initoverlayfs
initoverlayfs copied to clipboard
containers
Working on this minimal packit test #28, seems that fedora is working with initoverlayfs, but c9s machine fails to boot. distro: CentOS Stream 9[0m kernel: 5.14.0-388.el9.x86_64[0m https://github.com/containers/initoverlayfs/pull/28/checks?check_run_id=19189680972 Need to debug...
This is just so it appears on the initoverlayfs project tracker also, this is the primary ticket: https://github.com/ostreedev/ostree/issues/3066
@eric-ch created an even smaller init system that is available here: https://gitlab.com/echanude/bareinit like bareinit, the mini-init system here uses switch root. But most modern switch roots actually use the pivot_root...
We need to verify initoverlayfs on boot, to check it's contents are correct, we must ensure whatever we use can work on a erofs file within a vfat, ext4, erofs...
If yes, try and get into Fedora, CentOS Stream 10, Automotive kernels.
In an Android Bootloader ostree deployment, we use system_a partition as the sole root partition. We have a /boot directory remaining which acts as a fake /boot partition. This is...
Udev between initrd -> rootfs, cleans the udev database and recreates it as the udev rules differ between the filesystems, Consolidate the udev rules from initrd -> initoverlayfs -> rootfs...
On fast hardware we spend 30ms each fscking /boot and /root ext4 partitions. On common Automotive hardware, this probably translates to around ~100ms. ``` systemd-analyze plot | grep -i fsck...
We must write osbuild stages for ostree-based hosts and nonostree-based hosts. We also must ensure this works with Android Bootloaders and UEFI+grub variants. So the test matrix at least initially...