OneFileLinux: A tiny recovery distro that fits snugly in your EFI system partition

OneFileLinux is a very different sort of distro that runs entirely from your UEFI system partition, without a bootable USB key or any other partitions on the disk. The OneFileLinux project has been inactive for a few years now, but it does work – and we feel that the concept is inspired. It points to the sort of thing that …

[Throatwarbler Mangrove]

Kernel recompiles

"He vividly recalls compiling his own kernels to precisely match his hardware, eliminating the need for any supplementary files. This was standard practice in the 1990s."

Trepanning and circumcision with a sharp rock used to be standard practices as well. Thankfully, they are no longer.

[Liam Proven]

Re: Kernel recompiles

Well, yes, certainly.

The thing is, I'd expect it to be automated away after 30+ years, rather than (IMHO) rather ugly hacks to try to cram the whole ugly mess into a single file.

[Richard 12]

Re: Kernel recompiles

Indeed, surely it's easy for a distro to boot from a 'generic' kernel, then detect what's (semi) permanently installed, automatically build a 'custom' kernel with all that rolled in, along with every acceleration feature of that specific CPU, and use that for subsequent boots until a 'notable' hardware change is detected.

Though perhaps it just doesn't make much difference anymore. Cache lines are bigger than they used to be.

[Neil Barnes]

Re: Kernel recompiles

True, but the presence of bigger cache lines, bigger storage, bigger ram, faster processors have all led directly to code which requires those facilities to run.

It strikes me, for instance, that Word takes longer to fire up than Wordstar did in the eighties... admittedly it does more, but the basic functionality is the same.

It might not make a difference, but there's such a thing as elegance in design...

[Tom Chiverton 1]

Re: Kernel recompiles

You can't boot a kernel you built yourself with Microsoft's secure boot enabled, because it'll fail the DRM checks.

[david 12]

Re: Kernel recompiles

You can't boot a kernel you built yourself with Microsoft's secure boot enabled, because it'll fail the DRM checks.

Yes, that would certainly prevent you from booting windows on an unsigned Linux kernel.

But that's hardly the only thing that prevents you from loading Windows on a Linux kernel.

[CrazyOldCatMan]

Re: Kernel recompiles

I too remember recompiling new kernels of fit my hardware (started with slackware then Mandrake/Mandriva then early Ubuntu - at which point I gave up doing it because the PCs I was using were big and powerful enough that it didn't make any difference any more...)

And as for the "pack the initrd into the ESR" thing - if Lennart Poettering has his paws on it then it's a firm nil points from me.

[Lennart Sorensen]

Re: Kernel recompiles

Sure it could be automated. But no one has, because it serves no purpose to do it. It is a waste of time to compile a kernel on all sorts of machines. The generic ones run just as well because the kernel developers are fortunately a lot smarter about these things than random users. Modules are just as fast as built in and you can change hardware easily using new drivers and when an update is ready you just have to install it, without wasting time (and other resources) compiling a kernel for no benefit. The kernel is perfectly capable of selecting optimized versions of routines where it matters, and for the rest you don't bother.

We don't have to go back to the dumb old days (Remember windows 95 needed a reboot to apply any network settings? Wow was that ever dumb. Computers in the past were generally a lot dumber than today).

[Anonymous Coward]

Re: Kernel recompiles

Sharp rocks! You were lucky! When I was a lad all we had were hard to maneuver "Raymond Luxury Yacht" fast rotating impellers ... we thanked god every single day for Mountain Dew!

[Bebu]

adjacent is ... systemd creator Lennart Poettering

A bit like saying "design inspired by Bergholt Stuttley Johnson "

[Bebu]

Nothing new under the sun* :)

Then, for normal operation, automatically detect all the drivers in use on a given machine and compile a kernel with just those built in. Then we can dispense with the initrd altogether.

Quite a few proprietary Unix (bsd based?) kernels shipped with a generic genvmunix kernel which contained all the supported drivers and subsysteems that you initially booted into and the ran a script (doconfig?) to customise the selection of optional subsystems and retaining only the hardware support that genvmunix found (probed.) The resulting config file was then to build the custom kernel vmunix which is then subsequently booted to by default.

If your vmunix was corrupted or hardware changed etc you again booted /genvmunix.

I vaguely recall some sysv based systems (Irix?) invariably booted a mini(mal) Unix kernel and if the kernel config files had changed build a new Unix kernel then continued to boot or load the full Unix kernel. Typically did this when adding a non vendor tape drive.

_{* Eccles. 1:9 also 1:10 See, this is new? it hath been already of old time, which was before us. KJV}

[keithpeter]

Re: Nothing new under the sun* :)

Slackware still has the huge kernel with a lot of drivers.

The script /usr/share/mkinitrd/mkinitrd_command_generator.sh

can generate a mkinitrd command that shows what modules/hardware available on a running system.

Source is available in the Slackware mirrors /whatevermirror/slackware/slackware64-15.0/source/a/mkinitrd/ perhaps adaptable to generate a kernel make file (???)

OA is suggesting a sort of automated crux-like install with a machine specific kernel being compiled as part of installation? Or have I misunderstood?

[Liam Proven]

Re: Nothing new under the sun* :)

That's right.

Currently most distros either keep 2 or 3 kernels around as a backup. Some don't purge old kernels at all. But most don't keep the kernel in the ESP so space isn't a critical issue so long as the root (or '/boot') filesystem is nice and big.

I'm suggesting a bit more intelligence is applied to this process so that in normal use there's no need for any initrd whatsoever.

[Combat Epistomologist]

Re: Nothing new under the sun* :)

I'd certainly be happier never having to deal with an initrd.

[Steve Graham]

Re: Nothing new under the sun* :)

I compile my own kernels with most drivers built in, and the rarely needed ones as modules. The last obstacle to removing the initramfs was building a few binary blobs into the kernel (for Intel microcode and Intel graphics firmware).

I mount my EFI partition at /boot, which means the kernel build copies the finished item there, but that's OK since I made the partition 2Gb. The kernels should be bootable directly by the EFI firmware, since CONFIG_EFI_STUB is set, but I haven't tried that yet. The boot currently is set to use syslinux.efi with its basic VGA menu, but it allowed me very happily to de-install GRUB2.

[Combat Epistomologist]

Re: Nothing new under the sun* :)

The build-everything--into-your-kernel approach, unfortunately, can very readily become impossible if you are using, for example, ZFS. Or nVivia binary display drivers.

ZFS is a solvable problem. All it needs is for Larry Ellison to tell Oracle's legal department, "Look, just cross-license the thing." But he won't, even though Oracle has taken Solaris out behind the barn and shot it in the head.

[It's just me]

Re: Nothing new under the sun* :)

The zfsonlinux source contains the copy-builtin script to add the module source into your local kernel source, then a simple "make menu-config" && make give you a kernel with ZFS built in. The licensing only stops distros from doing this for you.

[jj_0]

if some mistake or accident damages your ESP then having OneFileLinux on your ESP won't help you.

[Liam Proven]

This is true, yes. But Windows is a great deal more fragile than that, including the recovery system.

It's no panacea but it's a step in the right direction, which was the point of the article. It's one step. I'd like to see half a dozen more heading the same way.

[steelpillow]

How deep?

A rescue OS which lives on the boot partition makes sense - until the partition gets corrupted along with the rest of the drive. At this point you are left with whatever is in the board's firmware, and that will usually allow you to boot a rescue OS from USB.

I seem to recall an initiative to put media codecs and stuff in BIOS, so smart home entertainment and IoT devices need never load a "proper" OS. Dunno if it ever happened.

A UEFI rescue suite in the firmware seems the logical conclusion.

[doublelayer]

Re: K.I.S.S.

A USB disk is much cheaper and larger, and you can put whatever you want on that. I don't think there are any security policies allowing booting to a floppy that don't allow booting to a USB drive, so unless you're working with something that doesn't have USB ports, then just use that way. Optical drives are another option that works just as well.

As for this approach, it's interesting, but I wonder how useful it is. I'm guessing that, in order to make it that small, they've excluded lots of things that I have on my recovery USB drives. For a while, my recovery drive was 1 GB in size (the benefit of that one was that it was too small to write other things to so I never erased it). That got lost so now it's a 4 GB drive. In both cases, I could easily add in whatever tool I wanted and keep that for later.

[Liam Proven]

Re: K.I.S.S.

> to make it that small, they've excluded lots of things that I have on my recovery USB drives

I concur.

I regard this as a very interesting exercise, and one that opens up fascinating possibilities in terms of system recovery tools...

It would be possible to build some cool stuff from this, that is not a million miles away from the firmware-embedded media-player OSes of 15+ years ago, such as Phoenix Hyperspace:

https://gekk.info/articles/hyperspace.htm

There were others, such as Splashtop.

There is prior art in recovery software in the former Rembo, now bought by, and dissolved into, IBM.

https://de.wikipedia.org/wiki/Rembo

[Liam Proven]

Re: K.I.S.S.

> An actual floppy drive costs $15-$60

I am with @doublelayer here. A USB stick is a more versatile and capable solution... albeit one sometimes blocked by corporate IT. But if it is, so will a floppy drive be.

[Anonymous Coward]

Isn't Minix Already Hidden In The Intel Hardware?.....

....and something similar in the AMD hardware?

....and neither of these hardware O/S features is actually capable of being corrupted!

[Anonymous Coward]

"The initrd is the "initial RAM disk." It's how Linux distributions cope with the issue of booting a machine on wildly different hardware without building a unique custom kernel for every individual machine. The bootloader loads the kernel and the initrd into memory...."

Most, if not all, distros these days use initramfs rather than initrd. Differences explained here: https://www.baeldung.com/linux/initrd-vs-initramfs

From a brief look at the OneFileLinux scripts/config etc:

- this is using a initramfs enbedded into the kernel file (CONFIG_INITRAMFS_SOURCE="../alpine-minirootfs"). So it's not a UKI (where a EFI stub, a kernel file, a initramfs file, microcode file(s), and a "cmdline" definition are merged into a single EFI file), which is how I'd create a "single EFI" solution these days.

- the EFI file not signed and so you can't boot it with UEFI Secure Boot enabled (unless you have loaded your own certs into the UEFI and signed the file with those)... that's to be expected as Alpine doesn't (currently) work with the EFI Shim (signed by Microsoft) that most other distros use to support Secure Boot.

[Liam Proven]

[Author here]

Excellent explanation and thank you. You are perfectly right: I should have explained the difference.

OTOH, the object of the speculative exercise *is* eliminating both of them.

No, it won't work with Secure Boot. A lot of things won't, and my standard advice is to disable Secure Boot. MS recently bollixed it with an update as it is -- as I linked in the article.

[Anonymous Coward]

The "big" problem with having a single file EFI Linux OS to run on physical machines (rather than VMs) is that a significantportion of the size is likely to be firmware for various network/storage/etc drivers. If you want a non-CLI interface then add graphics (AMD/Intel/Nvidia) firmware also. Then there's CPU microcode also (though that's not really that large).

As an exercise I must try building a Alpine Linux-based UKI file combined with Alpine's run-from-RAM rootfs to see what sort of size the resultant file would be, I'd guess it would be of the order of 100-150 MiB.