Skip to content
Skip to the article
In Proxmox: 1 article
Proxmox

Install, Pin, and Configure Proxmox VE Kernels

Install an opt-in Proxmox kernel, pin or unpin a kernel version, and change the kernel command line on GRUB or systemd-boot hosts.

Updated
Applies to
  • Proxmox VE 8
  • Proxmox VE 9
Tags
  • proxmox
  • kernel
  • systemd-boot
  • grub
Reading time
4 min

Proxmox VE ships its own kernel packages, which include ZFS and are tested with the rest of the platform. When you need newer hardware support, you can install one of the newer opt-in kernels, pin the host to a known-good version, and adjust kernel parameters. Run the commands as root on the node.

Note

Older notes installed Debian backports kernels (linux-image-amd64 with zfs-dkms) on Proxmox. Don't do that on current releases. Proxmox's opt-in kernels give you the same newer hardware support with ZFS built in and without DKMS rebuilds.

Check the Running Kernel and Installed Kernels

uname -r
proxmox-boot-tool kernel list

Install an Opt-in Kernel

Proxmox publishes newer kernels as opt-in packages, announced on the Proxmox forum. For example, proxmox-kernel-7.0 on Proxmox VE 9 or proxmox-kernel-6.14 on Proxmox VE 8:

apt update
apt install proxmox-kernel-<VERSION>
reboot

Once installed, later builds of that kernel series arrive with normal updates. Opt-in kernels are less tested than the default series, so try them on one node first.

Pin a Kernel Version

By default, the node boots the newest installed kernel. To boot a specific version instead, for example to stay on a kernel that works with a particular NIC or GPU driver, pin it. Use the exact version string from proxmox-boot-tool kernel list:

proxmox-boot-tool kernel pin <KERNEL_VERSION>

To try a kernel for a single boot only, so a failed boot falls back on the next reboot:

proxmox-boot-tool kernel pin <KERNEL_VERSION> --next-boot

Remove the pin to go back to booting the newest kernel:

proxmox-boot-tool kernel unpin

Pinning works with both GRUB and systemd-boot.

Change the Kernel Command Line

Where kernel parameters go depends on the bootloader. Find out which one the host uses:

proxmox-boot-tool status
efibootmgr -v

efibootmgr shows systemd-bootx64.efi for systemd-boot, and grubx64.efi or shimx64.efi for GRUB. On a legacy BIOS host, it reports that EFI variables aren't supported, which means GRUB. In practice, ZFS-on-root installs booting in UEFI mode without Secure Boot use systemd-boot, and everything else uses GRUB.

systemd-boot

Edit /etc/kernel/cmdline. It's a single line, so append parameters to the end:

root=ZFS=rpool/ROOT/pve-1 boot=zfs intel_iommu=on iommu=pt

Then copy the change to every boot partition:

proxmox-boot-tool refresh

GRUB

Edit GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

Then regenerate the GRUB config:

update-grub

After rebooting, confirm the parameters took effect with cat /proc/cmdline.

Warning

Kernel and command-line changes can leave a node unbootable. Keep console or IPMI access available, migrate or shut down guests first, and on a cluster change one node at a time.

Disabling CPU Vulnerability Mitigations

Some performance guides suggest adding mitigations=off to the kernel command line. It turns off the kernel's protections against Spectre, Meltdown, and related CPU flaws, which can win back a few percent of CPU performance on older processors.

Warning

On a hypervisor, mitigations=off lets code in one VM potentially read memory from the host or from other VMs. Never use it on hosts that run untrusted guests, customer workloads, or anything exposed to the internet. Measure the actual gain before considering it on an isolated lab host.

Sources

This article is in the public domain (CC0 1.0), code samples included. Use it however helps you.