Slackware-current, huge: Kernel panic when 'root=UUID' in GRUB configuration
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackware-current, huge: Kernel panic when 'root=UUID' in GRUB configuration
The TL;DR version:
I’m experimenting with configuring GRUB, and I’m running into a kernel panic when I attempt to boot the Slackware ‘huge’ kernel from a GRUB menuentry that specifies the ‘root’ filesystem through its UUID:
Code:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
My questions:
Is this to be expected?
Is it a GRUB issue, or a kernel issue?
Is there anything that can be done to avoid it?
The long-winded version:
I’m using “GNU GRUB version 2.04-1”, installed and configured by Debian-Testing, to boot this Legacy-BIOS laptop, with a GPT-partitioned harddisk.
GRUB configured a submenu for my Slackware-Current system, in which it included two entries—one for the ‘generic’ kernel, and one for the ‘huge’ kernel:
Code:
menuentry 'Generic (on /dev/sda8)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-generic--f9f286a7-0ed3-4d01-bfa7-895fb4535697' {
insmod part_gpt
insmod ext2
set root='hd0,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt8 --hint-efi=hd0,gpt8 --hint-baremetal=ahci0,gpt8 f9f286a7-0ed3-4d01-bfa7-895fb4535697
else
search --no-floppy --fs-uuid --set=root f9f286a7-0ed3-4d01-bfa7-895fb4535697
fi
linux /boot/vmlinuz-generic root=/dev/sda8 ro vt.default_utf8=0 vga = normal
initrd /boot/initrd-generic
}
menuentry 'Huge (on /dev/sda8)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-huge--f9f286a7-0ed3-4d01-bfa7-895fb4535697' {
insmod part_gpt
insmod ext2
set root='hd0,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt8 --hint-efi=hd0,gpt8 --hint-baremetal=ahci0,gpt8 f9f286a7-0ed3-4d01-bfa7-895fb4535697
else
search --no-floppy --fs-uuid --set=root f9f286a7-0ed3-4d01-bfa7-895fb4535697
fi
linux /boot/vmlinuz-huge root=/dev/sda8 ro vt.default_utf8=0 vga = normal
}
In contrast to the Debian entries, the ones for Slackware specify the ‘root’ filesystem on the ‘linux’ line as the device name (while for Debian, the ‘root=UUID’ notation is used).
As a test, I copied these two Slackware entries into the ‘/etc/grub.d/40_custom’ file (under Debian, obviously) and I edited their ‘root’ parameters to specify the UUID instead:
Code:
menuentry 'Generic UUID (on /dev/sda8)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-generic--f9f286a7-0ed3-4d01-bfa7-895fb4535697' {
insmod part_gpt
insmod ext2
set root='hd0,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt8 --hint-efi=hd0,gpt8 --hint-baremetal=ahci0,gpt8 f9f286a7-0ed3-4d01-bfa7-895fb4535697
else
search --no-floppy --fs-uuid --set=root f9f286a7-0ed3-4d01-bfa7-895fb4535697
fi
linux /boot/vmlinuz-generic root=UUID=f9f286a7-0ed3-4d01-bfa7-895fb4535697 ro vt.default_utf8=0 vga = normal
initrd /boot/initrd-generic
}
menuentry 'Huge UUID (on /dev/sda8)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-huge--f9f286a7-0ed3-4d01-bfa7-895fb4535697' {
insmod part_gpt
insmod ext2
set root='hd0,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt8 --hint-efi=hd0,gpt8 --hint-baremetal=ahci0,gpt8 f9f286a7-0ed3-4d01-bfa7-895fb4535697
else
search --no-floppy --fs-uuid --set=root f9f286a7-0ed3-4d01-bfa7-895fb4535697
fi
linux /boot/vmlinuz-huge root=UUID=f9f286a7-0ed3-4d01-bfa7-895fb4535697 ro vt.default_utf8=0 vga = normal
}
The only difference with the original entries are the menuentry titles, and the “root=UUID” notation on the ‘linux’ lines.
After I ran update-grub, the two entries were successfully added to the GRUB menu, and now, the “Generic UUID” entry boots fine. The “Huge UUID” entry, however, runs into the kernel panic shown above.
I believe that the UUIDs method to specify the root device for the kernel, needs a special processing done by an initrd. More specifically, this is how is done in the Slackware's initrd:
Code:
# $ROOTDEV maybe contains: "UUID=f9f286a7-0ed3-4d01-bfa7-895fb4535697"
# Find root device if a label or UUID was given:
if echo $ROOTDEV | grep -q "LABEL=" || \
echo $ROOTDEV | grep -q "UUID=" ; then
ROOTDEV=$(findfs $ROOTDEV)
fi
# $ROOTDEV contains: "/dev/sda8"
And very probably that's why that huge kernel is not aware by that particular way how the root is specified, unless you use an initrd also for it.
Last edited by ZhaoLin1457; 07-25-2019 at 05:38 PM.
Kernel documentation tell to read this comment about root parameter:
Code:
/*
* Convert a name into device number. We accept the following variants:
*
* 1) <hex_major><hex_minor> device number in hexadecimal represents itself
* no leading 0x, for example b302.
* 2) /dev/nfs represents Root_NFS (0xff)
* 3) /dev/<disk_name> represents the device number of disk
* 4) /dev/<disk_name><decimal> represents the device number
* of partition - device number of disk plus the partition number
* 5) /dev/<disk_name>p<decimal> - same as the above, that form is
* used when disk name of partitioned disk ends on a digit.
* 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
* unique id of a partition if the partition table provides it.
* The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
* partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
* filled hex representation of the 32-bit "NT disk signature", and PP
* is a zero-filled hex representation of the 1-based partition number.
* 7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
* a partition with a known unique id.
* 8) <major>:<minor> major and minor number of the device separated by
* a colon.
*
* If name doesn't have fall into the categories above, we return (0,0).
* block_class is used to check if something is a disk name. If the disk
* name contains slashes, the device name has them replaced with
* bangs.
*/
So probably you should use "PARTUUID" instead of "UUID".
As of the last time I dug into it, using UUID does require an initrd. If you don't want to use an initrd, you can use PARTUUID, but I believe these are only generated on GPT formatted disks.
I also enclosed my UUID=XXXX in quotes, just to make sure the system reads it properly. I never checked if it worked fine without it. Example below:
Indeed you can't set root by uuid in grub.cfg if there's no initrd to find the associated file system.
I just checked it , it works if you set it by partuuid (that's the default in Slint cf. our attached /etc/default/grub).
As an aside, that's an issue when using os-detect to detect and boot Linux if an initrd is not found because it uses the grub command probe to find the uuid aka the fs-uuid, not the partuuid.
This commit could help change that, however it was merged after the release of grub 2.04 (so you need to patch it to get it) and it works for gpt only.
Last edited by Didier Spaier; 07-25-2019 at 09:01 PM.
Reason: Actually uploaded the attached file
Why we need to patch the grub, while we already have the blkid to find the PARTUIDs ?
blkid is available when Linux is running. It is not before booting, when the GRUB menu is displayed.
I was not speaking about creating a grub.cfg file from an installed system using e.g. grub-mkconfig but detecting then booting the installed OS like with an USB boot stick as the one created by /var/log/setup/setup.80-make-bootstick.
1) yes, the kernel hasn't got the (e)udev output available, so only knows /dev/ paths
2) kernel, grub does have limited file system support, to find kernel and initrd
3) make an initrd (ramdisk) with eudev etc IN it, to support UUID=, LABEL= etc options in the /etc/fstab file. Those are only generated BY running udev, which then creates the /dev/disk subtree. Make sure that initrd is loaded before the root partition is mounted.
3) make an initrd (ramdisk) with eudev etc IN it, to support UUID=, LABEL= etc options in the /etc/fstab file. Those are only generated BY running udev, which then creates the /dev/disk subtree. Make sure that initrd is loaded before the root partition is mounted.
Right, I ignored this option until now, but I’m curious about what exactly will have to go into the initrd. How can I find this out? Could I start from a generic-kernel initrd and just remove anything that I assume unnecessary? I know I will at least have to remove the modules that are built into the huge kernel, because they will make the kernel panic (at least, that was what happened when I accidentally attempted to boot a huge kernel with a generic-kernel initrd, long ago).
Is there an intelligent way to obtain a list of what has to go into the huge-kernel initrd, or do I have to make an educated guess until it actually works?
Is there an intelligent way to obtain a list of what has to go into the huge-kernel initrd, or do I have to make an educated guess until it actually works?
run /usr/share/mkinitrd/mkinitrd_command_generator.sh will give you a starting point.
run /usr/share/mkinitrd/mkinitrd_command_generator.sh will give you a starting point.
Sorry to return to this issue after such a long time, but doesn’t mkinitrd_command_generator.sh work on the assumption that you will be using a generic kernel? I mean, even if I pass it the filename of my huge kernel, it just gives me the same list of modules as for the generic one. That won’t work, will it?
In fact, here’s the output that mkinitrd_command_generator.sh gives me:
Code:
# /usr/share/mkinitrd/mkinitrd_command_generator.sh /boot/vmlinuz-huge-5.15.27
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:
mkinitrd -c -k 5.15.27 -f ext4 -r /dev/nvme0n1p15 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:crc32c_intel:crc32c_generic:ext4 -u -o /boot/initrd.gz
# An entry in 'etc/lilo.conf' for kernel '/boot/vmlinuz-huge-5.15.27' would look like this:
# Linux bootable partition config begins
# initrd created with 'mkinitrd -c -k 5.15.27 -f ext4 -r /dev/nvme0n1p15 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:crc32c_intel:crc32c_generic:ext4 -u -o /boot/initrd.gz'
image = /boot/vmlinuz-huge-5.15.27
initrd = /boot/initrd.gz
root = /dev/nvme0n1p15
label = 5.15.27
read-only
# Linux bootable partition config ends
As far as I can tell, there’s nothing there that will point me in any direction that gets me closer to finding out what I need to include in an initrd in order for the huge kernel to understand filesystem UUIDs.
(By the way, this issue came up again after I installed Slackware next to an existing Ubuntu system and I subsequently let Ubuntu regenerate its GRUB configuration file. It used filesystem UUIDs on all entries, which didn’t work on the Slackware generic kernel because I didn’t have an initrd yet, and it didn’t work on the huge kernel either, because that couldn’t make sense of the UUID.)
Sorry to return to this issue after such a long time, but doesn’t mkinitrd_command_generator.sh work on the assumption that you will be using a generic kernel? I mean, even if I pass it the filename of my huge kernel, it just gives me the same list of modules as for the generic one. That won’t work, will it?
Man, forget about the existence of huge kernels. Now and ever, till you use UUIDs. Take a step back and say for thousand times: there is no such thing like a huge kernel!
Because to use UUIDs on your bootloader, means that you need to use always the generic kernel and this is end of line. And the usage of an initrd with the huge kernels makes no sense.
Secondly, never, BUT never mess with the bootloader of one OS on another OS.
Eventually, use chainloading, eventually use different hard disks, BUT trust me, the Ubuntu tools mess with all configuration, not only "regenerates" its own entries.
IF those things are too complicated to you, there's always the option to use a single operating system. Slackware or Ubuntu. Your call.
Last edited by LuckyCyborg; 04-20-2022 at 03:15 PM.
Take a step back and say thousand times: there is no such thing like a huge kernel!
(Takes a step back…)
[1] “There is no such thing like a huge kernel!”
[2] “There is no such thing like a huge kernel!”
[3] “There is no such thing like a huge kernel!”
…
[998] “There is no such thing like a huge kernel!”
[999] “There is no such thing like a huge kernel!”
[1000] “There is no such thing like a huge kernel!”
Quote:
To use UUIDs on your bootloader, means that you need to use always the generic kernel and this is end of line. And the usage of an initrd with the huge kernels makes no sense.
Sounds all very logical, but I just got curious again after I got reminded of this issue. I got to wonder if there was anything interesting I could learn about it.
Quote:
Secondly, never, BUT never mess with the bootloader of one OS on another OS.
Well, if you allow me to be pedantic for a moment, then I will say that I wasn’t actually messing with the bootloader of one OS on another OS. Technically, I only had one bootloader, being the GRUB copy that got installed together with Ubuntu. But anyway, my end goal is to remove the Ubuntu GRUB copy (which turns out to be a bit harder than it sounds, because the software packages that make up GRUB must be removed in the right order, and certainly not all in one go, or you get “broken” packages due to dependency troubles.) I will compile my own GRUB copy, for which I will write my own configuration file, manually. Much easier and far more elegant, and even far less error-prone, than the mess that GRUB tends to make of it. (And if it ever does go wrong, I’ll at least know who to blame…)
Quote:
Eventually, use chainloading, eventually use different hard disks, BUT trust me, the Ubuntu tools mess with all configuration, not only "regenerates" its own entries.
Actually, that’s one of the so-called “virtues” of GRUB: It will automate the bootloader configuration process, so you won’t need to worry about it ever again.
And about chainloading: I’m not even sure at this point that that would work under UEFI. I’m assuming that the messing around that I want to undertake with getting my own GRUB copy properly installed and the Ubuntu GRUB getting removed, may well render my system unbootable a few times because I’m still unfamiliar with UEFI. In any case, it will be a learning process.
Quote:
IF those things are too complicated to you, there's always the option to use a single operating system. Slackware or Ubuntu. Your call.
Nothing complicated about this issue, as far as I’m concerned. Just a question that popped up again after all this time.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Slackware-current, huge: Kernel panic when 'root=UUID' in GRUB configuration
for a moment, then I will say that I wasn’t actually messing with the bootloader of one OS on another OS. Technically, I only had one bootloader, being the GRUB copy that got installed together with Ubuntu. But anyway, my end goal is to remove the Ubuntu GRUB copy (which turns out to be a bit harder than it sounds, because the software packages that make up GRUB must be removed in the right order, and certainly not all in one go, or you get “broken” packages due to dependency troubles.) I will compile my own GRUB copy, for which I will write my own configuration file, manually. Much easier and far more elegant, and even far less error-prone, than the mess that GRUB tends to make of it. (And if it ever does go wrong, I’ll at least know who to blame…)
