forge/pmaports
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions
pmaports/main/systemd-boot/APKBUILD

119 lines
4.1 KiB
Text
Raw Normal View History

main/systemd-boot: new aport (MR 4484) EFI bootloader from systemd, with hacks to build it on Alpine/pmOS. Cross compilation (using a meson cross file) is used for building 32-bit version on x86_64, for systems that have a 32-bit EFI. Everything else assumes that the EFI arch matches the CPU arch. Besides supporting all the archs we need, another major goal was to minimize the number of changes to systemd's build system required to build only the bootloader, so that maintaining/rebasing isn't *too* painful... I am adding this to the "main" category, because I don't think there's a way to add it to Alpine. It requires cross compiling to x86 on x86_64 (to support 32-bit EFI on this arch), and Alpine doesn't support this. It requires stuff in pmaports/cross. --- Research notes --- I started looking at all of this because I wanted to come up with a single way to boot Linux via EFI, that supports all (or as many as possible) devices in pmaports. I looked at quite a few different options, and have some notes below about my observations and conclusions for each. Of everything I looked at, systemd-boot was the clear winner that met the most requirements ("pro" below) with the fewest downsides ("con" below). Using a Unified Kernel Image (UKI) was a close second place, however systemd-boot can also support booting UKI images quite easily (while also giving us more flexibility to boot other things easily too), so I think it wins over UKI. The capitalization (or lack thereof) of the "pro" and "con" markers below is significant: "PRO" / "CON" are major pros or cons for each point (e.g. a major downside that blocks using the option), and "pro"/"con" are minor (e.g. a downside that I'm willing to overlook.) ---- Requirements ---- - Arch support: - x86_64 - x86 (nice to have, but not sure if necessary...) - armv7 - aarch64 - riscv64 - EFI support: - support 32-bit EFI on x86_64 CPU (includes being able to build 32-bit .efi app on x86_64) - Easy to configure - Easy to maintain - Any changes to the bootloader required to get it working in pmOS - Config for it ---- Evaluated options ---- ------ grub ------ - (PRO) can target all required archs - (CON) grub can't be installed in pmb chroot, it calls grub-install and that fails due to something missing in /dev. Maybe this could be worked around in pmb? - (CON) grub-mkimage exe is integrated in grub package, grub-efi depends on grub - don't want to install all of grub just for 1 exe and/or the EFI modules - downsides of installing all of grub is that I think it can mislead users into thinking we use grub the "normal way". this might cause them to have the wrong expectations and break pmOS boot on their system - have POC "fixing" this - I'm not sure upstream Alpine will like this, it's ugly - (CON) grub x86 EFI support for x86_64 is currently in pmaports, that's pretty ugly. - IMHO forking grub (or grub components) for this purpose signals to me that grub is the wrong tool for this job ------- kernel's efistub ------- - (PRO) already included in the kernel, nothing else required - (pro) initrd and dtb can be passed in the kernel cmdline... however.... - (CON) kernel cmdline can only be set at compile time - (con) not all kernels may have EFISTUB set? - (con) can't do measured/secure boot - (con) requires a fairly recent kernel on aarch w/ efi_zboot support enabled since we compress the kernel ------- UKI ------- - (PRO) very simple, 1 file thing - (PRO) supports adding dtb, setting kernel cmdline and so on - (pro) can do measured/secure boot - (CON) requires an EFI stub loader - can't find a stub loader that meets all requirements (other than the one from systemd-boot...) - (con) requires efi-mkuki or dealing with objcopy directly (eww) - (con) requires a fairly recent kernel on aarch w/ efi_zboot support ------- limine ------- - (PRO) easy to install/configure, already have boot-deploy and pmaports patches - (PRO) can be cross compiled easily - evidence is in aports - ...but I couldn't reproduce building aarch64 and riscv64 on x86_64 - (pro) can do measured/secure boot (I think?) - (CON) doesn't target all required archs - can't do "linux boot" on aarch64, only "chainload" - what about using chainload everywhere? - requires using efistub in kernel - what about dtb= and upstream recommendation to not use it except for debug? - no kernel compression support on aarch64 - see efi-stub.txt kernel doc - (CON) vendors libgcc to support cross compilation - probably not a good idea to trust binaries produced in microsoft github's CI for some random project ------- stubbyboot ------- - (PRO) a straight forward stub loader - (pro) can do measured/secure boot - (CON) doesn't target all required archs - (CON) cross compiling doesn't work. - gcc can't do 32-bit on x86_64 Alpine... - gnu-efi-dev needs to be fixed to package both 32-bit and 64-bit on x86_64... - have patch in ~/src/aports that kinda does it.. but needs to be fixed/finished - maybe limine-efi works with it? - tried, but fails due to missing efilib.h in limine-efi ------- systemd-stub ------- - (PRO) another straight forward stub loader - (PRO) many (many) people using it, as part of systemd-boot - (pro) can do measured/secure boot - (con) requires a fairly recent kernel on aarch w/ efi_zboot support enabled since we compress the kernel - (con) doesn't target all required archs - but does claim to support most... missing armv7.. maybe it works? - (con) will end up maintaining some downstream patch to build it - hopefully the patch (if I can even make a working one!) is not too complex! - (CON) can't be built outside of systemd's silly large build system. - UPDATE: largely resolved this in pmaports - was able to build for native arch! - can't build 32-bit on x86_64, no gcc multilib support in Alpine... Couldn't get clang to work properly, but maybe it can somehow... - https://github.com/mintsuki/libgcc-binaries ? NO! (don't want bootloader binaries that depend on code compiled by microsoft / github...) ------- DIY stub / bootloader ----- - (PRO) **might** target all required archs and other meet requirements - (CON) lots of time required to learn, design, do, debug, test - (CON) lots of time required to learn, design, do, debug, test - (CON) lots of time required to learn, design, do, debug, test - (CON) (get the hint yet???) - (CON) written in C, probably (there's a rust EFI lib, lol...) [ci:skip-build]: Already built successfully in CI
2023-10-06 19:52:53 +00:00
# Contributor: Clayton Craft <clayton@craftyguy.net>
# Maintainer: Clayton Craft <clayton@craftyguy.net>
#
# Notes:
# - Builds / packages *only* the EFI boot manager and stub loader, and any
# useful apps for managing those things.
# - The goal with the systemd patch and this package is *NOT* to create the
# fastest build possible (e.g. by hacking up meson a bunch).
# - The goal is to create the smallest diff from upstream so that rebasing
# this is as easy as possible.
# - If you can figure out how to have both, great!!! Otherwise, installing
# some extra build-time junk and waiting for a long meson configure step
# is an acceptable price to pay for not having to rebase a bunch of stuff.
#
pkgname=systemd-boot
main/systemd-boot: upgrade to 255 (MR 4651) - Dropped patch that was merged upstream - Rebased other patches [ci:skip-build]: Already built successfully in CI.
2023-12-09 21:21:55 +00:00
pkgver=255
pkgrel=0
main/systemd-boot: new aport (MR 4484) EFI bootloader from systemd, with hacks to build it on Alpine/pmOS. Cross compilation (using a meson cross file) is used for building 32-bit version on x86_64, for systems that have a 32-bit EFI. Everything else assumes that the EFI arch matches the CPU arch. Besides supporting all the archs we need, another major goal was to minimize the number of changes to systemd's build system required to build only the bootloader, so that maintaining/rebasing isn't *too* painful... I am adding this to the "main" category, because I don't think there's a way to add it to Alpine. It requires cross compiling to x86 on x86_64 (to support 32-bit EFI on this arch), and Alpine doesn't support this. It requires stuff in pmaports/cross. --- Research notes --- I started looking at all of this because I wanted to come up with a single way to boot Linux via EFI, that supports all (or as many as possible) devices in pmaports. I looked at quite a few different options, and have some notes below about my observations and conclusions for each. Of everything I looked at, systemd-boot was the clear winner that met the most requirements ("pro" below) with the fewest downsides ("con" below). Using a Unified Kernel Image (UKI) was a close second place, however systemd-boot can also support booting UKI images quite easily (while also giving us more flexibility to boot other things easily too), so I think it wins over UKI. The capitalization (or lack thereof) of the "pro" and "con" markers below is significant: "PRO" / "CON" are major pros or cons for each point (e.g. a major downside that blocks using the option), and "pro"/"con" are minor (e.g. a downside that I'm willing to overlook.) ---- Requirements ---- - Arch support: - x86_64 - x86 (nice to have, but not sure if necessary...) - armv7 - aarch64 - riscv64 - EFI support: - support 32-bit EFI on x86_64 CPU (includes being able to build 32-bit .efi app on x86_64) - Easy to configure - Easy to maintain - Any changes to the bootloader required to get it working in pmOS - Config for it ---- Evaluated options ---- ------ grub ------ - (PRO) can target all required archs - (CON) grub can't be installed in pmb chroot, it calls grub-install and that fails due to something missing in /dev. Maybe this could be worked around in pmb? - (CON) grub-mkimage exe is integrated in grub package, grub-efi depends on grub - don't want to install all of grub just for 1 exe and/or the EFI modules - downsides of installing all of grub is that I think it can mislead users into thinking we use grub the "normal way". this might cause them to have the wrong expectations and break pmOS boot on their system - have POC "fixing" this - I'm not sure upstream Alpine will like this, it's ugly - (CON) grub x86 EFI support for x86_64 is currently in pmaports, that's pretty ugly. - IMHO forking grub (or grub components) for this purpose signals to me that grub is the wrong tool for this job ------- kernel's efistub ------- - (PRO) already included in the kernel, nothing else required - (pro) initrd and dtb can be passed in the kernel cmdline... however.... - (CON) kernel cmdline can only be set at compile time - (con) not all kernels may have EFISTUB set? - (con) can't do measured/secure boot - (con) requires a fairly recent kernel on aarch w/ efi_zboot support enabled since we compress the kernel ------- UKI ------- - (PRO) very simple, 1 file thing - (PRO) supports adding dtb, setting kernel cmdline and so on - (pro) can do measured/secure boot - (CON) requires an EFI stub loader - can't find a stub loader that meets all requirements (other than the one from systemd-boot...) - (con) requires efi-mkuki or dealing with objcopy directly (eww) - (con) requires a fairly recent kernel on aarch w/ efi_zboot support ------- limine ------- - (PRO) easy to install/configure, already have boot-deploy and pmaports patches - (PRO) can be cross compiled easily - evidence is in aports - ...but I couldn't reproduce building aarch64 and riscv64 on x86_64 - (pro) can do measured/secure boot (I think?) - (CON) doesn't target all required archs - can't do "linux boot" on aarch64, only "chainload" - what about using chainload everywhere? - requires using efistub in kernel - what about dtb= and upstream recommendation to not use it except for debug? - no kernel compression support on aarch64 - see efi-stub.txt kernel doc - (CON) vendors libgcc to support cross compilation - probably not a good idea to trust binaries produced in microsoft github's CI for some random project ------- stubbyboot ------- - (PRO) a straight forward stub loader - (pro) can do measured/secure boot - (CON) doesn't target all required archs - (CON) cross compiling doesn't work. - gcc can't do 32-bit on x86_64 Alpine... - gnu-efi-dev needs to be fixed to package both 32-bit and 64-bit on x86_64... - have patch in ~/src/aports that kinda does it.. but needs to be fixed/finished - maybe limine-efi works with it? - tried, but fails due to missing efilib.h in limine-efi ------- systemd-stub ------- - (PRO) another straight forward stub loader - (PRO) many (many) people using it, as part of systemd-boot - (pro) can do measured/secure boot - (con) requires a fairly recent kernel on aarch w/ efi_zboot support enabled since we compress the kernel - (con) doesn't target all required archs - but does claim to support most... missing armv7.. maybe it works? - (con) will end up maintaining some downstream patch to build it - hopefully the patch (if I can even make a working one!) is not too complex! - (CON) can't be built outside of systemd's silly large build system. - UPDATE: largely resolved this in pmaports - was able to build for native arch! - can't build 32-bit on x86_64, no gcc multilib support in Alpine... Couldn't get clang to work properly, but maybe it can somehow... - https://github.com/mintsuki/libgcc-binaries ? NO! (don't want bootloader binaries that depend on code compiled by microsoft / github...) ------- DIY stub / bootloader ----- - (PRO) **might** target all required archs and other meet requirements - (CON) lots of time required to learn, design, do, debug, test - (CON) lots of time required to learn, design, do, debug, test - (CON) lots of time required to learn, design, do, debug, test - (CON) (get the hint yet???) - (CON) written in C, probably (there's a rust EFI lib, lol...) [ci:skip-build]: Already built successfully in CI
2023-10-06 19:52:53 +00:00
pkgdesc="systemd's EFI boot manager and stub"
url="https://systemd.io/"
# TODO:
# armv7: untested
# riscv64: untested
# x86: untested (and unnecessary?)
arch="x86_64 aarch64"
license="GPL-2.0-only"
# Some of these are just to satisfy systemd's meson config, and aren't actually
# used for building the boot manager or stub...
makedepends="
bash
coreutils
gperf
meson
py3-elftools
py3-jinja2
"
source="
systemd-$pkgver.tar.gz::https://github.com/systemd/systemd/archive/refs/tags/v$pkgver.tar.gz
0001-meson-minimal-configure-for-building-systemd-boot.patch
0002-fix-wchar-for-compiling-on-musl.patch
cross-x86.meson
"
options="!check" # no tests
subpackages="ukify"
# TODO: cross-native fails on, e.g. aarch64, elf2efi gets an "unknown section
# with name '' " ...
# Maybe because meson thinks(?) the linker doesn't support norelro? It does
# when building the default way!
# Using meson cross files is a lot faster! But the whole thing is pretty small,
# so, meh.
# options="!check pmb:cross-native" # no tests
builddir="$srcdir/systemd-$pkgver"
case "$CARCH" in
# TODO: This doesn't work locally, pmboostrap's depends parser doesn't
# evaluate/consider shell stuff...
x86_64)
makedepends="$makedepends gcc-x86 musl-dev-x86"
;;
esac
build() {
abuild-meson \
-Dsbat-distro="postmarketOS" \
-Dsbat-distro-pkgname="$pkgname" \
-Dsbat-distro-summary="postmarketOS" \
-Dsbat-distro-url="postmarketos.org" \
-Dsbat-distro-version="$pkgver" \
. output
meson compile -C output systemd-boot
# Some x86_64 systems have 32-bit EFI, so cross compile the bootloader for
# 32-bit when building for this CARCH
# TODO: this should use systemd/meson.build's ability to cross-compile
# (setting meson "efi_arch_alt"). The check for that currently fails
# because the linker can't find the i586/32-bit stuff. Setting
# LIBRARY_PATH=/usr/lib/gcc/i586-alpine-linux-musl didn't work.
if [ "$CARCH" == "x86_64" ]; then
abuild-meson \
-Dsbat-distro="postmarketOS" \
-Dsbat-distro-pkgname="$pkgname" \
-Dsbat-distro-summary="postmarketOS" \
-Dsbat-distro-url="postmarketos.org" \
-Dsbat-distro-version="$pkgver" \
--cross-file "$srcdir"/cross-x86.meson \
. output.32
meson compile -C output.32 systemd-boot
fi
}
package() {
mkdir -p "$pkgdir"/usr/lib/systemd/boot/efi
mv output/src/boot/efi/linux*.efi.stub \
"$pkgdir"/usr/lib/systemd/boot/efi/
mv output/src/boot/efi/systemd*.efi \
"$pkgdir"/usr/lib/systemd/boot/efi/
if [ "$CARCH" == "x86_64" ]; then
mv output.32/src/boot/efi/linux*.efi.stub \
"$pkgdir"/usr/lib/systemd/boot/efi/
mv output.32/src/boot/efi/systemd*.efi \
"$pkgdir"/usr/lib/systemd/boot/efi/
fi
}
ukify() {
depends="binutils py3-pefile"
install -Dm755 "$builddir"/src/ukify/ukify.py \
"$subpkgdir"/usr/bin/ukify
}
sha512sums="
main/systemd-boot: upgrade to 255 (MR 4651) - Dropped patch that was merged upstream - Rebased other patches [ci:skip-build]: Already built successfully in CI.
2023-12-09 21:21:55 +00:00
51728de604c2169d8643718ac72acb8f70f613cfcca9e9abb7dac519f291fa26a16d48f24cae6897356319096cfe8f4d9377743e7870127374f98d432e0c557c systemd-255.tar.gz
f68d60956d689711b2790ff0cb41ec2ff0560915f1891183cbe93850e4e9f82878d9ecdc4e6a8c9fa5251a699bad629bff4c1d2f90c5e8f6b0fb162dd149b0e4 0001-meson-minimal-configure-for-building-systemd-boot.patch
1470afad196b4a7a98f7d640956d834dfe2dfa829731211a09757785c456599b8cefcc6121c8f466c11b7cb668248e2f2d5d305f025f16c07f958f1465ee21e2 0002-fix-wchar-for-compiling-on-musl.patch
main/systemd-boot: new aport (MR 4484) EFI bootloader from systemd, with hacks to build it on Alpine/pmOS. Cross compilation (using a meson cross file) is used for building 32-bit version on x86_64, for systems that have a 32-bit EFI. Everything else assumes that the EFI arch matches the CPU arch. Besides supporting all the archs we need, another major goal was to minimize the number of changes to systemd's build system required to build only the bootloader, so that maintaining/rebasing isn't *too* painful... I am adding this to the "main" category, because I don't think there's a way to add it to Alpine. It requires cross compiling to x86 on x86_64 (to support 32-bit EFI on this arch), and Alpine doesn't support this. It requires stuff in pmaports/cross. --- Research notes --- I started looking at all of this because I wanted to come up with a single way to boot Linux via EFI, that supports all (or as many as possible) devices in pmaports. I looked at quite a few different options, and have some notes below about my observations and conclusions for each. Of everything I looked at, systemd-boot was the clear winner that met the most requirements ("pro" below) with the fewest downsides ("con" below). Using a Unified Kernel Image (UKI) was a close second place, however systemd-boot can also support booting UKI images quite easily (while also giving us more flexibility to boot other things easily too), so I think it wins over UKI. The capitalization (or lack thereof) of the "pro" and "con" markers below is significant: "PRO" / "CON" are major pros or cons for each point (e.g. a major downside that blocks using the option), and "pro"/"con" are minor (e.g. a downside that I'm willing to overlook.) ---- Requirements ---- - Arch support: - x86_64 - x86 (nice to have, but not sure if necessary...) - armv7 - aarch64 - riscv64 - EFI support: - support 32-bit EFI on x86_64 CPU (includes being able to build 32-bit .efi app on x86_64) - Easy to configure - Easy to maintain - Any changes to the bootloader required to get it working in pmOS - Config for it ---- Evaluated options ---- ------ grub ------ - (PRO) can target all required archs - (CON) grub can't be installed in pmb chroot, it calls grub-install and that fails due to something missing in /dev. Maybe this could be worked around in pmb? - (CON) grub-mkimage exe is integrated in grub package, grub-efi depends on grub - don't want to install all of grub just for 1 exe and/or the EFI modules - downsides of installing all of grub is that I think it can mislead users into thinking we use grub the "normal way". this might cause them to have the wrong expectations and break pmOS boot on their system - have POC "fixing" this - I'm not sure upstream Alpine will like this, it's ugly - (CON) grub x86 EFI support for x86_64 is currently in pmaports, that's pretty ugly. - IMHO forking grub (or grub components) for this purpose signals to me that grub is the wrong tool for this job ------- kernel's efistub ------- - (PRO) already included in the kernel, nothing else required - (pro) initrd and dtb can be passed in the kernel cmdline... however.... - (CON) kernel cmdline can only be set at compile time - (con) not all kernels may have EFISTUB set? - (con) can't do measured/secure boot - (con) requires a fairly recent kernel on aarch w/ efi_zboot support enabled since we compress the kernel ------- UKI ------- - (PRO) very simple, 1 file thing - (PRO) supports adding dtb, setting kernel cmdline and so on - (pro) can do measured/secure boot - (CON) requires an EFI stub loader - can't find a stub loader that meets all requirements (other than the one from systemd-boot...) - (con) requires efi-mkuki or dealing with objcopy directly (eww) - (con) requires a fairly recent kernel on aarch w/ efi_zboot support ------- limine ------- - (PRO) easy to install/configure, already have boot-deploy and pmaports patches - (PRO) can be cross compiled easily - evidence is in aports - ...but I couldn't reproduce building aarch64 and riscv64 on x86_64 - (pro) can do measured/secure boot (I think?) - (CON) doesn't target all required archs - can't do "linux boot" on aarch64, only "chainload" - what about using chainload everywhere? - requires using efistub in kernel - what about dtb= and upstream recommendation to not use it except for debug? - no kernel compression support on aarch64 - see efi-stub.txt kernel doc - (CON) vendors libgcc to support cross compilation - probably not a good idea to trust binaries produced in microsoft github's CI for some random project ------- stubbyboot ------- - (PRO) a straight forward stub loader - (pro) can do measured/secure boot - (CON) doesn't target all required archs - (CON) cross compiling doesn't work. - gcc can't do 32-bit on x86_64 Alpine... - gnu-efi-dev needs to be fixed to package both 32-bit and 64-bit on x86_64... - have patch in ~/src/aports that kinda does it.. but needs to be fixed/finished - maybe limine-efi works with it? - tried, but fails due to missing efilib.h in limine-efi ------- systemd-stub ------- - (PRO) another straight forward stub loader - (PRO) many (many) people using it, as part of systemd-boot - (pro) can do measured/secure boot - (con) requires a fairly recent kernel on aarch w/ efi_zboot support enabled since we compress the kernel - (con) doesn't target all required archs - but does claim to support most... missing armv7.. maybe it works? - (con) will end up maintaining some downstream patch to build it - hopefully the patch (if I can even make a working one!) is not too complex! - (CON) can't be built outside of systemd's silly large build system. - UPDATE: largely resolved this in pmaports - was able to build for native arch! - can't build 32-bit on x86_64, no gcc multilib support in Alpine... Couldn't get clang to work properly, but maybe it can somehow... - https://github.com/mintsuki/libgcc-binaries ? NO! (don't want bootloader binaries that depend on code compiled by microsoft / github...) ------- DIY stub / bootloader ----- - (PRO) **might** target all required archs and other meet requirements - (CON) lots of time required to learn, design, do, debug, test - (CON) lots of time required to learn, design, do, debug, test - (CON) lots of time required to learn, design, do, debug, test - (CON) (get the hint yet???) - (CON) written in C, probably (there's a rust EFI lib, lol...) [ci:skip-build]: Already built successfully in CI
2023-10-06 19:52:53 +00:00
ad54e2c7e7a21bfa9b5f9e8db1b6af6a6d78a3e5dfe2dafcec77488f6224865ab4d4c8a8c8ee1c54c99d1741361e9fb3a51e5d36bcbc7a1c3fdcc4d0c1672132 cross-x86.meson
"
Reference in a new issue Copy permalink