Logging is important, we want our users to have logging, so make sure we
enable the new logbookd service on existing installation.
We check that we're upgrading from a postmarketos-base version that
predates logbookd and only enable the service in this case. This way we
won't enable it again for folks who disabled it manually.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
[ci:skip-vercheck]
Use logbookd to replace the busybox in-memory logger. The default
configuration of logbookd still logs in-memory but writes out the log on
shutdown or manual trigger.
The logread command is also replaced by a drop-in replacement for the
busybox tool.
The post-upgrade script in pmos-base isn't symlinked to the post-install
script, so zram-init wasn't being enabled on systems that upgraded to
the pmos-base version that intro'd this feature. I think this should
have been enabled by default on upgraded systems. There's a deviceinfo
toggle for it, so users who won't want to use this can set that var to
disable it, in that case having the service enabled is basically a
no-op.
Update by Oliver: add a comment to mention the deviceinfo variable
[ci:skip-build]: already built successfully in CI
This was a fallout from the /usr/share relocation, only found and
reported now by z3ntu. If the device package happened to be installed
later, then the link would point to the wrong location.
Fixes 1d748a93dd
Allows things like podman/docker to work out of the box.
I looked at /etc/init.d/cgroups, and having this service enabled isn't a
problem if the kernel doesn't have cgroup support... in that situation,
the service script just simply exits (success).
[ci:skip-build] already built successfully in CI
The riscv64 builder in Alpine is currently stuck, let's disable the
package for riscv64 temporarily so bpo isn't stuck on it for master. I
doubt anybody is using it on riscv64 currently.
[ci:skip-vercheck]
[ci:skip-build]: already built successfully in CI
Co-developed-by: Jakob Hauser <jahau@rocketmail.com>
Co-developed-by: Pablo Correa Gomez <ablocorrea@hotmail.com>
[ci:skip-build]: Already built successfully in CI.
As described in [0] let's switch away from RNDIS and use NCM instead.
Since we cannot force all kernels to switch at the same time, let's keep
a fallback to RNDIS in the setup function.
We can also remove usb_f_rndis from modprobe as the module gets loaded
automatically when needed, but instead we need to load libcomposite
manually so that $configfs/usb_gadget gets created.
[0] https://gitlab.com/postmarketOS/pmaports/-/issues/1797
[ci:skip-build] already built successfully in CI
Since mkinitfs / boot-deploy install sd-boot in the ESP, it makes sense
to always trigger mkinitfs when sd-boot is upgraded so that we always
boot with the latest supported version.
[ci:skip-build]: already built successfully in CI
This shows the OS version (from /etc/os-release), e.g. "edge", on the splash
screen. os-release is a tiny text file, adding it to the initramfs doesn't seem
too bad, and having this information on the splash screen can be helpful.
Note that this uses "VERSION" and not "PRETTY_NAME" from the os-release file,
since the splash already shows "postmarketOS" (and the pretty name includes
that too), it seemed redundant and took up valuable display space.
[ci:skip-build]: already built successfully in CI
Add a subpackage that sets the pmOS wallpaper, instead of always setting
the wallpaper that was added for giving GNOME Shell on Mobile a better
contrast.
Add a test for CI that:
* ensures unl0kr runs for 10 seconds without crashing
* ensures that it doesn't print any errors
This sure isn't an "ideal" test, but it at least validates that the
framebuffer interface doesn't die horribly...
With a little more effort we should be able to run unl0kr and then pull
the framebuffer and check it against some known good unl0kr screenshot.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
bootrr is a simple shell script tool for validating that a given board
has booted correctly. It checks that all expected drivers are loaded.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Enable using the postmarketOS initramfs for boot-testing devices, in
this scenario we don't care about some components like the splash, mdev,
or subpartitions, instead we want to run full udev (to load all devices)
and then run hooks. The ci hook will deadloop after running tests.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Add a helper to generate a post-install script for device pmtest
subpackages. This script configures the console and enables logging in
the initramfs for images running in CI.
[ci:ignore-count]
This package provides a helper for writing a pmtest subpackage, as well
as being a place to write generic tests that aren't specific to a device
(e.g. a suspend test).
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
[ci:ignore-count]
Add a new initramfs hook for running tests in a CI environment.
This hook automatically runs any scripts from /usr/libexec/ci-tests.
Tests should be installed as a subpackage of some other package (e.g.
qrtr) with an install_if clause to install them when this hook is
installed.
This allows platform specific packages like device packages to define
tests that will automatically be installed and executed when building
the initramfs for that device. See
device/community/device-oneplus-enchilada for an example.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Explicitly pull in the blkid package (we already added it to
00-initramfs-base.files), and replace uses of busybox findfs. Full fat
blkid supports PARTLABEL (so the /dev/disk/by-partlabel symlinks will
work consistently now), and has some nice optimisations that make the
lookup times a lot faster than busybox findfs.
[ci:skip-build]: already built successfully in CI
The "pmos_[br]oot(_uuid)?" kernel cmdline args can be used to specify
how to mount the root and boot partitions. During a previous rework, the
behaviour of these was made inconsistent (becoming dependent on the
order they were specified on the cmdline).
Undo the previous "optimisation" by splitting them back out into two
FOR loops, where the _uuid variants take precedence.
All devices that use downstream kernels should depend on this package.
We will to start with use it to fix so that lightdm+x11 work again
when using downstream kernels.
See also https://gitlab.com/postmarketOS/pmaports/-/issues/2102.
The only new thing in this version is the addition of a deprecation warning
when osk-sdl is installed in the initramfs.
Also see: https://gitlab.com/postmarketOS/pmaports/-/issues/2319
[ci:skip-build]: already built successfully in CI
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
