[Spike] Make UKI systemd sysext solution more robust #2630
Comments
jimmykarily
changed the title
|
Good test for this.
Hint: A way of skipping this would be to make so the agent does copy into the /EFI/kairos/active.efi.extra.d/ dir, as stub autoloads them from there. We could just store them under /EFI/kairos/sysext and make immucore move those sysext into |
|
FYI I can confirm that the workaround works. Manually copied the firmware.raw extension into /run/extensions and refreshed and magically all the firmware appeared correctly :D |
|
lol, nice, this works on systemd-256 I was able to auto copy the firmware sysext and have it autoload on boot :D |
|
Before we close this, let's bump the sizes until things break, just to know what our limit is. |
|
Depends on #2632 See also: #2595 kairos-io/packages#916 kairos-io/packages#919 |
|
Just to clarify (because I was confused), the idea here is to test how big of a file can the systemd 256 manage before it breaks. If that limit is good for us, we don't need the workaround describe by Itxaka in the Let's find out what the systemd 256 limits are first (this ticket). |
|
For the following tests, I will be creating a sysext as described in the docs and I will install with a config like this (I'm bundling the sysext in the iso as described here : Update: turns out we've implemented the SysExtPostInstallHook that automatically copies from the livecd to the right location. The Test 1 # kairos-core-ubuntu-24.04 v3.1.2-6-g3f9c2330
root@localhost:/home/kairos# du -h /efi/EFI/kairos/active.efi.extra.d/my-extension.sysext.raw
512M /efi/EFI/kairos/active.efi.extra.d/my-extension.sysext.raw
root@localhost:/home/kairos# free -h
total used free shared buff/cache available
Mem: 7.6Gi 2.9Gi 4.7Gi 2.6Gi 2.7Gi 4.6Gi
Swap: 0B 0B 0B
root@localhost:/home/kairos# du -h /usr/local/bin/bigfile
500M /usr/local/bin/bigfile
root@localhost:/home/kairos# systemctl --version
systemd 255 (255.4-1ubuntu8.4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified(500Mb sysext loads fine with 8Gb RAM - systemd 255) For the following tests I will remount the efi partition as rw, replace the sysext with a bigger one and reboot. |
|
Test 2: same setup, sysext size 1G, RAM 8G: 
it seems to be a limit of the firmware in qemu (or systemd limitation) and not the RAM size. |
|
Test 3: Installation on tumbleweed (systemd 256) shows some failures: but finishes. Update: I used one of our released images to build the uki ISO and the result is a 2.9Gb iso. That's probalby the issue and not the sysext. I will try to build something with systemd 256 which can be small enough to boot. |
|
Tumbleweed is a bit iffy if I recall my tests. I would recommend not testing in there. Even fedora 40 has some bugs so Ubuntu is the safe choice for uki |
I was trying to get a system with systemd 256 but then I realised we now have a packages 🤦 I will try again with ubuntu, I'm not sure how I ended up with system 255. I probably used the wrong image to build the uki iso. |
I ended up with 255 because we don't consume the package yet. I will do hacks to consume it and see. |
nope, we just build the systemd-boot files. @Itxaka what part of systemd 256 was expected to improve things and in which way? The only reliable flavor for uki isos is Ubuntu and that one doesn't have systemd 256, so I'm wondering, why is version 256 considered important here? My tests so far have shown that with systemd 255 in qemu, we hit the firmware limit somewhere around 500Mb. |
The loading I guess but maybe I screwed up and mixed versions? Or increased ram somehow and that made it work? Maybe we should just ignore the system version and bump memory to see if the loading is linear (i.e. with double the ram we can load double size sysext) so we can write that down? |
My example above shows that 500Mb sysext fit in 8G of RAM but 1G of sysext couldn't run in a 18Gb RAM vm, so it's not linear. |
Oh well, that sucks. So maybe there is a max allocated to the EFI implementation that we cant go over. Did you try a 800mb one? IIRC we had the same with EFI files, a max of 1Gb so it makes sense that it would be similar |
I will try more sizes and record the findings here. In any case, these are all based on qemu so the actual numbers don't really matter. If there is a limit, that limit comes from the firmware so it's value will vary. We can only gather some data points here to know what to expect (e.g. limit is the same and the OS image?). Let's see. |
|
800Mb sysext loads fine (18Gb RAM, ubuntu 24.04 VM with systemd 255): I reduced the RAM to 8G and rebooted and it still loads. RAM doesn't seem to be the limiting factor here. Update: 900Mb sysext doesn't load (fails with the usual error). |
|
Another test: I created 2 system extensions 700Mb each. As shown above, each one would otherwise load fine. I gave the VM 10G of RAM (although 8G was enough to load a sysext of 800Mb). So they extension size adds up. Splitting the files we want into separate extensions won't do the trick. |
umm, that makes sense. It generates a cpio archive on the fly if I remember the code correctly and passes it to the kernel/initramfs, which then unpacks it into the initramfs Actually we may be able to do the measurements of the sysextensions directly on immucore while we copy them from the EFI partition into the /run/systemd/extensions as we have a way of extending PCRs directly from immucore.....something to have in mind. |
|
closing as spike is done |
Instead of XBOOTLDR, we decided to go further in the path of systemd sysext}.
This ticket is to investigate the limit of this solution and find ways to support extensions as big as possible. We have reasons to believe that the system extension size is limited to a very low size (~500Mb) and we want to see if it's possible to load bigger ones.
The text was updated successfully, but these errors were encountered: