/etc/default/grub is missing on Silverblue 41 fresh install

Ask Fedora
, , ,
21

This is my latest iteration which gives me the best menu with my 4k workstation.

set gfxmode=800x600
insmod gfxterm
set gfxpayload=keep
terminal_input gfxterm
terminal_output gfxterm

1 Like
22

Despite a shift to static config, ostree still supports the dynamic config generation.
/etc/grub.d/15_ostree

Is there a specific reason to use the static config?

  • It doesn’t support themes
  • It doesn’t support os-prober
  • It easily gets overwritten by 99% of grub-involved scripts like theme installs
  • It doesn’t support the well-known /etc/default/grub grub2-mkconfig without manual editing of the low-level config.

Dynamic config, traditionally used, doesn’t seem to have a disadvantage.

  • Themes, /etc/default/grub etc
 are fully supported.
  • /etc/grub.d/15_ostree has hooks for ostree support
  • Above script uses ostree instutil or some command, so ostree has support for it

  • Most users wouldn’t notice if the static config is overwritten


So is there a reason to prefer static config over dynamic?

Atleast, the static config should support more resolutions, cover up the ugly menu to a simple systemd-boot-like theme, or just use systemd-boot if something is complicated


23

As far as I know, the migration to a static GRUB config is part of the ComposeFS support, which in turn is related to the transition to Bootable Containers.

24

Why not use systemd-boot in that case?

25

The dynamic config approach is fragile and a source of a lot of our previous issues with GRUB.

It’s my medium term plan to switch to systemd-boot, but some things need to happen before we can do that:

  • it would have to be signed by the Fedora key
  • support in ostree / bootc
  • support in bootupd
  • migration for existing systems
  • etc.
1 Like
26

/lib/systemd/systemd-sbsign or /usr/bin/sbsign.
It can’t be done on user’s system though as exposing the signing key would be dangerous.

Is very much easier than supporting GRUB. A trivial shell script if all are lazy. [kernel-install has the scripts]

IDK, but I don’t think it will be more difficult than GRUB. It has optional helper services like systemd-bless-boot.service though.

Is it an actual issue? Yes, it isn’t atomic, but again, it isn’t a major chore.

Some info:

Installation: [A basic script, just to let know]
[AVOID bootctl; It doesn’t support installing SHIM, but is does at detecting]

#!/usr/bin/env bash
set -euo pipefail

BOOTPART=$(bootctl -x)
BOOTPART=${BOOTPART:-$(bootctl -p)}
# SDBOOTEFIFILE= # somewhere under /lib/systemd/boot
EFITREEFILE=fedora/grubx64.efi # Adjust as needed to systemd-bootx64.efi

cp  ${SDBOOTEFIFILE} ${BOOTPART}/${EFITREEFILE}

if ! [ -e ${BOOTPART}/boot/bootx64.efi ]
then cp ${SDBOOTEFIFILE} ${BOOTPART}/boot/bootx64.efi
fi

## SHIM installation as usual in GRUB; no changes

Refer kernel-install scripts for generating entries [Type#1].

sbsign or /lib/systemd/systemd-sbsign supports signing.

# I needn’t talk about the key and mokutil and all


You can even prepare UKIs


Most of the logic is already written in kernel-install scripts, and it would be trivial to re-implement then in C or whatever language.

And it is actually easier than GRUB.

AND it has less moving parts to break, so don’t expect maintenance burdens.

AND it has a sane non-ugly-hackers-console theme. [GRUB’s you can’t change f41 onwards in atomic desktops
 and moreover all themes are too console-like or flashy.]