Adding a kernel parameter and regenerating grub config on a silverblue system


#1

Hello.
I need to know how can I add a kernel parameter to the kernel commandline on a Fedora silverblue system.
I am trying to install silverblue on a laptop but I need to add few kernel parameters before it gets updated to latest 4.19 kernel or things will break.
Also I am trying to regenerate grub config using the command sudo ostree admin instutil grub2-generate but it gives a “no boot device found” error.

Is there any way to add a kernel parameter like adding it on /etc/default/grub on normal system?

grub2-mkconfig actually creates a wrong config on UEFI systems. It uses linux16 and initrd16 instead of linux and initrd command respectively.


#2

Got it. It was there where I expected the least.

rpm-ostree kargs --editor and that without root password!


#3

Hi Jeet,

Another way of doing this is to use grubby.

Edit by @dustymabe: Please don’t use grubby as it does not integrate with ostree and your added kernel arguments may get lost. See Colin’s response below.

Try running:

sudo grubby --default-kernel

On my system this gives an output of the following (warning: it could be different on yours):

/boot/ostree/fedora-workstation-65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/vmlinuz-4.19.6-300.fc29.x86_64

You can then add a kernel parameter (for example “amdgpu.ppfeaturemask=0xffffffff”) using the following command:

sudo grubby --args=“amdgpu.ppfeaturemask=0xffffffff” --update-kernel /boot/ostree/fedora-workstation-65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/vmlinuz-4.19.6-300.fc29.x86_64

Reboot using:

systemctl reboot

On reboot you can then check if it has been added by running the following command:

sudo grubby --info /boot/ostree/fedora-workstation-65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/vmlinuz-4.19.6-300.fc29.x86_64

On my machine I get the following output:

index=0
kernel=/boot/ostree/fedora-workstation-65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/vmlinuz-4.19.6-300.fc29.x86_64
args=“resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet ostree=/ostree/boot.1/fedora-workstation/65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/0”
root=/dev/mapper/fedora-root
initrd=/boot/ostree/fedora-workstation-65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/initramfs-4.19.6-300.fc29.x86_64.img
title=Fedora 29.20181209.0 (Workstation Edition) 29.20181209.0 (ostree)

The change will persist even when you update the kernel to a newer one.

To remove a parameter (for example “amdgpu.ppfeaturemask=0xffffffff”) you can running the following:

sudo grubby --remove-args=“amdgpu.ppfeaturemask=0xffffffff” --update-kernel /boot/ostree/fedora-workstation-65b19cb39930782c7c954d1ec8b5aabd339ed2845bab6e583b6755dfe889b865/vmlinuz-4.19.6-300.fc29.x86_64

I hope this helps you.


#4

Interesting. Thanks. BTW. Do you know why usermod -a -G $GROUPNAME $USERNAME doesn’t work on silverblue?


#5

See https://github.com/projectatomic/rpm-ostree/issues/1318 and https://github.com/projectatomic/rpm-ostree/issues/49


#6

No, don’t do that; grubby doesn’t integrate with ostree; it’s a bug actually that we ship it. Hm, in fact:

# rpm -q --whatrecommends grubby
crypto-policies-20181026-1.gitd42aaa6.fc29.noarch

Ugh, going to go send a patch to remove that. (edit: patch here)


#7

Interesting. I wonder what is meant by %posts are run on the server side.


#8

It means that the %post section of an RPM is run when the ostree compose is being done (i.e on the compose server) rather than on the client side (i.e. your host).

This is different than traditional RPM/yum/dnf where all the RPM %post stuff is done on your host when you are doing an install.


#9

Does %post still run on the compose server when package layering is done?


#10

Not exactly. The package layering operation is something that is done client side; you don’t talk to the (remote) compose server to generate a new compose for you.

But the client can create a new ostree commit that includes the base compose (already on your host) and the new layered packages. In this case, the %post would technically run on the client (i.e. your host), however it is sandboxed from your running deployment. Just like when you do an upgrade, the new files are checked out into a new deployment (aka new ostree commit) and does not disrupt your running system.


#11

Thanks for the explaination. :slight_smile:


#12

Thanks for the heads up Colin