@stsquad I've spent a couple of days this week trying to move away from cross compiling #boot2container using qemu-user in favor of proper cross compilation... Just because it keeps on getting flakier and flakier in terms of performance and has a nasty tendency of just hanging when compiling go code...
Of course, cross compiling Go programs relying on CGO is another can of worm... Looking at you, #podman and #uroot!
I got it to work in the end, but decided not to go this route and just compile natively instead... Which sucks for riscv64... but I have a visionfive2 I can use for that.
Hopefully some more Go fixes could make emulation less of a pain!
Pour le fédivers Francophone:
Voici une présentation, faite par mon ami et contributeur Vincent Autefage, de #boot2container. Ce projet open source est un initramfs contenant #podman et permettant de démarrer des conteneurs sans installation préalable d'un système d'exploitation (très utile pour les tests de pilotes dans un environnement CI).
#boot2container v0.9.13 is out 🥳
This initramfs embeds #podman 5.3 and allows you to run one or more containers, entirely configured via the kernel command line... which is perfect for #linux driver testing in CI as every job gets full control of its test environment without having to re-download/deploy it at every boot nor influencing other jobs!
It runs on any AMD64, AARCH64, ARMv6, or RISCV64 computer running a recent Linux kernel.
Get it while it's fresh at https://gitlab.freedesktop.org/gfx-ci/boot2container/-/releases/v0.9.13
This release brings massive improvements related to running boot2container on diskless computers (swap over NBD, using NFS to access a shared read-only image store), and introduces REST-configured suspend/hibernation/timeouts...
Achievement unlocked: Booting a CI system in an hotel room... on another continent... with 4 DUTs (RPi5, VisionFive2, HDK8550, and a Steam Deck)... over WiFi !
Tune to our demo at #xdc2024 to see more: https://indico.freedesktop.org/event/6/contributions/301/
#ci-tron #boot2container
@cas Just to be clear: the EFI image would be the rootfs + kernel that the user would flash on one partition of their main storage?
We can't have full disk images unless the board has u-boot flashed in an SPI memory, right?
In any case, good luck, this will also help #boot2container (the OS part) / boot2ipxe (the firmware part) \o/
@siosm Fun and very useful, great work!
So, if I understand correctly, the container is downloaded and extracted by the current OS, then the initrd will pivot to an overlayfs at boot?
Did you re-use the container runtime at all? Any possibility to download and extract the container images at boot time, à la #boot2container?
@craftyguy @calebccff @igalia Unglamorous changes? Dude, initramfses are SEXY! 
But why I am not surprised you worked on this :D? Missing #boot2container already?
#boot2container v0.9.9 is out 🥳
The new version of this initramfs brings in #podman 4.3, better flexibility for iface configuration, support for loading containers without registries, and the ability to run fstrim at boot time.
However, what really excites me about this release is that it should now (net)boots on upstream-supported aarch64 platforms such as the #raspberrypi 4, as long as your bootloader is EFI-compatible (tianocore works).
Get it while it is fresh at https://gitlab.freedesktop.org/mupuf/boot2container/-/releases/v0.9.9
This release brings major improvements to the arm64/aarch64 users, complex network environments, and offline operations! Probably the most interesting aspect of this release is being able...
Martin Roukala (né Peres)
Martin Roukala (né Peres)