Installkernel, chroot detection check

[n1c3guy3dd13]

Hi. Sorry if there is a better place to ask this. I attempted an install recently, and I came across an error I don't think I've encountered before.

This bug summarizes it nicely: https://bugs.gentoo.org/971572

Overriding the check seems to clear up the kernel install.

This might be a rabbit hole while I look through wiki pages and wait for updates to the handbook.

I typically run OpenRC with GRUB. Does the grub-mkconfig take care of the kernel command line parameters in the end?

If I wanted to look into parameters, this is probably a good place to start? https://wiki.gentoo.org/wiki/Kernel/Com ... eters#GRUB

Should I just keep with the override instead of looking into kernel command line parameters (keep it simple/ignorance is bliss)?

Thank you in advance.

[zen_desu]

Hi. Sorry if there is a better place to ask this. I attempted an install recently, and I came across an error I don't think I've encountered before.

This bug summarizes it nicely: https://bugs.gentoo.org/971572

Overriding the check seems to clear up the kernel install.

This might be a rabbit hole while I look through wiki pages and wait for updates to the handbook.

I typically run OpenRC with GRUB. Does the grub-mkconfig take care of the kernel command line parameters in the end?

If I wanted to look into parameters, this is probably a good place to start? https://wiki.gentoo.org/wiki/Kernel/Com ... eters#GRUB

Should I just keep with the override instead of looking into kernel command line parameters (keep it simple/ignorance is bliss)?

Thank you in advance.

I think grub-mkconfig may read cmdline stuff from /proc/cmdline which is likely to have info for the livecd which will not work if you use dracut on your system. Grub can set root= info a variety ways "automagically"

this is mostly specific to setups using dracut and possibly UKIs, but the key is that you need to specify some cmdline info or things (other than ugrd) will try to autodetect using the current /proc/cmdline

using /proc/cmdline can be a reliable source of info but a notable example of where it is not is when chrooted and booted using a livecd
Failing to account for this can cause boot errors that are a bit tricky to diagnose

[n1c3guy3dd13]

Thank you for your insight, especially the bit about GRUB being automagical in its ways.

I am going to keep things simple and use the

Code: Select all

touch /etc/kernel/preinst.d/05-check-chroot.install

to allow the distribution kernel to install (at least until I read otherwise).

Also related to GRUB and the boot process, from what I'm reading, and high level:

UEFI will start GRUB
GRUB will load the kernel into memory
Kernel will do magic, mount file systems (i.e. / as rw)

GRUB can find my root partition, and I don't feel the need to fuss.

Ultimately, in my case, kernel command line parameters don't appear to play any significant role in my startup.

[zen_desu]

you're welcome, the explanation was a bit handwavey and i looked into it a bit more, and this cmdline config in particular would mostly apply if you're using a UKI with grub.

The cmdline set in the grub config if not using a uki should be respected by the kernel/initramfs, but you have to be sure it's correct. grub's automagic can sometimes do things like try to use paths when device mapper based devices are used (like luks or lvm) instead of using a UUID which can be unreliable depending on the setup.

[Nowa]

Just to add here for others bumping into this issue. In my opinion the best way to continue when hitting this problem is not to blindly override the check, but to tell dracut to not include a kernel cmdline in the initramfs (hostonly_cmdline=no). The check is there for good reason and if you change your setup later in a way where it does rely on the included dracut cmdline then this check might save you from having to boot into a rescue usb to recover your system.