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
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
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?
/etc/default/grub
grub2-mkconfig
without manual editing of the low-level config.Dynamic config, traditionally used, doesnât seem to have a disadvantage.
/etc/default/grub
etc⊠are fully supported./etc/grub.d/15_ostree
has hooks for ostree supportostree instutil
or some command, so ostree has support for itâŠ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âŠ
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.
Why not use systemd-boot in that case?
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:
/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.
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.]