wrong
this gives NOT a static number
both labels UUID= and LABEL= do find its way into kernel commandline


right
this gives a commandline to the kernel:

I am thinking you're not understanding things. The way I put UUIDs is the correct way to do it with lilo.conf. I am successfully using it in my computer right now. Others have successfully done it with labels. I've helped several people set up their lilo.conf files with UUIDs. As I wrote in the article, PARTUUIDs are not properly supported in lilo (unlike regular UUIDs), so you need to use the addappend option, but you do not need it for UUIDs (if you're using an initrd). If you're trying to do it without an initrd, it might be completely different (and might get the output you found), but the way I wrote it there most definitely works.

There is even a perl script included with lilo called lilo-uuid-diskid (it's under /sbin/) that will go through and convert your lilo.conf to use UUIDs in the format I listed. You can view the script here and between lines 443 and 447 it will show an example of what it does, which is the format I provided.

Also, to further iterate that this method works (without an append), if I view my /proc/cmdline, I get:

That particular boot is done with the following stanza:

My computer boots up properly every time. And when I first implemented UUIDs in my lilo.conf, I then played around with my drive order to ensure it worked, and when I swapped cables for my first and sixth drive, it still booted, although, my main OS drive was now /dev/sdf2 instead of /dev/sda2. It worked exactly as it should.

What you're probably seeing is when you use UUIDs without an initrd, which isn't supported. I specifically mentioned in the article that an initrd is required if using LABEL or UUID. The reason an initrd is required is because of what you quoted out of /usr/src/linux/init/do_mounts.c. As you can see, it doesn't support using UUIDs specifically (the only mention of UUID is under the PARTUUID section). It needs the environment provided by the initrd to use the UUID. If the environment isn't there, the kernel doesn't know what to mount and you end up with a kernel panic.

As for your comment about PARTUIDs (not sure if this was a misspelling since that term did not exist in your link) existing since winNT, that is probably something other than the PARTUUIDs that exist now (notice the extra U). UID stands for Unique IDentifier, but there is no standard on what that means. That is why with WinNT systems, according to you, it is a timestamp. UUIDs are universally unique, which means there needs to be a standard. That standard is a 128bit value that is comprised of 32 characters. GPT stands for GUID Partition Table, and GUID *is* a 128bit UUID. The whole partition table was designed around using universally unique identifiers for partitions, which are referenced using PARTUUIDs. As I mentioned, PARTUUIDs are only included with GPT partitions. They, flatout, don't exist for MBR tables. However, some clever people found a way to take the drive identifier and attach the partition name to allow referencing specific drives and partitions without PARTUUIDs under the PARTUUID label (this is why your MBR drives don't show up under /dev/disk/by-partuuid/ -- because they don't exist, but you can view the fake "PARTUUID" under blkid). But this wasn't implemented until the 3.8 kernel. If you were to try this on an older kernel, you wouldn't have any PARTUUIDs listed in blkid for your MBR devices and you'd have to use UUIDs and an initrd like old times.

This whole thing is just like how the NTFS "UUID" is not an actual UUID, but is still able to be referenced as one.

re: Hi, ;)

i have had a look into lilo source code and the change log ...

this leads into the bsect.c (version of lilo-24.2)
and i can see that lilo rearly took these too words and put them into kernel commandline by itself, because i have never used this before, and have had trying this with PARTUUID= witch doesn't work, i dont know it before.

so i have learned it today ... ;)

thank you

may be simple patch for bsect.c is a good idea

That might definitely be worth routing up to Pat since he stated he will maintain lilo after the most recent developer decided to finish the project at the end of 2015.

EDIT: I wonder if support could be added for PARTLABEL as well (I am not good enough with C to know how to add it), although, that is limited to solely GPT partitioned drives.

Good catch...

Out of random curiosity, how do you determine the number? Based on what I could find online about that line, I'm assuming it is checking if the string length is greater than 10 and

I think I just figured it out. First it's checking if the string is longer than the characters used for the definition (in PARTUUID=, it is 9 characters, plus the actual UUID after), then it checks if the first 9 characters actually equals PARTUUID= (if it doesn't, it moves on to the next else if statement).

Thanks for making me continue to learn on this thread ;)

Good Stuff !

These are excellent enhancements for LILO.

This Arch Doc helped me 'get it' Arch Persistent block device naming

Thanks for helping make Slackware better for all !

-- kjh

I used that wiki heavily when I was switching my computer over to UUIDs. It (and the few linked pages there) taught me a lot of what I know about UUIDs and how the interact with lilo.conf and fstab. Hopefully once I finish the slackwiki page, it can be a good enough reference for Slackers that they don't need to visit the Arch page.

sorry for disturbing your party ...

but i can't find any reference to this 'PARTLABEL=' in the kernel code, so i don't think that the kernel could find its root partition by this naming.

maybe with an initrd - i dont know - i have never used that.

ok. i shut up now

I'll do some testing in a VM before I finalize the wiki page.

@bassmadrigal,
as I can see for now 'PARTLABEL='
1) is unusable by kernel itself (see name_to_dev_t() from kernel's init/do_mounts.c), as "LABEL=" and "UUID=" too, and
2) is unusable by initrd. initrd's init script uses sbin/findfs to resolve "LABEL=" and "UUID=" to device name. As for 14.2 mkinitrd 1.4.8 uses BusyBox v1.20.2. It's findfs says: As we can see it doesn't know anything about PARTLABEL=.

So, for now "PARTLABEL=" is unusable by the kernel itself and by the initrd's init.

Sounds good. Where would we look to see if the fstab still supports it?

@bassmadrigal,
/etc/fstab is a config file of mount command, so

man mount -- for commandline support,
man fstab -- for support in /etc/fstab.

They (LABEL=, UUID=, PARTLABEL=, PATUUID=) are mentioned there.

Good point. I had thought about that after I posted, but I was already in bed.