Open adrelanos opened 9 months ago
Also the grub installation need refactoring. Not sure I should discuss this here or in a separate issue.
grml-debootstrap
currently relies on packages
(-arm64
) file to install package grub2-common
.packages-arm64
file currently contains grub2-common
, grub-efi-arm64
but not grub-efi-arm64-signed
.grml-debootstrap
installs grub-efi-arm64-bin
, grub-efi-arm64-signed
but not grub2-common
. This breaks builds with a custom packages-arm64
not including grub2-common
.grml-debootstrap
currently only checks if grub-efi-arm64-signed
needs installation and then installs grub-efi-arm64-bin
and grub-efi-arm64-signed
. However, if a packages file had only grub-efi-arm64-signed
but not grub-efi-arm64-bin
, that would also not work. Might see as a nitpick but I want to find a nice, clean design because that might allow to support all architectures supported by grub. (At least theoretically. Testing these might need later CI enhancements adding additional tests if there is any interest.)These inconsistencies should be fixed.
What should it be? Options:
packages
file which contains architecture specific packages such as bootloader packages. Or,packages
does not need to list these but then grml-debootstrap
will auto-detect and auto-install all that is required.A) has the advantage that it simplifies grml-debootstrap's code but more messy with lots of files, one per architecture. Then we should think about a shared packages file supplemented by architecture specific packages files. B) Might be possible with a switch, case code block setting different package to install and command line options. I think that might be better because options will be different anyhow depending on the architecture.
After https://github.com/grml/grml-debootstrap/pull/255 was merged, I'll attempt to send a PR but I need your on guidance on how a PR would need to look like.
grub-efi-arm64-bin
is also being installed too late by grml-debootstrap
. The following... if [ -n "$ARM_EFI_TARGET" ]; then
einfo "Installing Grub as bootloader into EFI."
chroot "${MNTPOINT}" grub-install --target=arm64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck --no-nvram --removable
...runs before any package installation. That code only comes later below in the same function.
if [ -n "$ARM_EFI_TARGET" ]; then
needs a special case.elif [[ -z "${GRUB}" ]] || ! dd if="${GRUB}" bs=512 count=1 2>/dev/null | cat -v | grep -Fq GRUB; then
High mental load. I would like to simplify that.
chroot-script
also conditionally does grub-install
.@adrelanos I fully agree that we should refactor this, to unify and simplify behavior as much as possible while keeping code minimal and simple as well. I'll try to take care of #255 so you're not blocked by that :)
The following code should be refactored, simplified.
Maybe the VMEFI and ARM64 code paths could be merged.
EFI
andESP
are currently labels.1MiB 101MiB
(or the larger sizes discussed in #221)'mkpart bios_grub 101MiB 102MiB'
and'set 2 bios_grub on'
also for--arm64
if that works. Not sure if there are any ARM64 legacy BIOS booting systems,but all of these changes are for code simplification purposes so this code and related code that comes later can be simplified.
Also maybe the grub installation code can be refactored but perhaps that can be discussed separately.
Why? This would fix or simplify the following issues:
221