Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LinuxBoot: Linux as Firmware

linuxboot.org

Post reply on HN
Print view View original

61–70 of 187 posts

Re: LinuxBoot: Linux as Firmware

#61

Post by hugelgupf »

BenjiWiebe wrote: post #50
hugelgupf wrote: post #13

Earlier quoted context omitted.

Chances are you don't want to re-flash your firmware on your servers just to change what kernel you run in production. The kernel in flash also has space constraints that will make it a pretty small kernel with a lot of features turned off.

In fact, you'd have to reflash to update Firefox! Oh wait, Firefox won't even fit on the ROM chip. No wonder we don't use the ROM chip as our main storage...

You could have a tiny initramfs that mounts the disk you want with your actual init and then switch_root to that. You'd have the kernel from flash, and init from disk.

Re: LinuxBoot: Linux as Firmware

#62

Post by garaetjjte »

BenjiWiebe wrote: post #52

BTW, on the flip side of the UEFI haters, i.e. things that I can do with UEFI more easily than BIOS (or at all). I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. I can easily update, add and remove boot entries from the OS command line. I can forgo bootloaders entirely and use Linux as UEFI application. I can use GPT and finally partition as much as…

>I can use GPT and finally partition as much as I want.

BIOS actually don't care what is on disk except for 512 bytes containing MBR, so it is possible to use GPT partitions with it.

Re: LinuxBoot: Linux as Firmware

#63

Post by johncolanduoni »

aplorbust wrote: post #36

IMO, the problems that [U]EFI introduces (that far exceed the historical limitations it overcomes) should be self-evident . IMO, he should not have to argue against having multiple, redundant copies of drivers, shells and utilties each accessible only in its own "OS" (UEFI, GRUB, OS). It should not be a debate. This is definitely not "defense in depth". IMO, whomever controls the first OS controls the computer becaus…

> These "hardware features", whether its [U]EFI or ME or whatever acronym, IMO is a land grab by hardware vendors over what we know as the "OS". Less computer owner control, more vendor control.

What control did you have with an old PC BIOS that you now are missing with UEFI? Things like SMM and Intel ME that keep running after your actual OS has started existed and were pretty much ubiquitous before UEFI became common in consumer hardware. They aren't required to implement UEFI, and UEFI doesn't enable them any more than PC BIOS did.

> I only need one OS to boot to a working environment. I should be able to choose that OS.

You weren't able to choose your PC BIOS any more than you can choose your UEFI implementation now. There are PC BIOS and UEFI motherboards that can accept coreboot or something similar, and in all other cases you're stuck with an opaque vendor blob. At least with UEFI you have an opportunity to write your own software that can be part of the boot process, doing so with a BIOS was usually impossible unless you could install an option ROM.

> I do most work on the commandline in text-mode (no graphics layer) and as such I only need one OS, with some basic utilities. When the news came that new computers would have [U]EFI, I considered whether I should just switch from the OS I am using to [U]EFI. It seemed to have all the utilities I would need to do work, along with the ability to extend with new programs.

That's great for you but a lot of people want to be able to install different OSes on their hardware. Having to duplicate the hardware initialization code for each would be a major pain and would probably result in a lot of hardware only supporting one OS (e.g. many consumer motherboards would probably be Windows only in this situation). I really don't see how having the firmware wedded to a particular OS is going to give people more choice.

Re: LinuxBoot: Linux as Firmware

#64

Post by johncolanduoni »

gnufied wrote: post #54
BenjiWiebe wrote: post #52

BTW, on the flip side of the UEFI haters, i.e. things that I can do with UEFI more easily than BIOS (or at all). I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. I can easily update, add and remove boot entries from the OS command line. I can forgo bootloaders entirely and use Linux as UEFI application. I can use GPT and finally partition as much as…

On other hand - a common partition that is shared among all operating systems has too high chance of getting corrupted or simply blown away by another install. Just yesterday - RHEL7.5 beta install overwrote UEFI entry of Ubuntu for me and Ubuntu became unbootable. On another laptop - Fedora blew away my Windows bootloader from UEFI partition and I have been too lazy to recover it. Also - because UEFI partition actua…

You can have multiple EFI system partitions on the same disk. The Windows installer does not like this, but it won't affect the actual boot process after it's installed. The Linux distros I've seen don't mind at all, since /boot/efi is usually mounted by UUID in your fstab.

Re: LinuxBoot: Linux as Firmware

#65

Post by aaronmdjones »

garaetjjte wrote: post #62
BenjiWiebe wrote: post #52

BTW, on the flip side of the UEFI haters, i.e. things that I can do with UEFI more easily than BIOS (or at all). I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. I can easily update, add and remove boot entries from the OS command line. I can forgo bootloaders entirely and use Linux as UEFI application. I can use GPT and finally partition as much as…

>I can use GPT and finally partition as much as I want. BIOS actually don't care what is on disk except for 512 bytes containing MBR, so it is possible to use GPT partitions with it.

More specifically, BIOS machines don't know what partitions are (nor partition tables), and it's only the first 446-ish bytes, not 512.

Re: LinuxBoot: Linux as Firmware

#66

Post by cmurf »

gnufied wrote: post #54
BenjiWiebe wrote: post #52

BTW, on the flip side of the UEFI haters, i.e. things that I can do with UEFI more easily than BIOS (or at all). I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. I can easily update, add and remove boot entries from the OS command line. I can forgo bootloaders entirely and use Linux as UEFI application. I can use GPT and finally partition as much as…

On other hand - a common partition that is shared among all operating systems has too high chance of getting corrupted or simply blown away by another install. Just yesterday - RHEL7.5 beta install overwrote UEFI entry of Ubuntu for me and Ubuntu became unbootable. On another laptop - Fedora blew away my Windows bootloader from UEFI partition and I have been too lazy to recover it. Also - because UEFI partition actua…

Right. I think it exchanged problems we know, for problems we don't know. And now we're learning about those problems. Or re-learning.

With respect to NVRAM boot entries, Apple has been doing this for ~30 years and across all of that hardware (three CPU architectures, at least three firmware and three or four filesystems) they have a single method of resetting the NVRAM called "zapping the PRAM" with command+option/apple+p+r at the boot chime. And that's because they know these entries can become corrupt for various reasons. And yet in 2018, what single uniform method exists for clearing stale or corrupt NVRAM information on non-Apple hardware?

Apple also long ago inserted a hint for likely boot device suspects into the HFS volume header, as a fallback for NVRAM in case it was incorrect or had been reset with zapping the PRAM.

With respect to the EFI System partition, Windows and all versions of OS X/macOS do not keep it persistently mounted. That volume is mounted on demand only during updates that require the contents of the volume to be updated, i.e. the bootloader and its files, and is then unmounted. I've always thought this was an incredibly risky as well as lazy thing on all common Linux distros that the EFI system partition is persistently kept rw mounted at /boot/efi.

Somewhat related is when /boot is a separate file system from root, it is also persistently mounted rw on Linux distros. The functional equivalents on Windows and macOS are not persistently mounted. I think it's a rather sloppy practice, but pretty much no one else seems to think it's a problem. You get a crash, and the dirty bits are ignored by read-only firmware and bootloader, so chances are it still boots, and then the dirty bit and any corruptions due to the crash are fixed by fsck during startup. shrug

Re: LinuxBoot: Linux as Firmware

#67

Post by chriswarbo »

johncolanduoni wrote: post #63
aplorbust wrote: post #36

IMO, the problems that [U]EFI introduces (that far exceed the historical limitations it overcomes) should be self-evident . IMO, he should not have to argue against having multiple, redundant copies of drivers, shells and utilties each accessible only in its own "OS" (UEFI, GRUB, OS). It should not be a debate. This is definitely not "defense in depth". IMO, whomever controls the first OS controls the computer becaus…

> These "hardware features", whether its [U]EFI or ME or whatever acronym, IMO is a land grab by hardware vendors over what we know as the "OS". Less computer owner control, more vendor control. What control did you have with an old PC BIOS that you now are missing with UEFI? Things like SMM and Intel ME that keep running after your actual OS has started existed and were pretty much ubiquitous before UEFI became comm…

> What control did you have with an old PC BIOS that you now are missing with UEFI?

I had a PC with a BIOS once. It didn't seem as slick as the Kickstart I'd used for the previous decase on my Amigas. It was also much less configurable/programmable than the OpenFirmware that came on my subsequent PC. My current machine uses libreboot, which is fine but I much prefer OpenFirmware.

tl;dr "BIOS vs EFI" is a false dichotomy, and "it's better than BIOS" is pretty weak praise for a boot system.

Re: LinuxBoot: Linux as Firmware

#68

Post by floatboth »

hugelgupf wrote: post #9
mikepurvis wrote: post #5

Earlier quoted context omitted.

Similar philosophy to Petitboot, for which the rationale is given here: https://www.youtube.com/watch?v=CQueOHKO58M Obviously it's a heavy weight solution, but the idea of having more drivers and better support is compelling— it's a much easier path to exotic boot setups, eg over wifi, off a SAN, whatever.

UEFI is a heavy-weight solution in comparison as well. You can compile some pretty small Linux kernels.

ehh… Sure, TianoCore extended by AMI/whoever is not that tiny, but it's still not a full multitasking multiuser kernel.

But EFI can be implemented by others. Including U-boot! Which is really lightweight.

Re: LinuxBoot: Linux as Firmware

#69

Post by katastic »

madez wrote: post #58
Santosh83 wrote: post #38

Earlier quoted context omitted.

This is in the hands of the firmware/hardware manufacturers. AFAIK, for instance, the version of Minix that serves as Intel's ME will continue to be operational even if the UEFI is replaced by Linux. The issue is that 'firmware' actually means many different blobs of software in various ROMs spread throughout the system, from disk controllers to GPUs to memory controllers to NIC and so on. You will never be able to v…

That's why it is important to not buy random shiny devices. Open source hardware like for example the Teres-1 [0] are what allows us to stay in control. I can't wait for even more open successors based on RISC-V processors. [0] https://www.olimex.com/Products/DIY-Laptop/

If you don't buy a random shiny device, how do you think the people in charge of those companies are even going to know? Even if they DID care, how is your one "not purchase" going to show up in any of their marketing analysis?
Post reply on HN