mount_server's "Restore previously mounted volumes" funtionality is bogus.

[bipolar]

I have set, via Tracker, the "Disk mounting during boot" option to "Previously mounted disks".

Via the kottan app, I can see that the ~/config/settings/mount_server file contains the correct values for:

• all the boolean settings (only initialMountRestore set to true in my case)
• 2 messages under info, for the two disks I want to be automatically mounted at boot: "Haiku64" (boot volume), and "Data1" partition.

Yet, upon boot, I end up with 3 volumes being mounted:

• Haiku64 (a 64 bits install of beta5)
• Haiku32 (a 32 bits install of beta5)
• Data1

Similar thing when I boot Haiku32, all the three above get auto-mounted, despite having the correct settings in the mount_server file.

[humdinger]

FWIW, it works for me. 64bit beta5.

[diver]

Same issue here. 64bit latest nightly.

[bipolar]

I've double checked, on both VirtualBox, and on bare metal. Same wrong results everywhere for me with beta5+125, and even on an hrev58095 nightly I had lying around.

In case it change things, I have 7 partitions (6 BFS) on disk1, and 5 partitions on disk2 (2 ntfs, 1 ext4, 2 BFS), and disk3 (1 each of ntfs, ext4, BFS).

For VMs, only disk1 and disk2 are attached. When running bare metal all three disk are present. All disks with MBR-style partitions.

On hrev58095, I tried setting only the boot partition (disk3) and "data1" from disk1... upon reboot, 3 partitions were mounted: boot (disk3), and from disk1: "data1" and "temp1". On a following reboot, one more BFS partition was automounted: "temp2" :-/

[bipolar]

I think the issue lies in the way MountArchivedVisitor calculates a "score" for each partition, to decide if it should auto-mount it. In MountArchivedVisitor::_Score(BPartition partition):

It assigns +4 "score points" if the capacity of a given partition matches the value stored on the info BMessage from the settings.

It then assigns +3 points if the deviceName matches. +1 if fsName matches, and +1 if blockSize matches. (deviceName won't match for partitions on the same disk, but can cause issues if you change driver order on BIOS or when switching from VM to bare-metal).

If I'm reading things right, a "score" value >= 6 means the partition gets auto-mounted.

In my case, "Haiku32" and "Haiku64" have the exact same capacity, and they are on the same device and are BFS formated, with same block size, thus they will get always auto-mounted together. Same with my "Data1"/"Data2" and "Temp1"/"Temp2" partitions.

---

I guess we need something more robust than that scoring mechanism, which clearly is not a good match for my setup :-)

[bipolar]

The following change, while far from perfect, fixes the issue for me: ​https://review.haiku-os.org/c/haiku/+/8565

[X512]

GPT unique partition GUID (not type GUID) can be used if available.

[bipolar]

Sadly on this machine I only have MBR-style partitions. Would be nice if there was a way of adding some form of "unique" ID into BFS partitions, but I guess if there was... it would be in use already.

[monni]

One way to get semi-unique ID is to store time of initializing/formatting the partition in the root directory metadata, but Haiku doesn't have statx() function yet to return full metadata of directory or file. Like I mentioned in 8565, file systems like FAT already store the information when partition was formatted in MS-DOS or Windows (not sure about tools in other operating systems).

[nephele]

bipolar: fwiw gpt partition tables can be used on mbr booted computers too, but this depends on the firmware a bit. Some may have issues but it usually works. In that case this should work woth gpt uids.

[waddlesplash]

Fix merged in hrev58366.

[diver]

I wonder if a commit here is related to this issue? ​https://github.com/axeld/haiku/tree/mount_server

[diver]

Ah, never mind, it was actually already merged in hrev51932.