User:Pietinger/Tutorials/Kernel Commandline Parameter

From Gentoo Wiki
Jump to:navigation Jump to:search

I wrote this article so that I can link to it in the Gentoo forums if users have questions about it.

Tutorial: Kernel Commandline Parameter

This is a short overview how you can give your kernel some parameters. Main difference is how you boot your kernel: Using a bootmanager (like grub) or using UEFI (booting a stub kernel directly).

A list of all possible parameters kernel will understand is here: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

What always work

Independent how you boot your kernel you can always "hardcode" needed parameters into your kernel directly with (EXAMPLE):

KERNEL
Processor type and features  --->
    [*] Built-in kernel command line
    (root=/dev/sda3 ro)

Using grub

Edit in /etc/default/grub the variable GRUB_CMDLINE_LINUX. See more here: GRUB#Setting_configuration_parameters

Using UEFI

Configure your UEFI boot entry with additional options when creating this entry (EXAMPLE]:

root #efibootmgr -c -d /dev/sda -p 1 -L "Gentoo" -l '\efi\gentoo\bzImage.efi' -u 'root=/dev/sda3 ro'

See more here: Efibootmgr#Creating_a_boot_entry

Can I mix it ?

Yes, you can give your kernel some parameters via built-in command line and some more via grub or UEFI. Kernel will put both informations together (at boot-time). But it is not recommended. Maybe there exists some special constellations where you need it. If you dont want that your bootmanager or UEFI will add (or even override) your built-in commandline parameters (for security reasons) you must enable this:

KERNEL
Processor type and features  --->
    [*]     Built-in command line overrides boot loader arguments

Parameter: root=

Why it is not recommended to use root=/dev/sdXY ?

Because it could confuse your kernel. This can happen if you have two (or more) hard disks in your system. Then it could be that sometimes your 2nd harddisk becomes /dev/sda and your first harddisk is /dev/sdb and then kernel will not find its root partition on /dev/sda3 because this is now the 3rd partiton of your 2nd harddisk. Another problem can occure if you have an USB-stick attached to your system when booting. Here it is also possible your harddisk becomes /dev/sdb instead /dev/sda.

So I should always use root=PARTUUID=... ?

Yes, it is better (more safe), BUT there is one exception: If you use an initramfs it could be you must use root=UUID=... instead. Of course then you must use the real UUID and not the PARTUUID. Here you will find an explanation for this: User:Pietinger/Tutorials/Confusion_with_root=PARTUUID=_and_root=UUID=

Just ask for the PARTUUID (or UUID) with Util-linux#blkid.

By the way: The same is true for your /etc/fstab. I recommend to label your partitions if you have a GPT disk. I did this with:

root #parted /dev/sda name 1 ESP

and now I use these:

FILE /etc/fstab
PARTLABEL=ESP           /efi            vfat    defaults,noauto,noatime                 1 2
PARTLABEL=Root          /               ext4    defaults,noatime,iversion               0 1
PARTLABEL=Swap          none            swap    sw                                      0 0

Of course you can use also "PARTUUID=" or "UUID=", but dont use "LABEL=" for a GPT disk. See more here: fstab#UUIDs_and_labels

Parameter: quiet

With this command line parameter you can suppress most output of your kernel when booting. If you still see some warnings and think this parameter does not work then read this kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=217226

Parameter: initrd=

This parameter specify the location of the initial ramdisk (initrd) or initial ram filesystem (initramfs) and is a very special parameter. You will need it if you want boot a kernel with an associated external initramfs (=CPIO archive). The special thing about this parameter is that you can/may NOT configure it in the built-in kernel command line (it would reach the kernel too late there). This means that if you use an external initramfs, you MUST configure it either in the UEFI or the bootloader/bootmanager. I have explained it in more detail here: https://forums.gentoo.org/viewtopic-p-8805827.html#8805827

(Attention: This post was written BEFORE Gentoo did the change of the ESP mountpoint from /boot to /efi)

Parameter: rootwait

Wait (indefinitely) for root device to show up. Useful for devices that are detected asynchronously (e.g. USB and MMC devices). You can use also rootwait= which specifies the maximum time (in seconds) to wait for root device to show up before attempting to mount the root filesystem. (This parameter should be preferred over rootdelay=)

Parameter: lsm.debug

Enable LSM initialization debugging output. It shows you more informations about your Linux Security Modules in your dmesg (and doesn't hurt).

Parameter: ipv6.disable=1

Disables IPv6 in the kernel completely.

Parameter: nomodeset

NEVER USE THIS parameter ... unless you want a black screen after booting. I don't know where this nonsensical recommendation to set this parameter comes from. Read more about it in the above link to the kernel docs.

Parameter: earlycon=efifb and others

You will need this only for debugging purposes (it slows down the kernel start considerably). In our Gentoo dist-kernel all options for this are already activated in the kernel; however, if you have configured the kernel yourself, you will need:

KERNEL
Device Drivers  --->
    Character devices  --->
        Serial drivers  --->
            [*] 8250/16550 and compatible serial support
            [*]   Console on 8250/16550 and compatible serial port

You can combine this parameter with others: earlycon=efifb efi=debug initcall_debug ignore_loglevel keep_bootcon

Read the description for these in: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

It has helped in this forum thread: https://forums.gentoo.org/viewtopic-p-8827678.html#8827678

If you have a kernel panic and your system does an immediately reboot then you have set a "-1" in your options. With a "0" the kernel will not reboot after a kernel panic:

KERNEL
Kernel hacking  --->
    Debug Oops, Lockups and Hangs  --->
        (0) panic timeout

See also