Kernel panic: lilo.conf: root="UUID=..."

Azevedo · 02-20-2012, 06:40 AM

Well it is booting now. But when it prompts for login the usb keyboard won't work

Uzuki · 02-20-2012, 10:13 PM

I believe that is another topic, so i suggest you create another one

allend · 02-20-2012, 11:45 PM

Quote:

mkinitrd -c -k 2.8.6.* -m ext4 -f ext4 -r /dev/sdb1

If you need support for usb devices (e.g. mouse, keyboard) then add ':usbhid:ehci-hcd:uhci-hcd' to the -m string.

duncan_roe · 05-20-2017, 05:47 AM

I just did some experiments on this which will hopefully shed some light:
- I normally build self-contained kernels which do not require an initrd
- using LABEL= in lilo.conf caused a panic as discussed above
- using LABEL= worked fine with a new initrd.gz created by "mkinitrd -c" and containing no modules at all
- using LABEL= worked fine on an older kernel with the above initrd.gz. Some complaints about "no modules" flashed by

The above were 64-bit kernels. Booting a 32-bit kernel revealed:
- using LABEL= with a 32-bit kernel failed with the 64-bit initrd.gz above. The panic message said

no working init found

So it seems that the LABEL= or UUID= functionality is relying on init (in the initrd) to mount the root partition

RadicalDreamer · 05-20-2017, 10:58 AM

Quote:

Originally Posted by Azevedo

Now I'm back to beggining of my problem:

On reboot, /dev/sdb1 is not the same drive/partition.
I have 4 eSata drivers which can be detected in different orders /dev/sd* on each boot up (because not always all 4 drives are turned on).

So your computer randomly assigns drive numbers at boot? Am I understanding this correctly? Does this include the Slackware operating system? One boot its sda1 and the next its sdb1? One drive with Slackware needs to be consistently sda1 if that is the case.

Here is what I do for lilo using mbr.

mkinitrd -c -k 4.4.19 -m ext4

In lilo.conf:
image = /boot/vmlinuz-generic
initrd = /boot/initrd.gz
root = /dev/sda1
label = Slackware

bassmadrigal · 05-20-2017, 11:59 AM

Quote:

Originally Posted by duncan_roe

I just did some experiments on this which will hopefully shed some light:
- I normally build self-contained kernels which do not require an initrd
- using LABEL= in lilo.conf caused a panic as discussed above
- using LABEL= worked fine with a new initrd.gz created by "mkinitrd -c" and containing no modules at all
- using LABEL= worked fine on an older kernel with the above initrd.gz. Some complaints about "no modules" flashed by

The above were 64-bit kernels. Booting a 32-bit kernel revealed:
- using LABEL= with a 32-bit kernel failed with the 64-bit initrd.gz above. The panic message said

no working init found

So it seems that the LABEL= or UUID= functionality is relying on init (in the initrd) to mount the root partition

You're correct that LABEL and UUID require an initrd. This is specified in the SlackDocs article concerning using persistent names in lilo.conf and fstab. However, the GPT spec adds PartUUID and PartLABEL (this feature was modified on relatively kernels 3.8 and newer to also work with MBR partitioned drives). You're now able to use PartUUID in your lilo.conf is able to boot the system without an initrd (PartLABEL is not supported for booting).

However, it's usually a good idea to not reply on extremely old posts (this was around 5 years old). It is frowned on by most forums.

@RadicalDreamer, this was a necro post from 2012.

duncan_roe · 05-20-2017, 09:57 PM

Thanks for that - I am again booting without an initrd now. LILO itself does not understand PartUUID so you have to use append, as in

append="apm=off root=PARTUUID=0aaac04b-02"

bassmadrigal · 05-21-2017, 07:13 AM

Quote:

Originally Posted by duncan_roe

Thanks for that - I am again booting without an initrd now. LILO itself does not understand PartUUID so you have to use append, as in

append="apm=off root=PARTUUID=0aaac04b-02"

Yes, that is covered on that wiki page as well.

Quote:

Now, as mentioned above, PARTUUID does not require an initrd (although, it works fine if you do use one). However, lilo is old enough that it doesn't have proper support for it, so there is a workaround to get it working. Instead of referencing root like we did above, we need to replace the root option within an “addappend”. This will add anything extra to the initial append line at the top of lilo.conf. Keep in mind your spaces, as it will be placed directly afterwards, so it might be wise to include an extra space at the beginning of the line to ensure it doesn't accidentally combine words (which would likely cause a kernel panic and prevent you from booting). For me, since my root partition is on a drive with an MBR, I'll have the shortened PARTUUID instead of the regular 32 character length of a proper PARTUUID.

Code:

image = /boot/vmlinuz-generic
addappend = " root=PARTUUID=6f47c81b-02"
label = Slack-partuuid
read-only

image = /boot/vmlinuz-generic
initrd = /boot/initrd-4.4.14.gz
root = "UUID=25a4dafe-bbf2-413f-a60c-8c38efc0a122"
label = Slack-UUID
read-only

image = /boot/vmlinuz-huge
root = /dev/sda2
label = Slack-default
read-only