Pass boot arguments to a QEMU-launched Linux kernel by configuring the virtual machine’s firmware interface, such as GRUB or UEFI, rather than using command-line append flags. This approach allows persistent configuration changes within the guest environment that survive reboots and do not require modifying the host-side QEMU invocation script every time settings change.
Understanding the Limitation of -append
The standard method for passing kernel parameters involves adding
-append "console=ttyS0" to the QEMU command line. While effective for quick debugging, this method is ephemeral; any change requires editing the host command string. For users seeking a more integrated solution where the guest operating system manages its own boot parameters, relying on the bootloader inside the virtual machine is the correct architectural choice. This separation ensures that the guest kernel behaves identically whether it is booted via QEMU, KVM, or physical hardware.
Configuring GRUB for Persistent Arguments
Most standard Linux distributions use GRUB (Grand Unified Bootloader) as their primary bootloader. To pass arguments without touching QEMU, you must edit the GRUB configuration file on the guest system. This method is particularly useful when you are performing incremental Linux kernel upgrades or managing specific kernel headers, as described in related guides on kernel management.
First, access the guest operating system via SSH or a serial console provided by QEMU. Once logged in, open the GRUB configuration file using a text editor with root privileges. The file is typically located at
/etc/default/grub. Look for the variable named
GRUB_CMDLINE_LINUX_DEFAULT. This variable contains the default set of arguments passed to the kernel during normal boot operations.
For example, if you need to enable verbose boot logging or specify a different console device, modify this line. Change:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
To:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash console=ttyS0"
After saving the file, you must update the GRUB configuration to apply these changes. Run the following command depending on your distribution:
- For Debian-based systems like Ubuntu or Kali:
sudo update-grub
- For Red Hat-based systems like Fedora or CentOS:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
This process ensures that every time the guest boots, the kernel receives the specified arguments directly from the bootloader, eliminating the need for host-side injection.
Handling Kernel Headers and Upgrades
When modifying boot parameters, ensure that the necessary kernel modules are available. If you are working with custom kernels or specific driver requirements, you may need to install corresponding kernel headers. Properly configured boot arguments can help isolate cores or manage system resources, which is critical when dealing with complex kernel tasks or isolated core assignments. Always verify that your current kernel version supports the arguments you are passing.
Using Serial Console for Debugging Without Append
A common reason developers want to pass boot args is to enable a serial console for debugging purposes. Instead of using
-append, you can configure the guest to output its console messages to a virtual serial port that QEMU exposes. This is often more stable than trying to force video console output during early boot stages.
In the guest's GRUB configuration, add
console=ttyS0 to the command line as shown above. Then, ensure that the kernel has support for serial ports compiled in. On the QEMU side, you do not need to pass arguments via
-append. Instead, define the serial device in your QEMU startup script or XML definition (if using libvirt). For example:
-serial stdio
Or in an XML configuration:
<serial type='pty'>
<target port='0'/>
</serial>
This setup allows the guest kernel to write its boot logs to the standard input/output of the QEMU process, providing visibility into the boot sequence without cluttering the graphical display or requiring host-side parameter injection.
UEFI and OVMF Considerations
If you are using UEFI instead of legacy BIOS, the process differs slightly. Modern QEMU installations often use OVMF (Open Virtual Machine Firmware). In this case, you cannot edit a simple text file like
/etc/default/grub because the bootloader might be loaded differently or managed by systemd-boot.
For UEFI systems, you typically need to modify the NVRAM variables or edit the EFI boot entries directly. Use tools like
efibootmgr inside the guest to view and modify boot options. Add your desired kernel parameters to the specific boot entry. For instance:
efibootmgr --create --gpt --disk /dev/sda --part 1 --label "Linux" --unicode "\vmlinuz root=/dev/sda1 console=ttyS0 quiet"
This method persists across reboots and does not rely on the host QEMU command line. It is essential for environments where security policies prevent modification of host-side scripts, ensuring that all boot-time configurations are contained within the guest's secure boot chain.
Netconsole as an Alternative
Another robust alternative to local serial consoles is netconsole. This allows the kernel to send log messages over the network to a remote server. Configure this in the guest's GRUB parameters by adding
netconsole=@IP_OF_SERVER/eth0,@PORT/DEST_MAC/IFACE_IP. This is particularly useful for headless servers where direct console access is difficult. Ensure that the network interfaces are correctly configured in the guest before rebooting, as misconfiguration can lead to boot failures.
Frequently Asked Questions
Why should I avoid using -append for permanent changes?
Using
-append ties your kernel configuration to the specific QEMU launch script, making it hard to maintain across different host machines or automation scripts. Configuring the guest bootloader ensures consistency regardless of how the VM is started.
Can I mix GRUB and UEFI boot methods?
No, you must choose one firmware interface per installation. Switching between BIOS/GRUB and UEFI/OVMF after installation can break the boot process. It is best to decide on the firmware type during the initial OS installation.
What happens if I make a typo in the GRUB config?
If the kernel parameters are invalid, the system may fail to boot. You can usually recover by selecting the previous kernel version from the GRUB menu or by using a live USB to edit the
/etc/default/grub file again.
Does netconsole work with encrypted disks?
Yes, netconsole operates at the kernel level before the root filesystem is mounted. However, you must ensure that the network drivers required for netconsole are built into the kernel image itself, not loaded as external modules, to guarantee availability during early boot.
How do I verify that boot args were applied?
After the system boots, check the contents of
/proc/cmdline using the command
cat /proc/cmdline. This file displays the exact arguments the running kernel received during startup, allowing you to confirm your changes took effect.