LinuxBoot Joins The Open-Source Firmware Foundation

[phoronix]

Phoronix: LinuxBoot Joins The Open-Source Firmware Foundation

Established a few months ago was the Open-Source Firmware Foundation to promote open-source firmware usage throughout the industry. LinuxBoot is now the latest party joining the Open-Source Firmware Foundation...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Boot-Joins-OSFF

[gnarlin]

So, if I'm understanding this right, if you have a system with Linuxboot (which replaces the UEFI) then you'll essentially be booting the Linux kernel 3 times!
1. Linuxboot
2. Init ram disk
3. The actual running Linux kernel for your system
Is it just me or is there some redundancy there? Why can't we just boot directly into our Linux kernel or at the very least dump the init ram disk?

[amdevereux]

It would be booting Linux twice not thrice, I think. This is very similar to Petitboot, which Odroid ARM SoCs (and probably others) use. UEFI is so huge that Linux is actually less bloat. Booting a single kernel directly without a bootloader and BIOS/EFI is possible (see the predecessor to coreboot), but it means every time there's a kernel upgrade, you're flashing ROM. Plus, it doesn't necessarily easily support multi boot.

I do like Petitboot (which is similar to this) because it allows an ARM SoC to easily boot from different mediums, itself provides a recovery shell, and can easily netboot. For example, to install Debian on my Odroid HC4, the bootloader/firmware downloaded the Debian net install iso to RAM and kexec'd it, meaning I didn't have to prepare any installation mediums. It also means I have easy access to a more complete and always up to date recovery environment (through the firmware!) in case anything goes really wrong.

[cavenditti]

So, if I'm understanding this right, if you have a system with Linuxboot (which replaces the UEFI) then you'll essentially be booting the Linux kernel 3 times!
1. Linuxboot
2. Init ram disk
3. The actual running Linux kernel for your system
Is it just me or is there some redundancy there? Why can't we just boot directly into our Linux kernel or at the very least dump the init ram disk?

The kernel doesn't change when you use an initial ram disk, you just switch root at some point during boot.

Btw it's perfectly possible to directly load a Linux kernel very soon in the boot process (without any initramfs) and run it for your os, assuming you're only targeting your specific hardware setup.
The very reason why initramfs exist is to be able to target a wide range of configurations, I'm not sure how difficult would be to create a more "direct" boot process that's flexible enough to be actually useful. Of course someone can try and see where it leads

[toves]

The very reason why initramfs exist is to be able to target a wide range of configurations, I'm not sure how difficult would be to create a more "direct" boot process that's flexible enough to be actually useful. Of course someone can try and see where it leads

With old school Unix one initially booted a generic monolithic kernel during installation or after installing/removing hardware.
The generic kernel would include all the device drivers, file systems etc.
A stripped down kernel customised for the machine would then be built and used for subsequent boots.
Adding new device requiring a driver not in the generic kernel usually meant rebuilding the custom
kernel with the vendor's supplied (binary) driver.

One could do the same thing with the Linux kernel but hardly worth the bother outside
embedded or safety critical platforms I would have thought.

Early on I do remember building Linux kernels without an initrd or kernel module support.

[waxhead]

Well something "simpler" than UEFI would be nice, maybe someday all peripheral will have it's own IP address

[binarybanana]

Btw it's perfectly possible to directly load a Linux kernel very soon in the boot process (without any initramfs) and run it for your os, assuming you're only targeting your specific hardware setup.
The very reason why initramfs exist is to be able to target a wide range of configurations, I'm not sure how difficult would be to create a more "direct" boot process that's flexible enough to be actually useful. Of course someone can try and see where it leads

initramfs is really only necessary if you use encryption and/or other complex storage setups involving bcache/LVM/nfs etc. And even for the latter you can sometimes get away with arcane kernel parameters. If you boot straight into some bog standard partiton on SATA/NVMe then all you need are AHCI/NVMe and file system modules baked into the kernel. Just point the kernel to the right partition with root=/dev/$part and that's it. Probably works for 90+% of users.

[sinepgib]

initramfs is really only necessary if you use encryption and/or other complex storage setups involving bcache/LVM/nfs etc. And even for the latter you can sometimes get away with arcane kernel parameters. If you boot straight into some bog standard partiton on SATA/NVMe then all you need are AHCI/NVMe and file system modules baked into the kernel. Just point the kernel to the right partition with root=/dev/$part and that's it. Probably works for 90+% of users.

Indeed. Arch's default config is enough in many cases. Only issue I have is with F2FS not being in the image, but back when I used ext4 it would boot right up as long as I passed rootwait in the command line.

[jabl]

With old school Unix one initially booted a generic monolithic kernel during installation or after installing/removing hardware.
The generic kernel would include all the device drivers, file systems etc.
A stripped down kernel customised for the machine would then be built and used for subsequent boots.

It was the same with early Linux. IIRC loadable module support was added in the 2.0 kernel, before that everything was builtin to the kernel "core". And it wasn't just the kernel, but also PC hardware back then was not discoverable by the OS via various plug-and-play mechanisms that we take for granted these days. For devices you had to configure the IRQ to use by setting dip switches (or sometimes in the BIOS for things like onboard serial and parallel ports), and then you had to manually configure the software to match. And it was up to you to make sure no two devices used the same IRQ.

I remember doing exactly that, compiling my own kernel and enabling the driver for my sound blaster card, and setting the IRQ and I/O base port in the kernel configuration, and these settings would then end up hardcoded into the kernel I built.