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

91–100 of 187 posts

Re: LinuxBoot: Linux as Firmware

#91

Post by ComputerGuru »

johncolanduoni wrote: post #57
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…

A big one is GPU passthrough. Before graphics cards supported UEFI the old VGA BIOS was a nightmare to get working with virtualization. Now with a tiny bit of configuration you can get consumer GPUs to work just fine in virtual machines.

This was mostly intentional, tbh. Both AMD and nVidia GPUs had "officially sanctioned" cards that worked just fine with their legacy VGA ROM.

Re: LinuxBoot: Linux as Firmware

#92

Post by danudey »

Hello71 wrote: post #80
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 now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. you can make a /boot with BIOS too. format it with FAT and nowadays all bootloaders can access it. in practice, I'm pretty sure GRUB can boot everything but Windows and Mac anyways, so it doesn't really matter. > I can easily update, add and remove boot entries from the OS command line. again, grub h…

/boot is a partition that your boot loader needs to know about ahead of time, and I still have to point my BIOS towards a disk that has the correct code embedded in a section at the beginning of the disk in order to execute it to read its config to know about /boot.

With UEFI, the pre-boot system can automatically detect OSes that are installed on any disks that exist, and can let you choose which ones to run before executing any other code.

This eliminates the issues of e.g. installing Windows (with its boot loader) and then Linux (with its replacement boot loader) overwriting that and then having to add an entry to boot the old OS, and so on. Now all OSes and boot loaders are accessible from the same level and OS installers don't have to worry about wiping out the other ones unless they're deleting partitions.

> again, grub handles this. in fact, it handles it much better than some firmwares

I have had significant issues with Grub when, for example, migrating from one disk to another, having to swap boot drives, change kernel boot parameters, run chroots, and so on, all to make sure that Grub puts the right code at the start of the right disk to point to the right partition ID to read the right config file to load the right kernel.

Nothing is perfect and foolproof, and Grub on UEFI is vastly better than Grub on BIOS/MBR/etc. in my experience.

Re: LinuxBoot: Linux as Firmware

#93

Post by chungy »

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.

GRUB on GPT+BIOS requires the use of a BIOS Boot Partition too (type code ef02 in gdisk... see the full UUID for the full story). So one of the points is moot as well.

Re: LinuxBoot: Linux as Firmware

#94

Post by ComputerGuru »

There is virtually no information on that page. I don't understand why this is getting voted so highly. I'm interested (this falls right in my area of expertise, see my other comments on this page) and I've heard about this proposal before, but the landing page this story links to is just a placeholder with no useful (technical or marketing) information.

Re: LinuxBoot: Linux as Firmware

#95

Post by danudey »

ComputerGuru wrote: post #81
johncolanduoni wrote: post #64

Earlier quoted context omitted.

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.

No you really can't. There can only be one ESP and that's in the spec. You can have multiple partitions each assigned as /boot for a different OS, but there can only be one ESP which is used by the firmware to store its settings, etc. The EFI spec [0] is officially silent about the presence of multiple EFI system partitions on non-removable hard drives , but explicitly forbids multiple ESPs on removable disks, per §1…

> I'm the author of EasyBCD

Thank you!

Also, maybe you can answer this: what's the 'correct' way for systems to handle multiple disks with an ESP partition each? In other words, if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP, or is that set when boot configurations are updated?

Re: LinuxBoot: Linux as Firmware

#96

Post by [deleted] »

dajt wrote: post #86
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. As long as you can still run the OS of your choice at the top of this stack of vendor OSs, what do the vendors gain by this 'land grab'? Particularly the HW vendors. I can imagine Apple and MS are happy to lock things down so o…

[deleted]

Re: LinuxBoot: Linux as Firmware

#97

Post by ComputerGuru »

danudey wrote: post #95
ComputerGuru wrote: post #81

Earlier quoted context omitted.

No you really can't. There can only be one ESP and that's in the spec. You can have multiple partitions each assigned as /boot for a different OS, but there can only be one ESP which is used by the firmware to store its settings, etc. The EFI spec [0] is officially silent about the presence of multiple EFI system partitions on non-removable hard drives , but explicitly forbids multiple ESPs on removable disks, per §1…

> I'm the author of EasyBCD Thank you! Also, maybe you can answer this: what's the 'correct' way for systems to handle multiple disks with an ESP partition each? In other words, if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP, or is that set when boot configurations are updated?

> Thank you!

No problem! Glad you found it useful.

> if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP

With regards to your question: I guess it depends on what you mean by "software" raid. Enabling RAID in the "BIOS" (that term has now come to encompass the firmware configuration utility for UEFI motherboards as well) (typically Intel "RST" rapid storage RAID, nvraid for nVidia chipsets (less common these days), AMD raid, etc.) is 100% software raid, which does nothing more than make the BIOS aware of its presence (and toggle a flag so that RAID drivers can find the array) so that it doesn't run into exactly the problem you describe, i.e. it'll be aware of the cloning at a level higher than the UEFI bootloader init, which will only see the virtual raid volumes rather than their independent components.

Now if you put all that aside and are just wondering how it selects in the presence of multiple ESPs on different devices that made it through to the bootloader layer: the UEFI "BIOS" doesn't know (and can't know) since UEFI has done away with the concept of drive order entirely. You can set the order manually in the "boot device order" section (typically on the boot tab in the BIOS config) or choose the one-time boot target via F11 or F12 at the boot-up screen, but otherwise it's just a tossup and the BIOS is free to chose any local device's ESP as "the" ESP. In practice, it'll choose one of the SATA drives (assuming a mix of other interfaces such as NVMe), either the first to respond (not an issue with SSDs which respond quickly, but magnetic media takes time to spin up if you're still using old HDDs) or the first to be enumerated by the SATA controller (which has its _own_ firmware and its own level of abstraction and logic (and bugs) and whatnot).

BUT in the case of software raid, that RAID 0 should actually extend to the GPT itself and both drives will have the same content and mirrored ESPs, so in practice it won't matter which is loaded (so long as your OS doesn't do anything stupid like try to modify the on-disk structure before loading the RAID-aware storage driver. I've seen BIOSes that "helpfully" store a copy of the current firmware to a locally-attached disk with an understandable partition format (so FAT32) that ended up breaking a RAID because the drives were no longer in sync because the BIOS wasn't aware of the mirror).

Re: LinuxBoot: Linux as Firmware

#98

Post by dogma1138 »

cmurf wrote: post #66
gnufied wrote: post #54

Earlier quoted context omitted.

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/a…

NVRAM on PC/server main boards is cleared with the RTCRST (Real Time Clock Reset) jumper.

On laptops it’s a combination of keys usually some older ones would require removing the battery for a specific amount of time.

Re: LinuxBoot: Linux as Firmware

#99

Post by ComputerGuru »

nickwinlund wrote: post #3

Wonderful! I detest the UEFI/secure boot schema in use on post-Windows 8 systems

This doesn't really have anything to do with Windows, recent Linux and FreeBSD release prefer to use UEFI and Secure Boot if available.

While UEFI is platform/OS-agnostic, it's too early to tell if this LinuxBoot will be as open (even if better designed). Additionally, there are benefits that Secure Boot brings to the table (notable with regards to security and integrity verification) that you should not be so hasty to throw out along with the bathwater. If LinuxBoot does not support Secure Boot, I can guarantee you it will be a project dead in the water, no one (in the corporate world) will want to go back to untrusted boot.

Re: LinuxBoot: Linux as Firmware

#100

Post by gatmne »

dajt wrote: post #86
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. As long as you can still run the OS of your choice at the top of this stack of vendor OSs, what do the vendors gain by this 'land grab'? Particularly the HW vendors. I can imagine Apple and MS are happy to lock things down so o…

> What do the vendors gain by this 'land grab'?

One thing is that it could be used to as a venue to pursue new recurring revenue streams.

While not exactly the same thing, I've seen some people joke about intel locking owners from cpu features behind monthly subscriptions.

This kind of exploitation requires disallowing owners from fully controlling their devices in order to be effective. The more control vendors have, the more elaborate and exploitative these schemes can be, and the less likely owners will be able to do anything about it.

Post reply on HN