Why doesn't Gentoo use UUID=... in fstab? -- Solved

py-ro · Veteran Joined: 24 Sep 2002 Posts: 1734 Location: Velbert

Since you are using GPT anyways, just use PARTUUID, should work.

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

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.

Thanks.

saellaven · l33t Joined: 23 Jul 2006 Posts: 646

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

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.

saellaven · l33t Joined: 23 Jul 2006 Posts: 646

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

OK all that makes sense well enough. I got bit by that IDE to SATA renumber, but not so incredibly bad since I knew it might happen.

I'm usually the one who shouts about complacency, so I guess it was my turn to have it come around.

Thanks.

mv · Watchman Joined: 20 Apr 2005 Posts: 6747

FastTurtle · Posted: Sat Aug 09, 2014 6:52 pm Post subject:

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).

NeddySeagoon · Posted: Sat Aug 09, 2014 7:27 pm Post subject:

Team,

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.

Cyker · Veteran Joined: 15 Jun 2006 Posts: 1746

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?!

NeddySeagoon · Posted: Sun Aug 10, 2014 11:56 am Post subject:

Cyker,

As always, patches welcome.

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.

Cyker · Veteran Joined: 15 Jun 2006 Posts: 1746

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.

szatox · Advocate Joined: 27 Aug 2013 Posts: 3131

What about using initramfs and call mount with e.g. labels? I guess it's not a perfect solution, but hey, it isn't that bad either.

Yes, I know UUIDs are more unique, but labels are human-readable and I consider it a serious advantage.

NeddySeagoon · Posted: Sun Aug 10, 2014 8:58 pm Post subject:

Cyker,

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.