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...
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.
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/`)
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).
38 comments
[ 0.24 ms ] story [ 35.5 ms ] threadIn hindsight "fitting into" a microcontroller does also work, sort of...
That is correct -- thanks. I did not think it was ambiguous in context. Silly me.
https://github.com/ESP32DE/Boot-Linux-ESP32S3-Playground
"20 MB Linux.EFI" ...
Download 25MB ...
Leads to 26MB download file ...
Holds a compressed partition of 209 MB.
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
https://github.com/uapi-group/specifications/blob/main/specs...
Kernel docs > admin-guide/efistub: https://docs.kernel.org/admin-guide/efi-stub.html :
> 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
Arch Wiki > EFISTUB: https://wiki.archlinux.org/title/EFISTUB :
> 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.
eaut/efistub is a script for managing signed efistubs: https://github.com/eaut/efistub
... Systemrescuecd can be PXE booted (netbooted) from tftpd managed by Cobbler or Foreman.
From "Booting Linux off of Google Drive" https://news.ycombinator.com/item?id=40853770#40859485 re: signing and iPXE
Ventoy boots via grub/efi but there are blobs: https://news.ycombinator.com/item?id=40619822#40620279
"Ask HN: Where can I find a primer on how computers boot?" https://news.ycombinator.com/item?id=35230852
systemd-boot and grub support booting to efistubs
"Migrate from systemd-boot to EFISTUB" https://www.reddit.com/r/archlinux/comments/14jt8yv/migrate_... :
> 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.
Fedora > Changes/Unified_Kernel_Support_Phase_2 > Switch_an_existing_install_to_use_UKIs: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor... :
https://github.com/spxak1/weywot/blob/main/guides/fedora_sys... : - "No more boot loader: Please use the kernel instead" https://news.ycombinator.com/item?id=40907933Gentoo wiki > EFI_stub https://wiki.gentoo.org/wiki/EFI_stub :
> 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...
Shame it's not been updated in so long.
I think that ESP partitions formatted as HFS+ were a thing on Intel Macs, but I've never had one to try it out.
[1] rEFInd's website lists a bunch of available file system drivers: https://www.rodsbooks.com/refind/drivers.html#selecting
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/`)
So now you're asking your users not only to bless the EFI loader, but also to resize their ESP, and most likely system partition.
[1]: https://overhead.neocities.org/blog/build-usi-mkosi/
Another example: https://swsnr.de/archlinux-rescue-image-with-mkosi/
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).
Source here: https://github.com/zhovner/OneFileLinux/
This is crying out for an update, IMHO.
https://etcha.dev/etchaos
EtchaOS is for building a custom immutable distro, but it is a conventional distro with a root partition.
This is a distro which doesn't have a root partition. It doesn't just boot from the UEFI ESP: it fits entirely into it, with no other partitions.
UKIs and similar are nice but don't play well with secure boot (unless you setup your own signing) and BIOS boot.
This is the last I've heard of such an effort: https://www.cnx-software.com/2019/12/03/western-digital-risc...