Debian uses UUID (blkid) in /etc/fstab automatically, but neither Slackware nor LILO do. FreeBSD doesn't use it either. I just wonder if there is a reason for this?

If you have two drives and install on /dev/sdb, and then unplug the other one, then the install should be on /dev/sda, which would prevent LILO from chainloading and Slackware from booting -- unless they used UUIDs to refer to the partitions.

UUID usage is not at all discouraged in fstab and lilo.conf in Slackware.

They are simply not used to write /etc/fstab during installation and by liloconfig to write /etc/lilo.conf.

But of course you can edit /etc/fstab and /etc/lilo.conf after installation and use UUID as you see fit, e.g. in case of removable devices. That's just a kind of tweaking you have to do manually when using Slackware.

1 members found this post helpful.

There is a utility to do this packaged with lilo:

usr/sbin/lilo-uuid-diskid

Unfortunately, it is currently broken for Slackware. I sent a patch to the maintainer Joachim Wiedorn. He told me it would be applied in the next lilo release. The patch can be applied manually in the mean time, if anyone wants to use it:

http://lists.alioth.debian.org/piper...ch/000066.html

3 members found this post helpful.

If you unplug a disk, you'd reckon you'd be aware of it and could update the boot-loader (I haven't used lilo in over a decade FWIW).

Debian based distros introduced UUID when libata was merged and they couldn't predict if devices would be /dev/hd? or /dev/sd? when the installer ran. Fedora used LABEL for similar reasons. Note these are filesystem attributes, not partition - unless you choose to use partuuid with gpt disk.
If you happen to use cloning imaging techniques, you will eventually run into problems with both UUID and LABEL.

2 members found this post helpful.

Interesting. Thanks for the replies and the patch.

Haha, yes, you have a point there. So which one do you use with Slackware? Not grub?

I decided to use it in fstab but not in LILO. If you use it in LILO, it's only supported for boot and root (using an initrd), and doesn't appear to work for other. Unfortunately I am only interested in other because LILO is on the MBR and chainloads 4 other partitions, and they all have their own boot loaders. LILO has a small /dev/sdb1 partition for the map file, which is not "governed" by any distribution (but it can be installed from Slackware or SystemRescueCD). There are no kernels on that partition since it only chainloads. The idea was that I would never have to update LILO once I have installed it, so the system would never become unbootable. UUIDs would help toward that end.

Of course, just about every distribution other than Slackware thinks it's a good idea to overwrite the MBR without asking, so it still has to be reinstalled all the time. And UUIDs change when a partition is formatted anyway, so maybe /dev/xxx is better for my purposes.

By the way, I just noticed that you can't mount UFS2 partitions in fstab by UUID, and blkid won't print it unless you invoke with "-p -n ufs" (but that prints a very short UUID which doesn't match the partition's UUID as printed by Debian's blkid). It works in Debian though.

I was having same problem, that is the reason I'm using UUID on fstab and lilo for more than year.
I don't remember if this is right, but if you set UUID on lilo you must use an initrd.

Technically, you use diskid (/dev/disk/by-id/) for the boot device. Some people use the terms UUID and diskid interchangeably.

To my knowledge there is no UUID standard, RFC-4122 is on track to be. Diskid is, or should be, a universally unique identifier.

Diskid's (/dev/disk/by-id/) have unique IDs for partitions that should not change with formatting.

Not in grub[2].