OneFileLinux: A 20MB Alpine metadistro that fits into the ESP | Hacker News Reader

OneFileLinux: A 20MB Alpine metadistro that fits into the ESP

hub.zhovner.com

92 pointslproven37 comments

Fun fact: you can easily create your own USIs (Unified system image), which basically does the same (is the same concept?), with mkosi[1].

[1]: https://overhead.neocities.org/blog/build-usi-mkosi/

Another example: https://swsnr.de/archlinux-rescue-image-with-mkosi/

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.

[1] rEFInd's website lists a bunch of available file system drivers: https://www.rodsbooks.com/refind/drivers.html#selecting

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/`)

I guess one could do something like put a large ext4 file image on the FAT32 partition and mount that from within Linux.

Except most ESP partitions I have seen are in the 200MB range.

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.

[OP here]

Source here: https://github.com/zhovner/OneFileLinux/

This is crying out for an update, IMHO.

Slight difference between EFI and ESP. Works on my EFI laptop, my ESP32 board wasn’t having it.

https://en.wikipedia.org/wiki/EFI_system_partition

Yup, that.

In hindsight "fitting into" a microcontroller does also work, sort of...

In this context ESP = EFI System Partition

[OP here]

That is correct -- thanks. I did not think it was ambiguous in context. Silly me.

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.

You’re joking but you can run Linux on the ESP32-S3

https://github.com/ESP32DE/Boot-Linux-ESP32S3-Playground

Ohhhhh! Yeah the "ESP can be up to 4GB" had me totally lost. Like, no, the ones we use have 4MB of flash.

And here I was secretly hoping someone managed to make a minimal MMU-free linux distro to run on ESP32.

This is the last I've heard of such an effort: https://www.cnx-software.com/2019/12/03/western-digital-risc...

There's a version for the ESP32-S3: https://github.com/ESP32DE/Boot-Linux-ESP32S3-Playground

That's just incredible! Thank you so much for sharing :)

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

Do you happen to remember what that kernel feature was called? I did something very similar, and it'd be cool to have one fewer file to deal with.

UKI, maybe?

https://github.com/uapi-group/specifications/blob/main/specs...

Efistub

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... :

  dnf install virt-firmware uki-direct kernel-uki-virt
  kernel-bootcfg --show

https://github.com/spxak1/weywot/blob/main/guides/fedora_sys... :

  sudo dracut -fvM --uefi --hostonly-cmdline --kernel-cmdline "root=UUID=b6b8fa59-92cc-4d03-8d8f-d66dab76d433 ro rootflags=subvol=root resume=UUID=fb661671-97dc-45db-b720-062acdcf095e rhgb quiet mitigations =off"

- "No more boot loader: Please use the kernel instead" https://news.ycombinator.com/item?id=40907933

Gentoo 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 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]

That option is CONFIG_INITRAMFS_SOURCE, see https://www.kernel.org/doc/html/latest/filesystems/ramfs-roo... .

Yeah, it was this

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.

Shame it's not been updated in so long.

If your looking for something similar only for distributions like Debian, Ubuntu, Fedora etc checkout EtchaOS:

https://etcha.dev/etchaos

Not really the same thing or even comparable, AFAICS, no.

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.

In EtchaOS, the entire distro is contained within the initrd file. So I guess it's technically two files, kernel and initrd, but still similar.

UKIs and similar are nice but don't play well with secure boot (unless you setup your own signing) and BIOS boot.

Slightly misleading title

"20 MB Linux.EFI" ...

Download 25MB ...

Leads to 26MB download file ...

Holds a compressed partition of 209 MB.

I don't think it's that misleading, bzImage and the like are comressed, so...

It is a little surprising given alpine images are regularly less than 10MB.

They are compressed too, right?

I'm not sure. The only thing in there besides busy box and apj is the kernel and a bunch of text files.

Reply on news.ycombinator.com