Suggestion for improvement how Dolphin handles and displays mounted devices

As far as I can tell Dolphin diplays the mounted drives/partitions in the “Devices” section based on /dev/disk/by-path.

Unfortunately by-path can change if you have multiple disks attached during boot.

For example in one of my computers I have three SATA drives, sda, sdb and sdc. In Debian or openSUSE it happens more or less frequently that /dev/disk/by-path does change - sda, sdb and sdc could be assigned differently during any boot.
This results in drive/partition entries in the “Devices” section to be mixed up.

Here are two screenshots to illustrate this behaviour (“Geräte” = “Devices”):


“Debian12KDE”, “Kubuntu2204” and “Windows10” are on the only M.2 NVMe drive - therefore their entries stay constant.

IMHO it could be an improvement to base the disk entries in Dolphin’s “Devices” section on e.g. /dev/disk/by-uuid or by /dev/disk/by-label instead.

If my assumptions are correct… :slight_smile:

PS: The screenshots are from Dolphin 22.12.3, but it also happens in other versions like 23.08.2.

2 Likes

I mount my drives and partitions using UUID, but I list them in Dolphin by Label. You just have to remember to open a partitioning tool and make sure to give each one a label. Once they are showing in Dolphin, it does allow me to drag them and put them in the order I choose. It appears that you use the same methods.

Mounting them by Path does allow them to change, depending on what USB devices are plugged in at boot on some PCs. When the path mounts change, nothing you do in Dolphin will keep them in the order you choose.

Thank you for your reply.
As you supposed, I usually mount my partitions in /etc/fstab by UUID (or by label).

But whether you give a partition a label or not (e.g. in GParted or CLI) does not change anything in Dolphin concerning the order. You just have a better declaration there.

Exactly that is the “problem”. And it does not matter if they are mounted or not.

is any of this affected by what is listed in fstab?

because i’ve never touched fstab and have only used dolphin and the Disks & Devices from the system tray to dictate what drives appear in dolphin.

changing their labels using a partition manager works to change their name in dolphin

the contents of my fstab are just those entries put there by the installer when i first selected the mount points for my linux partitions.

Not in my experience. Neither does how it is mounted in /etc/fstab.

My fstab is always UUID.

I just thought about this file that I had stored. This fstab sample lines is from several PCs, they use different methods for some of the shares, etc. I was hoping that others might add to it with pull requests.

This gave me the idea to improve things:

Should sort first the mounted drives then, by display name.

4 Likes

Unfortunately I am too stupid to understand your code, but I am glad that somebody who has the ability to improve things has taken an interest.
Thank you!
I hope one will still be able to sort the devices individually and that they will stay this way afterwards (this time) when /dev/sdX changes during boot.

The problem, is we want to allow users to change the order themselves.
So if we order by name we contradict this, hence we can’t do it.

Your best solution would be to add your drives to your /etc/fstab file using an UUID.
That’s the only way to have a consistent ordering accross boots.

2 Likes

I will give it a try (and add all of the drives/partitions) when I have time.
But I am not too sure that this will solve the “problem”, because I already mount some of the partitions/drives in /etc/fstab by UUID and their order gets changed nonetheless.

1 Like

You can use this to get everything you need to edit each drive in /etc/fstab because it is just so handy. It loses the nice formatting it had in my Konsole window. :joy:

lsblk -o path,label,uuid,fstype

┌──[wilson@heisenberg] Thu Nov 09, 03:06:07 [~]
└──[ <$> lsblk -o path,label,uuid,fstype
PATH LABEL UUID FSTYPE
/dev/sda any:pool 63e65642-55c3-2fb9-57e3-fde7ba28cb5f linux_raid_member
/dev/sdb any:pool 63e65642-55c3-2fb9-57e3-fde7ba28cb5f linux_raid_member
/dev/md127 4TB-SSD b7f515a6-0cc8-4127-87c9-3d01da319e95 ext4
/dev/md127 4TB-SSD b7f515a6-0cc8-4127-87c9-3d01da319e95 ext4
/dev/zram0
/dev/nvme1n1
/dev/nvme1n1p1 /home f27036e4-4e3c-4186-8070-b58acb26b549 ext4
/dev/nvme0n1
/dev/nvme0n1p1 2618-10E1 vfat
/dev/nvme0n1p2 / c3100e62-013a-4d82-8875-795e8c2fc2df btrfs

1 Like

Thank you, that’s exactly the way I would have done it.
But I have to postpone it until next week.

1 Like

I have never has an issue with the display order in Dolphin but I have a persistent issue with the categorisation. I have 11 drives and all of the drives connected to the SATA expansion port card are shown as Removable Devices despite them being internal hard drives. I am unable to move them to the Devices section.

That’s an usual case we don’t handle properly currently it seems.
On the other those drives are hot swappable right ? So there could be considered removable.

I don’t have such hardware and very few regular KDE devs would so we’d need inpurt from you to handle this. (solid-hardware list & details for the disk /etc/fstab file content for the concerned disks, versions, udisksctl dump output).

Feel free to open a bug with those details, and so that someone can help with that.

@meven : I know you did not mean me, but in my case the “hot pluggable” setting in the computers’ firmware makes no difference in the behaviour of Dolphin - whether I set them to “hot pluggable” or “not hot pluggable” (and they are not mounted in an external rack or something but are run-of-the-mill internal SATA SSDs).

I was also able to simulate Dolphin changing the display order of partitions (when e.g. sda, the internal SSD connected to SATA port 1, becomes sdb and vice versa) on different computers.
I cannot reproduce if this also happens with e.g. M.2 NVMe drives, though, as I only have one port for them in my most modern machine. :slight_smile:

I think that could have something to do with the distribution one uses.
Additional observation: I was mostly able to recreate this with Debian 12 and openSUSE Tumbleweed (my main systems apart from Kubuntu and TUXEDO OS) - but not once in one of the Ubuntu-based system. I guess Canonical has done something to the boot process that prevents e.g. sda becoming sdb and vice versa…

So I have had the time to alter my /etc/fstab today:

# <file system>                            <mount point>     <type>       <options>                  <dump>  <pass>
# / was on /dev/nvme0n1p4 during installation
UUID=f1844df8-1db6-4192-8eaa-37b1d6e488a9  /                 ext4         noatime,errors=remount-ro  0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=7DF1-DC9C                             /boot/efi         vfat         umask=0077                 0       1
/dev/sr0                                   /media/cdrom0     udf,iso9660  user,noauto                0       0
# setting swap to /dev/nvme0n1p6 after installation
UUID=8e9f45cf-b1d1-4707-8e2d-a61b02d0a412  none              swap         pri=10                     0       0
# setting second swap to /dev/sdb5 after installation
UUID=0459ee56-023e-4014-b87b-a23a98913838  none              swap         pri=5                      0       0
# setting third swap to /dev/sda13 after installation
UUID=347ac71b-c49e-440f-8f9e-947053eba097  none              swap         defaults                   0       0
# automount LinuxSpace (/dev/sda12)
UUID=7ec215a7-d052-452d-ae2d-33431e54822d  /mnt/LinuxSpace   ext4         noatime,defaults,nofail    0       2
# automount LinuxBackup (/dev/sdb3)
UUID=e1de1cd0-5c44-48cc-842c-7f33be81fdf6  /mnt/LinuxBackup  ext4         noatime,defaults,nofail    0       2
#
# added for "Dolphin test"
# <file system>                            <mount point>             <type>   <options>       <dump>  <pass>
UUID=4b536b29-d4d2-48e2-9ae6-969e2dc26e5d  /mnt/test/Debian12Server  ext4     noatime,noauto  0       0
UUID=06b790b3-a550-4fd8-8c58-14cd9b4def4d  /mnt/test/Kubuntu2004     ext4     noatime,noauto  0       0
UUID=5b500c7a-1361-4dd5-baeb-e114c2bcc562  /mnt/test/ZorinOS16Pro    ext4     noatime,noauto  0       0
UUID=5c1fb964-63df-4ad1-9574-ccf9301306e6  /mnt/test/GarudaKDE       btrfs    noatime,noauto  0       0
UUID=a35618a9-6db5-4495-a8cf-722c4ffe4b2a  /mnt/test/KDEneon         ext4     noatime,noauto  0       0
UUID=9f109b8a-8831-4460-8747-2e4ce70f5f5e  /mnt/test/Fedora39        ext4     noatime,noauto  0       0
UUID=078aeb8b-5926-4ca3-838a-0eea68bb9813  /mnt/test/Mint21Cinnamon  ext4     noatime,noauto  0       0
UUID=fca7240a-eadf-4b04-951c-90401e9c4312  /mnt/test/openSUSELeap15  btrfs    noatime,noauto  0       0
UUID=9c9b3b53-09d3-4960-84be-a9ae43762e96  /mnt/test/Kubuntu2310     ext4     noatime,noauto  0       0
UUID=2f08f381-da45-40e0-be7c-8136843833f8  /mnt/test/TuxedoOS2       ext4     noatime,noauto  0       0
UUID=d502d59d-8d03-4b5d-9923-4476e3456f7b  /mnt/test/openSUSETwd     btrfs    noatime,noauto  0       0
UUID=77D1-78D4                             /mnt/test/Transfer        exfat    noauto,user     0       0
UUID=EC2A1FA52A1F6C38                      /mnt/test/Windows10       ntfs-3g  noatime,noauto  0       0
UUID=115cab55-7092-4735-8dc7-cf20b3dfbe63  /mnt/test/Kubuntu2204     ext4     noatime,noauto  0       0

Without the additions in the lower part of /etc/fstab Dolphin would mount a partition in /media/$USER/name_of_partition (when I click on its entry in the “Devices” section).
With those additions it now mounts them in /mnt/directory_in_fstab.

Unfortunately those additions in my /etc/fstab had zero effect on how Dolphin sorts (and changes the display order of) the partitions in the “Devices” section, if e.g. sdb, connected to SATA port 2, and sda, connected to SATA port 1, exchange their names during the boot process (meaning /dev/disk/by-path changes during boot).

So back to square one…?

I will try to explain what I think I understand on this subject.

The path of a thumbdrive will be /dev/sd*
The path of a sata drive will be /dev/sd*
The path of an nvme drive will be /dev/nvme*

Normally, a sata drive would be /dev/sda and the hot plugged USB drive would be /dev/sdb.

To make a USB device bootable, the BIOS might mount it first, thus the OS might see the USB device as /dev/sda and this would cause a change of the drive ordering as seen by the OS. Since nvme drives are not mounted as /dev/sd*, they are immune to this happening.

To get around this, you can mount devices in /etc/fstab as either label or UUID and they will not change when a bootable USB is inserted before boot.

As far as Dolphin is concerned, it mounts by label of the partition. You can open each drive in kpartitionmanager and edit the label on any of the mounted partitions, or unmounted partitions in your system. These can be Hard Disk drives, SSDs, NVME, USB, etc. You should not have to boot from a live disk to edit labels. My system tends to put the /etc/fstab mounted devices first in the list, but I don’t know if that will be guaranteed. I also mount shared drives in fstab, and thus they are ordered correctly in Dolphin.

I don’t think that this has much to do with USB drives, but if one has several SATA devices connected to different (internal) SATA ports on the mainboard.

Their /dev/disk/by-path can interchange during boot, possibly resulting in sda becoming sdc, sdc becoming sdb and so forth…
And then the order of mounted and unmounted devices/partitions (of the drives that got another /dev/disk/by-path assigned to than last boot) in Dolphin’s “Device” section gets mixed up.
This is completely independent from what your entries in /etc/fstab are.

Therefore I assumed that Dolphin’s display has something to do with /dev/disk/by-path.
As I don’t know where exactly Dolphin gets the information for the devices in the “Devices” section from, I thought it might display them based on /dev/disk/by-path (and not based on e.g. /dev/disk/by-label) and this is the reason why the entries get mixed up…

As I wrote: if you use e.g. Kubuntu you won’t see the interchanging happen (at least I never have…) - for whatever specific reasons during its boot process.

Bug 476973 has been successfully created

The output of udisksctl is endless so was not submitted as I don’t know what part you need.