Why is everything so complicated now?

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

This thread is not about what I should use to create a good working fstab. There are several good memorable options available for sysadmins to identify partitions: device names, filesystem labels and, for GPT disks, partition labels. GUID and UUID strings are ugly and unmemorable imho but if you want to use them in your own handwritten or hand-edited fstab, go ahead. What I am complaining about here is the traditional automatic fstab generation at installation, which used to give you a stable and reliable setup but no longer does so. Newbies rely on these files to just work. They used to do so and now they don't because installers are writing in partition identifiers that are liable to change without notice.

There are at least two ways in which this could be fixed.

1) Don't include in the installer-provided fstab any hard drive partitions that the user hasn't named as part of this installation. Just make entries for the internal partitions like root, swap, and home plus some standard entries for hot-pluggable devices. If users want to make any other partitions available, they can do so for themselves.

2) If you do want to include partitions that are outside of the current installation, don't use filesystem-dependent identifiers for them that are liable to change without notice. Use device names for an mbr disk, partition names or GUIDs for a gpt disk.

Is that too much to ask?

Back in the old days when IDE drives were still the norm, I simply used /dev/hda, /dev/hdb etc, since the system was always going to assign /dev/hda to the master drive on the primary IDE port, and /dev/hdb to the slave drive on the primary IDE port.

When SATA came along, drives can be on any SATA port. Things are less guaranteed, whether it be because of port swapping, bios changes, buggy firmware etc... It's rare drives will get assigned different designations without making any changes, but it has happened to me.

How large is the auto-generated fstab file? It's easy to see what UUIDs belong to what drive.

ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 15 2023-12-02 13:59:28 1942456544156648952 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 15 2023-12-02 13:59:28 302A-3642 -> ../../nvme0n1p2

Originally Posted by fatmac 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.)

+1. I have one uuid for a usb disk so it's always on the same mount point.

Originally Posted by hazel 1) Don't include in the installer-provided fstab any hard drive partitions that the user hasn't named as part of this installation. Just make entries for the internal partitions like root, swap, and home plus some standard entries for hot-pluggable devices. If users want to make any other partitions available, they can do so for themselves.

I think it works already that way, installers do not care about all your disks/partitions, but the OS you want to install. Or probably I misunderstood something? (how is it related to your initial post?)

Originally Posted by hazel 2) If you do want to include partitions that are outside of the current installation, don't use filesystem-dependent identifiers for them that are liable to change without notice. Use device names for an mbr disk, partition names or GUIDs for a gpt disk.

This is an extremely hard question. There are a huge amount of different filesystems/partitions, storage devices available, including ram, disk, nfs, samba, raid, lvm, virtual disks, cards, ....., there is no need to have either mbr or gpt. Exactly this unique id is [meant to be] used to identify them, if any.
But if it is not suitable for you use labels or whatever else you find useful.

Originally Posted by pan64 I think it works already that way, installers do not care about all your disks/partitions, but the OS you want to install. Or probably I misunderstood something? (how is it related to your initial post?)

I am talking specifically about AntiX, but I don't know if what this installer does is universal in Debian distros these days or if it is a special AntiX wrinkle. And I know even less about other non-Debian installers.

The partition assignment dialogue in AntiX is actually very impressive. It shows all the partitions it has found and you label the ones you want to use for root, swap, efi or any other standard purpose (for example as a /var partition) in this installation. Logically therefore these should be the only partitions to go into the fstab. But what AntiX does is to add in the remaining partitions to be mounted user-mode in the /media tree, like removable devices. And it uses filesystem-dependent IDs for them rather than partition-dependent ones.

I'm sure this is someone's idea of user-friendliness but it makes the installed system hostage to changes that may take place elsewhere on the drive, which imho are none of AntiX's business. Maybe some people who use other distros would care to report whether their installer programs do this. If so, my first rant stands: this is the kind of creeping complexification I would rather do without.

Originally Posted by hazel Maybe some people who use other distros would care to report whether their installer programs do this. If so, my first rant stands: this is the kind of creeping complexification I would rather do without.

I won't report hazel, since we share similar views and distros. What irritates me is things being automagically mounted in places like /media/user/other/directories/UUID/. . Why mount it at all if you're going to hide it so well?

Originally Posted by business_kid What irritates me is things being automagically mounted in places like /media/user/other/directories/UUID/. . Why mount it at all if you're going to hide it so well?

But that's the whole point, isn't it. Those weird mountpoints are not intended to be seen and used by human beings but by udisks/udevil. You just click on a folder in your file manager and the appropriate disk gets mounted behind the scenes. The general view these days is that what is actually going on in the system must be kept hidden so as not to frighten the poor silly users. Until it goes wrong and then you have the devil of a job finding out what actually happened.

Originally Posted by hazel But that's the whole point, isn't it. Those weird mountpoints are not intended to be seen and used by human beings but by udisks/udevil. You just click on a folder in your file manager and the appropriate disk gets mounted behind the scenes. The general view these days is that what is actually going on in the system must be kept hidden so as not to frighten the poor silly users. Until it goes wrong and then you have the devil of a job finding out what actually happened.

Exactly. Which is why neither of us are going there. I don't go for systems operated on point & click. Point & click is a good way of selecting 'one of many' options, but very poor otherwise.

Besides, with me going from Accounts to grease monkey on motorbikes, to Electronics R&D Genius, my whole career orientation is against that sort of thing. And let me guess - udevil requires Systemd?

Originally Posted by business_kid And let me guess - udevil requires Systemd?

Not on AntiX, it doesn't! AntiX is just as hostile to systemd as Devuan or Slackware. Although it mostly uses Debian repositories it has a "non-systemd" repository of its own, where it stores systemd-free versions of programs like cups. It uses sysvinit to boot and eudev to manage hardware. I suspect that they also use elogind to stand in for the systemd dependencies in application packages.

Thinks have ALWAYS been complex and complicated, but we were once too ignorant to KNOW that!

I use the tools to give things names, and mount using the names. That way the UUID can change, but the name I GIVE IT identifies the item properly.

Exceptions: mdadm does its own non-UUID naming. LVM simplifies one end while making the other end more complex, but it is a complex that is under my CONTROL! I REALLY like control!

Originally Posted by wpeckham Thinks have ALWAYS been complex and complicated, but we were once too ignorant to KNOW that!

That isn't so. I started using Linux around the turn of the century and I was amazed at how easy it was to understand the basic structure of the system and how it worked. It has grown hugely more complicated over the years, easier to use perhaps but much harder to understand.

I use the tools to give things names, and mount using the names. That way the UUID can change, but the name I GIVE IT identifies the item properly.

If you use an e2label, then I think that goes in the superblock along with the UUID, so the label would disappear if you remade the filesystem. But I agree that labels are at least a lot easier to recognise than UUIDs.

I REALLY like control!

Exactly. That's partly what I'm complaining about in this thread.

Yes, control is good. And control over simple is better than unnecessary complications. I earned a living fixing (hardware) stuff too complicated for the ordinary mortal. But linux is in danger of losing that simplicity. It's great to be able to configure files and fix stuff, instead of imploring apt or systemd to fix it for you.

I have Antix, on my laptop. I mean to get to know it better. I have Devuan to replace Debian on this box as a spare distro. I have the iso on a usb drive, I just haven't run it yet.

I'm not really for or against systemd. When Debian switched, I held back any of the upgrades to systemd. When I bought a new laptop, I installed Debian, and let it pull in the minimal default dependencies. In my daily usage, I really didn't notice much difference between sys-v and systemd.

I don't really have a lot on my system that's automatic. My fstab includes the root filesystem and /tmp on tmpfs. Any additional drives I manually mount.

Why not just remove or comment out the unwanted entries in fstab?


Oh, and what does udevil do? I don't have it on my system.

Originally Posted by hazel Not on AntiX, it doesn't! AntiX is just as hostile to systemd as Devuan or Slackware. Although it mostly uses Debian repositories it has a "non-systemd" repository of its own, where it stores systemd-free versions of programs like cups. It uses sysvinit to boot and eudev to manage hardware. I suspect that they also use elogind to stand in for the systemd dependencies in application packages.

antiX does not use elogind or any of its libraries at all (unlike Devuan and Slackware).
We also have a runit init version available and an init-diversity development release which includes 4 init systems on the live iso (sysvinit, runit, s6 and s6-66).

Originally Posted by anticapitalista antiX does not use elogind or any of its libraries at all (unlike Devuan and Slackware).

Is there documentation on what/how you change the packages that currently depend on libsystemd0/libelogind0 in order to make them not do so?