Grub2 on Silverblue: No flicker-free boot

Ask Fedora
, ,
1

I just revealed that my Fedora 42 Installation does not longer boot flicker-free. The boot menu is shown for one second and than the Message

`Booting Fedora Linux 42.xxxxx (Silverblue) (ostree:0)´

after running echo 'set timeout_style="hidden"' | sudo tee -a /boot/grub2/user.cfg the issue is fixed. But i’m not sure, if this is the right approach for fixing it this way.

according grubenv there are no variables defined.

This happens on my Dell machine as well on a KVM VM.

i have an older Lenovo Installation upgraded since 3x, to verion 42, too, that has the following Variables set:

# grub2-editenv - list

menu_auto_hide=1
boot_success=1
boot_indeterminate=0

on this installation, /etc/default/grub is also still present.

any clues?

Thanks!

3

/etc/default/grub is missing on Silverblue 41 fresh install may be relevant and contain useful information.

4

Thank you @hricky. This changes everything. But i am unsure about the results. My upgraded, now static grub config looks completely different compared to a new installed system.

sudo head /boot/grub2/grub.cfg from my current, upgraded system

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set pager=1

New install:

# This file is copied from https://github.com/coreos/coreos-assembler/blob/0eb25d1c718c88414c0b9aedd19dc56c09afbda8/src/grub.cfg
# Changes:
#   - Dropped Ignition glue, that can be injected into platform.cfg
# petitboot doesn't support -e and doesn't support an empty path part
if [ -d (md/md-boot)/grub2 ]; then
  # fcct currently creates /boot RAID with superblock 1.0, which allows
  # component partitions to be read directly as filesystems.  This is
  # necessary because transposefs doesn't yet rerun grub2-install on BIOS,
  # so GRUB still expects /boot to be a partition on the first disk.
  #

did i miss something?

according to the logs, it was converted during upgrade:

Apr 18 21:17:26 systemd[1]: Starting bootloader-update.service - Update bootloader on boot...
Apr 18 21:17:26 bootupctl[1331]: No update available for any component.
Apr 18 21:17:26 bootupctl[1377]: ostree repo 'sysroot.bootloader' config option is not set yet
Apr 18 21:17:26 bootupctl[1377]: Marking bootloader as BLS capable...
Apr 18 21:17:26 bootupctl[1377]: Migrating to a static GRUB config...
Apr 18 21:17:26 bootupctl[1377]: Creating a backup of the current GRUB config '/boot/grub2/../loader/grub.cfg' in '/boot/grub2/grub.cfg.backup'...
Apr 18 21:17:26 bootupctl[1377]: Stripping ostree generated entries from GRUB config...
Apr 18 21:17:26 bootupctl[1377]: GRUB config symlink successfully replaced with the current config
Apr 18 21:17:26 bootupctl[1377]: Setting 'sysroot.bootloader' to 'none' in ostree repo config...
Apr 18 21:17:26 bootupctl[1377]: Static GRUB config migration completed successfully
Apr 18 21:17:26 systemd[1]: Finished bootloader-update.service - Update bootloader on boot.
Apr 18 21:49:21 systemd[1]: bootloader-update.service: Deactivated successfully.
Apr 18 21:49:21 systemd[1]: Stopped bootloader-update.service - Update bootloader on boot.
5

This is as expected. We could not replace the existing config with the ones we are using for new installations without risking loosing users customization, so the statically migrated config looks different.

1 Like
6

Thanks you for clarification.

Now, there is only one question left:

Was this the right approach? And shouldn’t this be set as standard for all Desktop New installations to improve UX?

OK, now we have two questions. :wink:

7

Yes it should. /etc/default/grub is missing on Silverblue 41 fresh install linked earlier here points to Bootupd installation is missing `/boot/grub2/grubenv` · Issue #746 · coreos/bootupd · GitHub which is the issue tracking this.