Background to the rant: Yesterday morning I booted into AntiX to do my weekly update. After completing this, I decided to take advantage of my early morning "free download period" to download the packages that I would need to start my new LFS build. It seemed sensible to transfer them from Antix's ~/Downloads to LFS's /sources directory before logging off and shutting down. And I found I couldn't do it!

Tried to do it in the file manager and was told I had to be root. Yet /etc/fstab said that all my guest partitions were user-mountable! Tried to do it several different ways with mount and got told either that the disk didn't exist or that it wasn't in fstab. So then I checked the entries in /dev/disk/by-label one by one and found that the partition had a different UUID from the one listed in fstab. And then I realised what had happened. Like most people I clear partitions by reformatting them with mkfs and a new filesystem means a new UUID.

Rant begins
All Debian distros use UUIDs in the fstab created by the installer. I believe other distro families do this too.
a) This is ugly and confusing. You can't really see what gets mounted where. AntiX at least provides comment lines with the correct partition device above each active line, but the need to do that at all proves my point. The contents of a major file like fstab should be self-explanatory.
b) It is very difficult to use the mount command with such long partition IDs. And you can't use the mountpoints instead because, idiotically, they take the form /media/UUID. Cut-and-paste is the only thing that works.
c) Partitions are seldom deleted but often repurposed, especially in a multiboot machine. The quickest way to repurpose a partition is to reformat it. Did the Debian developers not realise that, compared with device names, UUIDs are ephemeral and can easily get out of date? Again fstab is too important a file to be made so fragile.
d) Most drives are gpt now so if ID strings are really needed (and I'm told that they are necessary in server machines), the installer should at least check for this and use GUIDs where available and not UUIDs.


Thank God Slackware is still sane!

You youngsters ....

As in most inane decisions made by distros (think sudo) UUID was mandated by Ubuntu when the support for SATA was rolled out for PATA disks. They figured their users were too stupid to be able to handle the nomenclature change from /dev/hda to /dev/sda
And they had the audacity to suggest it needed to be done because device names might change between after boot. Bunkum !!!

You never have to use UUID (maybe partition UUID rarely) - sometimes it can be handy tho'. Also tab completion works fine on the mount command. I never use GUI file managers for anything important.

What did they think udev rules were there for? Decoration?
Well, I for one would rather not have to completely re-edit the fstab file created by the installer. That's more or less what I am complaining about here. They keep saying they want to make Linux easier and they're actually making it harder and more confusing.
Oops! I never thought of that.
I don't often use them either; I much prefer command line. In Slackware I don't even have a file manager. But since AntiX does have one, I thought that using the file manager's automount capacity and just dragging files across would be faster. Bah!

Think of the positive - using the file manager in antiX alerted you to fixing fstab

User can label partitions (via gparted for example) and set them in fstab and you are right -it is complicated (which is why we provide a script to 'simplify' it through comments)

Here's mine

1 members found this post helpful.

Why not just use their /dev/sd? in fstab - it still works fine, especially for internal disks - UUID can come into their own when using/removing multiple external disks...

There's an important structural point here. If you have multiple Linux systems on one drive, they should be completely independent of each other, island universes. The only points of contact should be conceptual links that you yourself choose to make: for example, I have a common data partition that is mounted in the same place on all my systems and that works because I set my UID to be the same for all of them. If I want to make one system's root partition available within another system, I can do that, but I make sure that this doesn't conflict with any future plans I might have for that partition. Using a device name ensures that; a UUID or an e2label does not.

If root partitions are automatically shared around in fstab files, the integrity of one system becomes dependent on what happens to another. fstab in effect becomes merely a snapshot of the systems at the time of installation and its accuracy is almost bound to degrade over time. How is it that devs don't see this?

@anticapitalista Thanks for making it clear where those comment lines came from. Without them, I might have been threshing about even more. But that isn't a solution. In fact if a partition acquires a new UUID, the comment line can cause further complications. When I tried to mount the target partition by device name, I was told that it was not in the table, because it was there only in a comment. And when I tried by the UUID as listed, I was told there was no such disk.

I thought the preference for using UUID was because if you had multiple disks, there was no guarantee that /dev/sda didn't become /dev/sdb the next time the system booted.

1 members found this post helpful.

Yes to the post immediately above. That has bitten me more than once. The device node changes if you plug the SATA cable into a different port on the mobo.

And anyway, you can use volume labels.

How often does the average user play musical disks with their motherboard? Distros like Debian and the Ubuntus try to be all things to everyone and you end up with things like this. Then, software wants to not have to do all the heavy lifting and you end up with Avahi as a requirement for a printer. Users want things done automagically, then you end up with Systemd, as in sudo systemctl jobctl system.world.universe.mindofgod dog::wash.start(). Finally, people get tired of something that's worked fine since the 1980's, decide to reinvent the wheel, and you end up with Wayland. My curent process list from ps aux is 306 lines long. That's why everything is so complicated.

Actually my buddy had a haswell hp business desktop that I slackified for him. It had a proprietary mobo (non standard shape), powersupply (weird connectors, non standard form factor), and only one extra sata port. When I put an extra drive in, it was a dice roll which drive was going to be sda and which sdb (every time) even though no one was touching cables or config. I did have to use blkid /uuid scheme to make it fit for recipient (who was not willing to learn to tinker with it to fix it himself). HP's theory about corporate customer hardware seems to be same as systemd philosophy about software: idiot proof the box with respect to a customer who is only going to do unimaginative expected things with it , but so inflexibly that it also impedes intelligent people trying to innovate ways to do more with their system.

Yes, of course I can if I completely rewrite my fstab. But if I decide to do that, I might as well do it with device names. The point I'm making is that most distros and most users rely on the installer to create their fstab and it shouldn't create one that is dependent on the future management and use of partitions that have not been declared as relevant.

I'm really sorry, for me it looks like the best way to solve it is what we have right now, at least I don't know anything better. As said, things become more and more complicated over time, so the solutions become more and more difficult.
By the way, if I remember well using systemd this good old fstab can be eliminated completely. In the future. But it is another story.

+1 from me.

When I trouble-shooted a Linux VM that had a cyclic reboot (admin mistake), I saw that after 20-30 reboots it came up to maintenance mode - with sda and sdb swapped!

Others have reported a disk swap after an OS upgrade.

And RedHat recommends to use either UUID or LABEL.
If you dislike the UUIDs then go for LABELs!

I also worked with Solaris. Solaris uses /dev/ path that is symlinked to a /devices/ path that is from the physical structure, a HW path and/or a UUID. You need a special "reconfiguation reboot" to reconstruct it (and then risk a disk swap).

Well, all I can say is, since starting using Linux (1999), I've been using /dev/sd? since the renaming from /dev/hd?, without any issues.

(I do use UUID on some installs, so not averse to it, just think it isn't needed in most cases.)