AIUI -- correct me if I am wrong -- this is intended for building UKI images to boot a conventional distro from a root partition, so it's not the planned usage to construct a standalone distro from it?
Generally building UKIs is the intended output, but the only thing that tells systemd to pivot into an actual root is if it boots into the `initrd.target` unit, which by default it does when `/etc/initrd-release` exists. Other than that USIs and UKIs aren't very different.
To answer the question if its planned: yes. It is officially supported to build USIs, just its not an explicit output format since its just a slightly different UKI (from a systemd perspective).
The ESP is just a FAT-32 partition, so its capable of being up to 4GB (by default).
At 4GB you can probably store most linux distributions on the ESP, so the title makes it less impressive than it is.
Technically the ESP doesn't have to be a FAT32 partition. UEFI has file system drivers installable at runtime [1], so you could have an ESP partition that isn't FAT32... assuming that the file system driver for it is loaded. UEFI implementations must have built-in support for FAT per the specification, but you'd need to slipstream any extra EFI drivers into your platform's firmware that are required to get to the ESP.
I think that ESP partitions formatted as HFS+ were a thing on Intel Macs, but I've never had one to try it out.
IIRC FAT32 is the only that needs to be supported for a valid UEFI implementation. So to actually have something like that alpine image work for most it does need to be limited to that.
There are also standalone EFI drivers that can be loaded by other means: https://archlinux.org/packages/extra/any/efifs/ (e.g. systemd-boot loads these if they are installed to `<esp>/EFI/systemd/drivers/`)
Given the specs on an esp32, or stm32 for that matter, a usable desktop should really be possible. The amiga1k didn't have anything but page protection from its mmu, and many microcontrollers can do that. The web experience would be... different, but a lot should work fine.
Yeah, you could certainly make an older OS work quite nicely on such hardware. You can even cram Linux into such devices, but it's not going to give a smooth interface
I didn't think you could get modern kernels to work eithout an mmu that supports virtual memory? In any case linux seems a bit heavy. Something based off redox might work, it has a small code base at least, but it would be a lot of work.
I made this exact thing like 2 years ago except with a custom busybox based environment, huh
It worked by building the system into the initramfs, then using a kernel feature to basically bake the initramfs into the kernel image, and then using efistub to make the kernel bootable
> Like most boot loaders, the EFI stub allows the user to specify multiple initrd files using the “initrd=” option. This is the only EFI stub-specific command line parameter, everything else is passed to the kernel when it boots
> The option is enabled by default on Arch Linux kernels, or if compiling the kernel one can activate it by setting CONFIG_EFI_STUB=y in the Kernel configuration.
> You don't "disable" systemd-boot, you just don't run it. Or you can delete the boot entry for it with efibootmgr if you want. You also don't need to "set up" EFISTUB, the stub is already built into the Arch kernels, so they're already bootable. So all you need to do is make a boot entry in your UEFI using efibootmgr with the correct kernel parameters, most likely the same ones you used for systemd-boot.
> It is recommended to always have a backup kernel. If a bootmanager like grub is already installed, it should not be uninstalled, because grub can boot a stub kernel just like a normal kernel. A second possibility is to work with an additional UEFI entry. Before installing a new kernel, the current one can be copied from /efi/EFI/example/ to /efi/EFI/backup. [And then efibootmgr]
This looks interesting and I can certainly see a use for it. It'd be very handy as a fallback/rescue system, and that includes for Windows as well as Linux.
[1]: https://overhead.neocities.org/blog/build-usi-mkosi/
Another example: https://swsnr.de/archlinux-rescue-image-with-mkosi/