OK that worked, except for LVM volumes which don't have PARTUUID. But since the host isn't booting off those I don't think it matters. Right now there's only swap on there, but when I start adding VMs it will be pretty crowded.

Come to think of it though, maybe /dev/vg/lv path identifiers make more sense in that case.

How do I set things up so that no matter what happens regarding new hardware, all the partitions are attached in the proper order?

I thought that UUID was supposed to solve it.

UUID is fine once your root file system (and possibly others*) is up... Anything you do has the potential to break when adding/changing hardware though, and every layer of abstraction (such as using an initramfs) comes with new ways for things to break in addition to the old ways. I suppose someone could extend an existing boot manager, create a new one or add UUID handling code to the kernel, but even that will only go so far (say your root directory gets corrupted). At some point, a sysadmin has to be responsible for the hardware in their machine, even if it means setting a new root UUID after rebuilding a corrupted root.

And that's why I try to keep my system as simple as possible, with most of the handholding removed. This way, when I change something, I will notice any immediate effects and can fix them while everything is fresh in my mind. I had a friend that used another distribution back about a decade ago... I helped him set up some servers and such by remotely editing config files in /etc and much to my surprise, the distro's config tools rewrote his config files on his next reboot a week or two later. Not the first time software has decided it knows what's best and changes things to something completely wrong.

For non-removable media, I use /dev/sd* devices for root/boot and /dev/mapper/* for my LVM partitions in my fstab. I used to mount by LABEL/UUID but stopped after udev's upstream decided it would be fun to potentially break things for arbitrary reasons. Frankly, given their history in breaking userspace carelessly and without concern for the consequences, I don't trust them or anything that might rely on them in terms of stability.

* again, see what the systemd folks and friends have tried to force by artificially limiting systemd's ability to have a separate /usr, usrmerge, etc. They say it's to prevent system breakage, but it causes a whole different set of problems that they don't care about and the Gentoo Council has said that it is perfectly fine for new versions of util-linux and such to move its files all over the place should the upstream or gentoo devs choose to do so. The result is, stuff that should be in /lib may very well end up in /usr in the future. The vote was absolutely insidious and the Council utterly irresponsible, but I'll stop there in this thread

Please try to avoid systemd politics on this thread. I hear you, but I do NOT want my support thread taken over by that battleground.

My boxes of this category seem to have a lot of disk changes. For one thing, the box in question has an ejectable SATA enclosure for backups, and for another my requirements are changing fairly often. That combined with the unfortunate acquisition of a bunch of WD green drives that all turned to crap on me in short order, and I've been sticking drives in and yanking them out more than any other setups I can remember.

I somehow thought that UUID was supposed to be the same anywhere. Move a drive from system A to system B and the UUID is still the same. Must not be so. My preference would be that no matter how many drives showed up in what order, my partitions would always be the ones I set up.

Please try to avoid systemd politics on this thread. I hear you, but I do NOT want my support thread taken over by that battleground.

I only included it, in so much as it matters why UUID might not be the most reliable thing going forward with regard to boot activity, and stopped there. I don't intend for it to take over the thread, just to provide an example of how things can arbitrarily change and cause pain.

Quote:

My boxes of this category seem to have a lot of disk changes. For one thing, the box in question has an ejectable SATA enclosure for backups, and for another my requirements are changing fairly often. That combined with the unfortunate acquisition of a bunch of WD green drives that all turned to crap on me in short order, and I've been sticking drives in and yanking them out more than any other setups I can remember.

So long as some hardware doesn't take over sda (such as adding extra controllers to your system), /dev/sda should be stable for booting (again, barring swapping that drive). In the past, I had a system with 4 IDE devices and three difference SCSI controllers inside it (with a total of 5 more hard drives between them). Using LABEL at the time kept everything sane with one exception - when the Linux drivers switched over from IDE to SATA, causing a rename up the chain with the IDE taking over sd[abcd]. I was prepared for this when I installed my new kernel though, and was immediately able to observe and correct the change for my root/boot partitions and with the proper root loading, everything else loaded fine by LABEL regardless of what node it was on.

And therein lies the key... a sysadmin needs to keep up on all the relevant changes to both the hardware and software on their system or else things can end up broken. Automation can only help so much, and, I would argue, can often hinder a non-experienced person (or even a more experienced one) by lulling them into a sense of complacency and helplessness when things do unexpectedly break, leaving them with no knowledge on how to handle it. "It just works" is great until it doesn't... and this is further exacerbated when something is in a constant state of change (hardware or software).

Anyway, you can mount your disks by UUID... just be wary of using UUID for root (and potentially a separate /usr). And keep in mind that an initramfs solution to UUID for root has the potential to break in random, unexpected ways in the future if you don't regularly rebuild it when updating certain key programs even if you don't change your kernel (regular binary distros update initramfs whenever there is a userspace or kernel change for you, so it isn't an issue there).

Quote:

I somehow thought that UUID was supposed to be the same anywhere. Move a drive from system A to system B and the UUID is still the same. Must not be so. My preference would be that no matter how many drives showed up in what order, my partitions would always be the ones I set up.

UUID is the same everywhere... it's just contained in the filesystem, not in the hardware tables and, at least as of my last research, the Linux kernel doesn't contain the code to mount via those filesystem descriptors directly, as userspace mount handles them entirely and then passes the proper reference expected to the kernel.

Last edited by saellaven on Tue Apr 22, 2014 5:23 am; edited 1 time in total

For non-removable media, I use /dev/sd* devices for root/boot and /dev/mapper/* for my LVM partitions in my fstab

I am not sure about LVM, but /dev/sd* for root/boot can be dangerous if there is more than /dev/sda*, even if you do not touch the hardware: Depending on your board and some other conditions, the order of letters might depend on the initialization order of corresponding controllers, and thus on some boots the order may have changed. Admittedly, in practice this is very unlikely, but it can be a severe issue if you are hundred miles away from the machine and need to reboot with a new kernel...

all: The kernel has been able to read UUID since 3.0+ when the feature was introduced due to UEFI and GPT disks. Current 3.1 sources (later then 3.4) I know - Linus changed numbering again.

I'm currently doing a test VPC VM install using GPT (no efi/uefi) to see what all is needed for a later project and will be using UUID/PARTUUID with grub-legacy (sys-boot/grub:0) and hoping it works as I dislike Grub2 and elilo refuses to install unless it's a proper ESP (efi system partition - fat12/16/32).

The term UUID is ambiguious. Filesystems have a UUID and partitions have a (different UUID)
In /etc/fstab, its OK to use the filesystem UUID os user space is available to make sense of it.
The root entry is not used to mount the root filesystem, so UUID works there too. It is only used to know the filesystem type for ckroot.

The kernel does not understand filesystem UUIDs, so if you want to write root=UUID=<root_filesystem_UUID> on the kernel command line, you must have a initrd to hold the required userspace tools. However, the kernel does understand PARTUUID, so root=PARTUUID=<partition_UUID> works without an initrd but don't use PARTUUID in /etc/fstab._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Yeah, this is what I really miss about IDE - Controller ports were fixed. Smeg knows why they broke this with udev and libata.

The worst thing is, contrary to what I was told in the past, the Kernel *KNOWS* what ports disks are plugged in to.

If I run dmesg, I can see that the kernel has detected that ata[1-3] have disks attached, and so do ata[7-8], but ata[4-6] are 'link-down', so in theory it should be bloody trivial for udev to map disks to e.g. fixed /dev/sata[1-8] based on that alone instead of the utterly batshit stupid all-storage-devices-from-anywhere-are-arbitrary-FCFS-sdX.

There information is RIGHT THERE in the kernel! There *must* be a way of getting that to (g)udev so we can create proper rules for drive position assignment. Yes there are labels and UUIDs, but these are disk unit assignment and not disk position, and labels can be accidentally spoofed, while UUIDs are unwieldy and a nightmare to type in by hand. Better yet, just have the kernel name the devices sanely in the first place!

Who would we need to speak to, to try and get something like that implemented?!

In days of old, when the PC only supported a small number of IDE drives, fixed assignments were neither here nor there.
SCSI has always enumerated drives in discovery order.
When you have large numbers of drives, fixed assignments become less and less useful because you only care about where a drive is when you need to (hot) swap it out to replace it.

It will be a really bad idea to have (e)udev rename drives. Suppose your root is on port 5 but its the only drive.
The kernel sees it an sda and boot proceeds normally until (e)udev starts. Now sda gets renamed to sde.
I will be able to hear the crash in Scotland.

Do not confuse drives/partitions with the file systems they hold. They are separate entities. Indeed. a filesystem can be spread over several drives.

Consider mdadm --assemble ...
Do I want to use the UUID of the raid set and let the kernel find all the bits or list lots of individual /dev/sd .... elements.
lots here can be 10s or even 100s.
The short hand at mdadm --create ... /dev/sd[a..z]1 only works because the elements are contiguious, regardless of where they are connected._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Well this is why *something* needs to to be fixed with the kernel and pretty much all bootloaders other than LILO right now.

*ALL* of them depend on the fact that 99% of people use /sda or drive 0,0 as root, but this is not a dependable thing because it is completely arbitrary.

A lot of Linux systems can be broken just by leaving a USB or eSATA drive plugged in because it messes up the order of drives between various bootloaders and the kernel.

It is a problem that has been ignored for decades because, by mostly luck, using the first disk socket in the system and not plugging anything else in works most of the time.

I am in a fairly unique situation as, due to the design of my motherboard and case, I have to use sockets 7 or 8 for the boot disk, and this exposes the hidden problem of unstable drive assignments in Linux.

In the IDE days, this would not have been a problem as HDG and HDH would *always* be HDG and HDH, and LILO wouldn't care.

Now, because grub is not port aware, and the kernel ignores port order, it is extremely easy to break my system by adding a new drive because the root and /var drives on 8 and 7 respectively will move.

I think grub was aware of this easily encountered edge case, and is why they added code to let you edit the boot string.

I had looked into what could be done, kernel-wise, but I'm not really an experienced coder and, frankly, the code is too hard for me to follow.

Thats a BIOS thing. grub calls the BIOS to find out about hard drives and uses BIOS detection order.
BIOS order and kernel ordering may be different.
Indeed some BIOSes call the boot drive hd0 regardless of which drive it is._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.