Draft: RFC: add package that installs grub-efi images
This generates grub efi application images for multiple archs, and allows installing a grub efi image on a host with a different arch (e.g. x86 efi app on x86_64 system)
I'm pretty sure that using arch="any", etc is not the best way to package this, so I'm open to suggestions.
Also, maybe something like this would fit better in Alpine, but I wanted to make the MR here so we can discuss it more.
This depends on https://gitlab.com/postmarketOS/boot-deploy/-/merge_requests/27, this branch includes a boot-deploy APKBUILD patch to build boot-deploy with the branch in that MR.
This also requires a pmbootstrap patch.
I'm not happy with how deviceinfo vars for boot stuff have been handled (using generate in the name for those vars is kinda misleading, imho). I would much rather use some format for those vars like: deviceinfo_<bootloader>_<bootloader-specific config used by bootdeploy>, and so I used new vars with this format in both the patch here, the changes in boot-deploy, and the patch in pmbootstrap that I'll submit on the mailing list shortly.
The motivation for this is to simplify how pmOS configures x86 and x86_64 systems that use EFI boot. With this change, device packages will no longer need to provide a grub.cfg, or generate a grub EFI app image. boot-deploy is able to also properly inject kernel cmdline params from deviceinfo too (currently device packages that provide a grub.cfg are hard-coding kernel cmdline params...)
pmbootstrap patch: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230507022014.25135-1-clayton%40craftyguy.net%3E
Merge request reports
Activity
This will obviously require changes to other x86 / x86_64 devices that EFI boot, but I'll hold off on making those changes until we can agree whether this approach is good, or if further changes are necessary. This way I don't have to rebase constantly to keep a collection of device packages updated in this branch
By clayton craft on 2023-05-07T02:22:00
- main/grub-efi-img/APKBUILD 0 → 100644
21 _mkimage() { 22 23 mkdir -p "$srcdir/out" 24 25 local _grub_arch="$1" 26 local _efi_arch= 27 case "$1" in 28 x86_64) 29 _efi_arch="x64" 30 ;; 31 i386) 32 _efi_arch="ia32" 33 ;; 34 esac 35 36 grub-mkimage \ -
another reason to not do this in boot-deploy, is taht it would require installing grub on the system, at least in the rootfs (grub-install shouldn't be run... since boot-deploy would handle that part). So having grub laying around in the rootfs would take up space and it might be confusing to someone who sees it and thinks that pmOS is using grub-install, etc.
By clayton craft on 2023-05-07T05:13:35
- main/grub-efi-img/APKBUILD 0 → 100644
18 19 # Generates a grub efi app in $srcdir/out 20 # $1: grub arch 21 _mkimage() { 22 23 mkdir -p "$srcdir/out" 24 25 local _grub_arch="$1" 26 local _efi_arch= 27 case "$1" in 28 x86_64) 29 _efi_arch="x64" 30 ;; 31 i386) 32 _efi_arch="ia32" 33 ;; - main/grub-efi-img/grub_early.cfg 0 → 100644
1 search --no-floppy --set=root --label "pmOS_boot" -
I think, when we just use slash without any early configs, grub uses the partition where it is booted from
But i've never actually checked it
By jenneron on 2023-05-07T02:27:32
-
Ok right off the bat I can see that the way this grub-efi-img package is configured won't work since it's trying to build on other archs, which makes sense... lol.
Another idea I had was to generate the efi image for both x86 and x86_64 and have a single package that targets archs x86 and x86_64...
By clayton craft on 2023-05-07T02:24:05
-
Regarding grub-early.cfg: we need to generate this in boot-deploy, so we can put the UUID of the partition where grub lies into it, so grub loads the modules from the correct partition.
Right now we have in
cross/grub-x86/grub_early.cfg:search --no-floppy --set=root --label "pmOS_boot" set prefix=($root)/grubBut this leads to problems when there are two partitions with a pmOS_boot label, e.g. after installing to eMMC and booting from SD card.
Related: #1531
By Oliver Smith on 2023-06-04T07:35:35
Edited by Ghost User
added status::mr-stale label
-
Sorry to bother you @craftyguy,
but we've detected that this merge request hasn't seen any recent activity. If you need help or want to discuss your approach with developers you can ping
@postmarketOS. You can also ask on matrix in #devel:postmarketos.org or #postmarketos-devel on OFTC. If no further activity occurs in this MR, postmarketOS developers may close it in the future.Thanks for your contribution.
By * postmarketOS Bot on 2023-07-06T13:00:02