UUIDs on drives

[ghe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Broughton wrote:

| I don't see that the two statements are contradictory.  The _hardware_
| identifies itself - but the hardware never identified itself as
/dev/sdb3.
| The software does that...

Yes. That's true. My complaint is that the software sometimes decides
that Derek should get a new phone number. Then Derek's friends can't
find him anymore. And sometimes he's got the kernel in his back pocket.

| But why would they want to make artificial distinctions between
hardwares?
| The simple fact is that there's nothing intrinsically special about being
| the first SATA disk - especially if you really are wanting to boot off
USB.

Beg to differ. If the boot block is on SATA1, grub needs to be able to
find it -- or failing that, go look for it.

If you want to boot a different system, go to the grub menu and do it.
But if grub can't find the disk, it can't display the menu.

|> Yes, but that's not a lot of help when it's trying to read that
|> partition on the wrong disk. Or when you can't get to menu.lst to
|> correct the problem
|
| pffft.  You can _always_ get to menu.lst to correct the problem.  You
might
| need to be an expert, but it's certainly possible.

Very true. "Or when *I* can't get to menu.lst" or "Or when it's a major
PITA to get to menu.lst". Better?

| For that matter so would hd, but what would it mean?  The whole point is
| that those device names are _meaningless_, and so _shouldn't_ be tagged
| with artificial and misleading distinctions.

They aren't meaningless when they're written into config files like
menu.lst or fstab. The UUIDs are consistent because they're created when
the fs is built (and because udev never gets ahold of them :-).

But if the installers and updaters are writing sda or (hd0) in the
configs, they'd better be referring to the same hardware next time those
files are read. UUIDs, as I see them, are a fix for a problem that
shouldn't have existed.

There may have been good and sufficient reasons for udev (and the
changes to the kernel's block drivers), but the way it was implemented
broke a system that had been working, literally, for decades.

| And you couldn't fix that from a live CD?  I've managed to make systems
| unbootable before, but you go to a live CD (the first time, I didn't even
| use an Ubuntu one - I don't think they had a live CD then), and
| run "grub-install".

No, I couldn't. Because I've never learned how. I thought about that
route, but it was easier to just reinstall (it was still pretty much
what the installer put there, updated) than to google and read and think.

- --
Glenn English
ghe at slsware.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkilEIIACgkQ04yQfZbbTLbKVwCfT/AX4t4Mo1n1jYNofQ79Dt49
kqAAoJOMNVqFrB6J2Hzxg6m4W0Q6f10H
=tQQR
-----END PGP SIGNATURE-----