On Thu, Feb 14, 2019 at 5:06 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Feb 12, 2019 at 5:08 AM Javier Martinez Canillas > <javier@xxxxxxxxxxxx> wrote: > > You are correct, we will work on more documentation and also better > > tooling to manage the BLS snippets, grubenv file, etc. For example > > grub2-editenv is very fragile as was mentioned in this thread. > > I'm looking at this: > https://docs.fedoraproject.org/en-US/fedora/f29/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/ > > I'm noticing that grubby on F30 is actually grubby-bls. On the one hand: > Yes. The grubby-bls script supports all the grubby options for backward compatibility, but under the hood it just manages the BLS snippets. > # grubby --set-default /boot/vmlinuz-5.0.0-0.rc5.git0.1.fc30.x86_64 > # cat /boot/efi/EFI/fedora/grubenv > # GRUB Environment Block > saved_entry=8a6804fc8b1447b49bf2b522e419f2ae-5.0.0-0.rc5.git0.1.fc30.x86_64 > [snip] > > That appears to work. However, > > [chris@localhost ~]$ sudo grubby --remove-args=quiet That's not a valid grubby command, even for the old grubby tool: $ sudo grubby --info=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 | grep args args="ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet" $ sudo grubby --remove-args=quiet grubby: no action specified $ sudo grubby --update-kernel=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 --remove-args=quiet $ sudo grubby --info=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 | grep args args="ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb" > [chris@localhost ~]$ sudo cat /boot/efi/EFI/fedora/grubenv > [snip] > kernelopts=root=/dev/mapper/fedora_localhost--live-root ro > resume=/dev/mapper/fedora_localhost--live-swap > rd.lvm.lv=fedora_localhost-live/root > rd.luks.uuid=luks-8dc728e5-4420-4f90-a1c5-aaf87a69d88b > rd.lvm.lv=fedora_localhost-live/swap rhgb quiet > boot_indeterminate=0 > > That doesn't work. Nor does --remove-args="quiet" - nor is there an > error message. It just fails silently. And the --args argument doesn't > appear to add arguments to the grubenv (or the bls snippets), also > fails silently. Is it a bug? > Yes, the tool not printing an error message is a bug. I've fixed it now, thanks a lot for reporting this. The following will work with the new grubby script (and also the old grubby tool): $ sudo grubby --info=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 | grep args args="ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet" $ sudo grubby --update-kernel=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 --remove-args=quiet $ grubby --info=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 | grep args args="ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb" Now, the grubby script doesn't work as you expected it. The $kernelopts variable in grubenv is used to set a kernel command line that's shared by all the BLS snippets, that allows you to have a single place where you can update the cmdline for all the entries. You have two ways to update this: 1) Using grub2-editenv set option 2) Setting GRUB_CMDLINE_LINUX in /etc/default/grub and running grub2-mkconfig again. Option (2) is what most people are used to and what we have documented in many places, so we supported for backward compatibility. The grub2-mkconfig tool will set $kernelopts with the value in GRUB_CMDLINE_LINUX. The grubby script (and the old grubby tool) are used to change individual boot entries. So you need to specify a kernel with --update-kernel (you can also specify DEFAULT for the default entry or ALL to update all the entries). Since the $kernelopts is shared by all the entries, the grubby script can't change, since that will affect all the others. So what we decided in this case is to make the grubby-bls script to copy-on-write the kernel cmdline. That is, when you change an cmdline for an entry it will expand the $kernelopts variable, do the changes and store the modified cmdline in the BLS options field instead of $kernelopts. So from now on the modified entry won't share the $kernelopts anymore and will have it's own cmdline. Any changes to $kernrelopts won't affect this entry anymore and the grubby script should be used for any future updates. As an example: $ sudo grep kernelopts /boot/grub2/grubenv kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet $ sudo grep options /boot/loader/entries/036f3661be4047b6b678d491f76df6f4-5.0.0-0.rc6.git0.1.fc30.x86_64.conf options $kernelopts $ sudo grubby --update-kernel=/boot/vmlinuz-5.0.0-0.rc6.git0.1.fc30.x86_64 --remove-args=quiet $ sudo grep kernelopts /boot/grub2/grubenv kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet $ sudo grep options /boot/loader/entries/036f3661be4047b6b678d491f76df6f4-5.0.0-0.rc6.git0.1.fc30.x86_64.conf options root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb > Is grubby-bls intended as the primary tool for changing these things? In the short term yes. And provide better docs that clearly explain how all this works. > Long term or short term? > In the medium term our plan is to provide better tooling for this. Having two tools to update the kernel cmdline (grub2-editenv and grubby) is not intuitive. So our plan is to have a library + command line tool for configuring everything related to the bootloader. We will keep grub2-editenv and the grubby script for backward compatibility, maybe they could just be a wrapper on top of this new tool. > > -- > Chris Murphy Best regards, Javier _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
