Running loadlin from MS-DOS was peak Linux usability, IMHO:
There was a whole entire (simple, limited) operating system to work with (MS-DOS) to use for sorting out any issues with booting the "real" operating system, and that bootloader-OS worked well with the hardware, and was familiar to the people using it -- at that time.
I used it for a long time (longer than most, I'm afraid). The method provided for systems that would [hopefully, and almost-alwaus] successfully boot MS-DOS, whereafter the boot environment was easy to manage and sort out so that a real operating system (Linux) could be loaded and run.
Back then, given any working PC, it was trivial to make an MS-DOS boot floppy, and therefore it was also trivial to make a Linux system boot up with loadlin.
After that, I used LILO for a time: LILO worked great if everything was in order, but it tended to fall down hard if things weren't just-so.
And then: GRUB. I still hate GRUB. (I will probably always hate GRUB: It still has too much interdependence between boot and system environments. It has done an OK job at autocnfiguring itself for a couple of decades, but that interdependence remains, and things can get hairy on reboot when the autoconfig doesn't do the right thing for whatever reason. It all feels like it is too limited, and also too far-reaching -- concurrently.)
tl;dr, I dearly miss the seemingly-simple concept of using a "real," common, minimal-ish operating system as a bootloader. I've been told that UEFI provides something similar to what MS-DOS and loadlin provided, but I haven't found a single utterance as to how that's actually supposed to work. Working within UEFI seems to be mostly a dark black box in common use, and the boot environment should never be a black box.)
Well, if MS-DOS is something you'd be comfortable debugging issues within, then I imagine you'd be even happier using live images to debug issues.
For smaller ISOs, you can even just stuff it on your boot partition and have e.g. the arch install ISO as a permanent boot option should you ever need to debug. I have the Arch ISO there, in the off-chance that I massively screw up and have no spare computer to prepare an image/aid in debugging.
> And then: GRUB. I still hate GRUB.
I'm not a huge systemd fan, but systemd-boot just works. Configuration is trivial and does not require rebuilding, so you can change settings from anything that can mount your EFI system partition.
It does have one annoying quirk, and that is that if your forget to fill in your loader.conf (needs a default entry and timeout which is commented out by default in e.g. Arch), then it silently fails.
> I've been told that UEFI provides something similar to what MS-DOS and loadlin provided,
To some extend - if you drop to the EFI shell (assuming your firmware includes one, otherwise you can bring your own), you can navigate supported filesystems and load ramdisks and kernels and such.
It can host fancier apps too, but I haven't done more than just read files and load OS's. Useful when you effed your system and your bootloader.
I second the "have a recovery distro installed permanently on your computer" thing, it has saved me countless times. My choice is Puppy Linux, since it's impressively tiny and has a good selection of recovery tools preinstalled, but is also totally usable as a desktop OS in case I really need to get some things done before I have time to recover my system.
Since the advent of bootable ISOs on disc and then large USB flash drives, I haven't bothered with any kind of recovery options on my computer, and now actively remove them. See recovery partitions, recovery kernel (on fedora) etc, etc.
Feels redundant, and I enjoy having the disk space back. An external flash boot drive has saved me countless times, and is useful for other stuff.
On it I now use Ventoy, which I heartily recommend. So much better than imaging the whole drive.
Ventoy is great[0], but with laptops easily having 2TB for cheap nowadays, leaving room for a sub-1GB ISO on the boot partition is not really space that would be missed. I also feel that any time one really needed an ISO, no flash drive near me ever had the right one.
[0]: ... when installed, but the installation process is awful. For GPT, it's just a FAT partition with the ESP flag and a few Ventoy files on it, and yet you need to run "installers" as root to "prepare" the drive. It should just have been a tarball and a few trivial commands - not a thousand lines of bash shelling out to a custom C partitioning tool...
I have lot of multi GB movies/series in process at any time so always short on space and don’t want to lock it up in another partition.
You just put several isos on it once a year. It’s usually not installed, just run. Any live distro can download additional tools as needed. And really any from the last five years are fine, partition tools and text editors haven’t innovated recently. Maybe you’d want the latest btrfs tools possibly, if so download.
A cheap 64GB! flash drive dedicated to the purpose and put on a keychain works well. Think I looked for 32GB but needed to go 64 to get usb3.2+ transfer speed, which I also recommended. Still so cheap!
Great for test driving new distros too.
I agree about ventoy, but only had to install it once, and already blocked it out, haha. Hopefully someone strips it down and adds a lite version to debian.
I used MS-DOS as flexible and (at the time) familiar environment from which to run a bootloader, which in turn loaded up a Linux kernel.
Live images aren't the same thing, I don't think: Sure, I can do all kinds of useful stuff with them, and they're vaguely as familiar as any other Linuxey-thing is.
But AFAIK there is no Linux equivalent to loadlin, so I can't use a live image as a flexible environment from which to run a bootloader like I did with MS-DOS over a quarter of a century ago.
> But AFAIK there is no Linux equivalent to loadlin, so I can't use a live image as a flexible environment from which to run a bootloader like I did with MS-DOS over a quarter of a century ago.
> And then: GRUB. I still hate GRUB. (I will probably always hate GRUB: It still has too much interdependence between boot and system environments. It has done an OK job at autocnfiguring itself for a couple of decades, but that interdependence remains, and things can get hairy on reboot when the autoconfig doesn't do the right thing for whatever reason. It all feels like it is too limited, and also too far-reaching -- concurrently.)
GRUB might disappear in the future. You might already switch to systemd-boot (which is basically gummyboot if my understanding is correct?).
But Lennard Poettering & co is working on UKI (unified kernel image) that should make linux bootable from UEFI directly (no grub or other boot loaders needed).
I didn't dive that much into UKIs but if my understanding is correct an UKI should be a bundle comprising a linux kernel, an initramfs and a few more things, packed as an executable that UEFI can launch.
This should simplify a few things (like cryptographic chain of trust) and make some things smoother.
Directly booting Linux kernels on EFI has been possible for quite a while thanks to the EFI stub[0], which is maintained by the kernel developers.
I'm not sure if having yet another implementation of EFI booting Linux kernels, such as UKI, especially if done without support from the kernel developer community, will bring anything but useless competition and strife. The whole kdbus controversy comes to mind.
Vouch, EFISTUB has been by far the fastest method of booting a Linux kernel for me. It's also prettier IMHO, since there already is a framebuffer set up with the correct resolution for my display, provided directly by the UEFI.
Especially if you already compile your own kernels, IMHO, there's almost no excuse not to use EFISTUB other than if your specific firmware isn't compatible with it for whatever reason.
rEFInd has been my goto when using UEFI. Finds most boot partitions without having to configure anything.
Configuration is just a single line:
"Boot with power options" "ro cryptdevice=UUID=XXXXXXXXXXXXX:root root=/dev/mapper/root initrd=amd-ucode.img initrd=initramfs-linux.img quiet amd_pstate=active"
I think for the past three years or so I've exclusively used EFISTUB, extra bootloaders just aren't necessary anymore because UEFI already implies one provided by the motherboard. I just use efibootmgr to set up an entry with the flags I want and boom. You're going to be waiting for the motherboard's bootloader to load anyway, so you may as well have it load the actual kernel rather than another bootloader.
EFISTUB is a Linux config option that has to be specified at compile time, so you do have to compile your own kernel if the distro you're using doesn't already enable it, but I compile my own kernels anyway so this is fine.
It is technically a bootloader. However it looks inside of itself for the kernel, ramdisk, and kernel commandline [0]. This means that you can use objcopy to put an existing kernel and ramdisk into a standalone EFI executable; without needing to recompile anything.
Dracut even has a "--uefi" option that will do all of that automatically.
[0] Although if secureboot is disabled, you can override the cmdline from the EFI if your firmware exposes that functionality.
I stuck with LILO as long as I possibly could too. I was gutted the day I had to switch to GRUB. Like yourself, I don’t think I’ll ever learn to like GRUB.
There was a whole entire (simple, limited) operating system to work with (MS-DOS) to use for sorting out any issues with booting the "real" operating system, and that bootloader-OS worked well with the hardware, and was familiar to the people using it -- at that time.
I used it for a long time (longer than most, I'm afraid). The method provided for systems that would [hopefully, and almost-alwaus] successfully boot MS-DOS, whereafter the boot environment was easy to manage and sort out so that a real operating system (Linux) could be loaded and run.
Back then, given any working PC, it was trivial to make an MS-DOS boot floppy, and therefore it was also trivial to make a Linux system boot up with loadlin.
After that, I used LILO for a time: LILO worked great if everything was in order, but it tended to fall down hard if things weren't just-so.
And then: GRUB. I still hate GRUB. (I will probably always hate GRUB: It still has too much interdependence between boot and system environments. It has done an OK job at autocnfiguring itself for a couple of decades, but that interdependence remains, and things can get hairy on reboot when the autoconfig doesn't do the right thing for whatever reason. It all feels like it is too limited, and also too far-reaching -- concurrently.)
tl;dr, I dearly miss the seemingly-simple concept of using a "real," common, minimal-ish operating system as a bootloader. I've been told that UEFI provides something similar to what MS-DOS and loadlin provided, but I haven't found a single utterance as to how that's actually supposed to work. Working within UEFI seems to be mostly a dark black box in common use, and the boot environment should never be a black box.)