UUIDs on drives

[ghe]

Rashkae wrote:

> The boot drive is always Drive 0, whichever drive on your Mobo you
> decide to boot from.  I strongly suggest you always make the drive where
> your /boot/grub is located the boot drive.  Anything else will now
> likely lead to tears.

(This is long, but hopefully the end.)

Look. I think we're all saying pretty much the same thing, but, as 
someone has said, we're looking at the situation from different points 
of view and different layers of software/firmware.

My own orientation is somewhat hardware-based. My first computer had no 
peripherals or drivers, so (with the help of a mentor who knew what he 
was doing) I built the controllers and wrote the drivers. So I tend to 
think of a disk drive (or whatever) as a collection of I/O addresses for 
however the CPU does its I/O.

My most recent box (the Mac Pro) has 4 SATA slots, 1 or more ATAPI 
ports, some USB ports, some FireWire ports, and a couple SCSI buses. 
When the computer powers up, the CPU runs some code in a ROM, and that 
code looks around for hardware, determines what exists and decides how 
to address it, and makes that information available to the world. That 
process is pretty deterministic, given one computer with unchanging 
hardware capabilities.

If I install onto a disk in the leftmost SATA slot, there's a unique and 
unchanging I/O address associated with that disk (as long as it's in the 
same slot), and I see no reason why the ROM code and the boot loader 
should ever need to refer to it as anything else. (The boot loader could 
be told which I/O address to boot from in a setup in the ROM code.)

I know it doesn't work this way now, and that's largely what I'm whining 
about.

In my case, with Ubuntu dual booting on the Mac Pro,, udev apparently 
scanned the SCSI bus before the SATA ports, while the ROM code (Mac EFI) 
scanned the SATA ports before the SCSI bus. So the names they made up 
didn't match if the SCSI bus had an active device on it.

(hd0) was always the same because it was determined by the ROM code, but 
sda wasn't, so when (hd0) was hit to boot, it found and ran grub just 
fine. But grub couldn't find a kernel to load. I know that's what UUIDs 
are for, but something didn't work (maybe Ubuntu started using them in 
the update that broke my install???).

There are "udev rules" that could maintain consistency with all this, 
but the installer would have to write some, if a given disk is always to 
have the same label.

And, as has been pointed out, the installer doesn't do that. It could, 
though. If creating fstab is part of its job, why shouldn't writing a 
few udev rules be, too?

UUIDs are yet another layer of software designed to maintain 
consistency, but they refer only to filesystems, not hardware devices. 
So some things are still at the mercy of the (sometimes not very 
merciful and often easily bewildered) ROM code.

The idea of running all block I/O through one piece of code is a great 
idea, but the operations have to be split out for the protocols of the 
different controllers, so there's not much to gain, I claim, by labeling 
all block devices with the same code.

udev's purpose of getting rid of redundant nodes in /dev and allowing 
for new ones for hardware that didn't exist in the past was a good idea, 
too. I just think there was just a tiny oops in the implementation, 
around the names used by that one piece of code for the block devices.

Since the node names in /dev are just strings, C's going to be referring 
to them with pointers anyway, so what's the disadvantage of calling 
things what they are: SCSIa, SATAa, SASa, IDEa, ATAPIa, FIREWIREa, 
IEEEa, USB_STICKa, PICTURE_FRAMEa, etc? And leaving enough room in the 
namespace for all the devices without overlap? (Don't create the nodes, 
just leave room for them.)

Except for the obvious problems that might be caused legacy software 
still referring to the sda names. That would need to be fixed, but 
building a sane map from the sda names to the new ones could 'trivially' 
be handled by more udev rules...

But UUID on top of udev on top of the kernel on top of the BIOS on top 
of the CPU's I/O... There's got to be an easier way to get to an I/O port.

I'm very much aware that things don't happen this way now, and I'm sorry 
I brought it up. But if I'm thinking something that isn't true or 
doesn't make sense, I'd very much like to know about it.

-- 
Glenn English
ghe at slsware.com