8 ms·

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 b

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 want. I might have forgotten something too. :)

gnufied 9y ago
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 actually contains things needed for booting these operating systems - it is almost always non-trivial to restore.
- johncolanduoni 9y ago
  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.
  - ComputerGuru 9y ago
    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 §11.2.1.3: > For removable media devices there must be only one EFI system partition, and that partition must contain an EFI defined directory in the root directory But in practice, Bad Things (TM) happen if you have more than one ESP on the boot disk. An ESP isn't just a partition mounted to /boot or one that has bootfiles or a bootloader, it's (in practice) a FAT32 partition that has a different filesystem ID, in particular, the magic GUID {C12A7328-F81F-11d2-BA4B-00A0C93EC93B} I'm the author of EasyBCD and numerous other boot utilities and spent a hell of a lot of a time (too much time) researching and working around the various UEFI deficiencies in various desktops, laptops, firmware implementations, bootloaders, and operating systems. Here's a Microsoft bulletin on the matter: https://support.microsoft.com/en-us/help/2879602/unable-to-boot-if-more-than-one-efi-system-partition-is-present https://support.microsoft.com/en-us/help/2879602/unable-to-b... (long story short, the Windows kernel may bork if it runs into multiple ESPs and fail to load. Our bootable boot repair CDs wouldn't boot into the WinPE kernel because the disk management subsystem would hit an infinite loop in certain cases (not this case). We ended up switching to FreeBSD for our live CDs and writing our own disk repair subroutines to get around cases where even Windows live CDs wouldn't boot so we could fix the customer's PCs) Linux may not hang if there are multiple ESPs (except it sometimes does), but it certainly doesn't support treating multiple partitions as the ESP simultaneously, either: https://superuser.com/questions/688617/how-many-efi-system-partitions-esp-can-a-computer-have https://superuser.com/questions/688617/how-many-efi-system-p... [0]: https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf https://www.intel.com/content/dam/doc/product-specification/...
    - danudey 9y ago
      > 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?
      - ComputerGuru 9y ago
        > 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).
  - cmurf 9y ago
    From my reading of the UEFI spec, much of the language assumes one EFI system partition per device, for example see the capsule updating language on page 262 of the version 2.4 spec. The directory \EFI\UpdateCapsule is checked for capsules only withing the EFI system partition on the device specified in the active boot option determine by reference to BootNext variable or BootOrder variable processing. and later The system firmware is not required to check mass storage devices that do not contain boot target that is highest priority for boot nor to check a second EFI system partition not the target of the active boot variable. There's no accounting for two ESP's for one device, and how to resolve the ensuing ambiguity, which one is the primary one? Are you certain Windows updates distinguish between two EFI system partitions, should an update need to update the Windows bootloader or its config?
    - ComputerGuru 9y ago
      Actually, it's even worse than that. As the BIOS no longer has a concept of "active device," multiple ESPs on separate devices are also a problem; the user would have to actively pick the one to load at boot time via the non-EFI "boot device menu" at the boot screen.
- cmurf 9y ago
  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
  - dogma1138 9y ago
    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.
    - igravious 9y ago
      Great, but what magic key combo–or combos?
      - 9y ago
- jiggunjer 9y ago
  I always thought it a design flaw in OSes that always keep EFI partitions mounted (and writeable). I also read horror stories where someone bricks their pc/laptop by corrupting the UEFI (not the EFI partition, the actual firmware).
- OOPMan 9y ago
  Why are you sharing a UEFI partition between your OSes? Pretty sure you don't have to?
johncolanduoni 9y ago
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.
- Sephr 9y ago
  Maybe for AMD GPUs, but getting consumer Nvidia GPUs working with VT-d on Nvidia's drivers is a little difficult. GPU passthrough is not something Nvidia wants to support on consumer GPUs. Edit: s/very/a little/
  - lathiat 9y ago
    It's "very difficult" because the drivers are intentionally nerfed not to load in a virtual environment. Your statement is entirely correct.
  - irth 9y ago
    One line config change to hide the hypervisor from the VM and it works. (Source: worked for me)
  - johncolanduoni 9y ago
    I've had no problem using consumer Nvidia GPUs with QEMU/KVM for this. All I needed to do was (1) use kvm=off (this does not turn off KVM, it just sort of hides it from the NVidia driver) and (2) on Windows, edit the registry to force enable Message Signaled Interrupts. When I tried it with an AMD card it would periodically crash the host when it was assigned to a Linux guest.
- ComputerGuru 9y ago
  This was mostly intentional, tbh. Both AMD and nVidia GPUs had "officially sanctioned" cards that worked just fine with their legacy VGA ROM.
garaetjjte 9y ago
>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.
- aaronmdjones 9y ago
  More specifically, BIOS machines don't know what partitions are (nor partition tables), and it's only the first 446-ish bytes, not 512.
- chungy 9y ago
  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.
- jarman 9y ago
  Also GPT partitions have little use when using mdraid/dm-crypt/lvm2 (or zfs) stack. IIRC Windows have similar features with dynamic partitions, so I don't see any reason to use bios partitioning for anything beyond boot (and MBR is enough for it, even without extended partitions).
thudson 9y ago
With LinuxBoot you can use any filesystem that Linux supports, not just FAT. You can update boot entries by editing shell scripts, rather than manipulating opaque NVRAM variables. You can run Linux applications straight from the ROM if you want to do that. You can avoid legacy partitions entirely and use LVM for flexible volume management. And... You can build it yourself and verify that the reproducible build matches what others have built to ensure that the firmware is clean. You can have the firmware attest to you via TOTP that it hasn't been changed. You can have a fully encrypted disk, with secrets sealed in the TPM and only unsealed if the firmware is unmodified. You can include device drivers for things that UEFI doesn't support. You can use external hardware tokens like a Yubikey to sign the OS install and have the firmware validate the GPG signature. Or what ever else you might want to do...
- Annatar 9y ago
  All very good and very valid points. Just wouldn’t want to do that with Linux. OpenBSD or FreeBSD, yes; illumos, yes; Linux - out of the question.
  - pferde 9y ago
    You're probably getting downvoted because you did not follow up with "...because $reasons", so your post comes off as petty Linux hate (is there such word as "anti-fanboyism"?).
    - Annatar 9y ago
      Thanks for the clarification. In the context, most other posts here contain no technical detail whatsoever either and are nothing more than unsubstantiated opinions (same as mine); they just really dislike that there is someone out there who doesn’t think that Linux is phenomenal. In the days of Microsoft dominance, we called that monoculture. Volumes have been written and videos filmed on all the inadequacies of the GNU/Linux kernel, far more than I could cram into one “Hacker News” post. I for example get a painful reminder of just how unfit the Linux kernel is as firmware every time I turn on my television set which runs it (ARM V7 Linux for the curious). After that, I don’t want any more. That is not an isolated scenario. Apropos petty, my hate of GNU/Linux is epic.
Hello71 9y ago
> 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 handles this. in fact, it handles it much better than some firmwares, which usually have bugs relating to, among others, random rearrangement of boot order, failure to persist changes, and permanently adding entries for every flash drive you plug in. these have never happened to me with grub, and I do not expect them to. OTOH, I expect to see stupid bugs caused by firmware vendors de facto supporting single-drive Windows only, at least until the end of the PC platform as we know it. > I can forgo bootloaders entirely and use Linux as UEFI application. I guess this is nice, but honestly three binaries wasn't significantly worse than two. > I can use GPT and finally partition as much as I want. you can use GPT with BIOS too, it's just that MS doesn't feel like testing it so they lock it out for everybody.
- danudey 9y ago
  /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.
ComputerGuru 9y ago
I (see footnote) started off hating the UEFI because it changed everything for me and others working with bootloaders, but at this point I'm just ambivalent about it. It trades one set of problems for another. The biggest problem is with shoddy implementations and poor development/engineering practices by hardware and software vendors (I have some devices lying around from R&D that brick themselves if the ESP is erased; you can't even access the "BIOS" even if you remove the CMOS battery, can't boot from a removable disk, nada. Need to insert a physical, non-removable disk with an ESP compatible with that PC or mail it back in to the vendor for an RMA!) That said, your argument really boils down to a straw man. None of your points are really in favor of UEFI and some show a misunderstanding of the previous situation. I really recommend anyone that wants to better understand the (traditional) boot process have a read of this guide we wrote, complete with flowcharts and breakdowns, entitled "Everything you ever wanted to know about how your PC starts up (but were too afraid to ask)": https://neosmart.net/blog/2015/everything-you-ever-wanted-to-know-about-how-your-pc-boots-up/ https://neosmart.net/blog/2015/everything-you-ever-wanted-to... Anyway, to address your remarks: 1) I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. That has always been the case, at least any time in contemporary PC history. Ever since bootloaders grew past the 1 sector limit, the only code at the start of the drive has been a pointer (that can even be copied and pasted between Windows and Linux, etc. because it serves a universal purpose) that looks for and loads the first active, primary partition on the drive. That is where the actual bootloader code resides. 2) I can easily update, add and remove boot entries from the OS command line. This isn't anything to do with UEFI either, it's just a matter of your OS providing an interface for doing so. Microsoft did that back in 2006 for legacy bootloaders with bcdedit (that's where our free EasyBCD tool comes in) and we've developed standalone cli utilities for doing the same for GRUB under Linux. 3) I can forgo bootloaders entirely and use Linux as UEFI application. Sure. But that bootloader code has been integrated into the OS and the firmware. Really it's just reduced the abstraction and increased blurring between the layers. Makes it hard to swap out components. 4) I can use GPT and finally partition as much as I want. GPT is independent of UEFI. Many operating systems support the use of GPT partitioning in a BIOS environment (see Windows and FreeBSD, until recently, FreeBSD defaulted to doing so. Not sure if it still does, would have to spin up a VM and check against FreeBSD 12-CURRENT). GPT is a partition management scheme, UEFI is a bootloader scheme that requires GPT (interestingly, while it requires GPT to be understood, it does not require GPT to be necessarily used and can actually function with MBR drives, though in practice this does not happen. Mostly.). In addition, the GPT spec is purposely backwards compatible with BIOS by reserving the first 512 bytes of the disk (where the 446 bytes of MBR bootloader code followed by the 66 bytes of partition descriptors would be located), which can be used to point the traditional "BIOS bootloader" to a GPT partition to serve as a shoe-in. (I'm the developer of EasyBCD [0] and numerous other boot utilities that deal heavily with EFI/GPT dark magic [1]) [0]: https://neosmart.net/EasyBCD/ https://neosmart.net/EasyBCD/ [1]: https://NeoSmart.net/EasyRE/ https://NeoSmart.net/EasyRE/

gnufied 9y ago

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 actually contains things needed for booting these operating systems - it is almost always non-trivial to restore.

johncolanduoni 9y ago
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.
- ComputerGuru 9y ago
  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 §11.2.1.3: > For removable media devices there must be only one EFI system partition, and that partition must contain an EFI defined directory in the root directory But in practice, Bad Things (TM) happen if you have more than one ESP on the boot disk. An ESP isn't just a partition mounted to /boot or one that has bootfiles or a bootloader, it's (in practice) a FAT32 partition that has a different filesystem ID, in particular, the magic GUID {C12A7328-F81F-11d2-BA4B-00A0C93EC93B} I'm the author of EasyBCD and numerous other boot utilities and spent a hell of a lot of a time (too much time) researching and working around the various UEFI deficiencies in various desktops, laptops, firmware implementations, bootloaders, and operating systems. Here's a Microsoft bulletin on the matter: https://support.microsoft.com/en-us/help/2879602/unable-to-boot-if-more-than-one-efi-system-partition-is-present https://support.microsoft.com/en-us/help/2879602/unable-to-b... (long story short, the Windows kernel may bork if it runs into multiple ESPs and fail to load. Our bootable boot repair CDs wouldn't boot into the WinPE kernel because the disk management subsystem would hit an infinite loop in certain cases (not this case). We ended up switching to FreeBSD for our live CDs and writing our own disk repair subroutines to get around cases where even Windows live CDs wouldn't boot so we could fix the customer's PCs) Linux may not hang if there are multiple ESPs (except it sometimes does), but it certainly doesn't support treating multiple partitions as the ESP simultaneously, either: https://superuser.com/questions/688617/how-many-efi-system-partitions-esp-can-a-computer-have https://superuser.com/questions/688617/how-many-efi-system-p... [0]: https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf https://www.intel.com/content/dam/doc/product-specification/...
  - danudey 9y ago
    > 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?
    - ComputerGuru 9y ago
      > 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).
- cmurf 9y ago
  From my reading of the UEFI spec, much of the language assumes one EFI system partition per device, for example see the capsule updating language on page 262 of the version 2.4 spec. The directory \EFI\UpdateCapsule is checked for capsules only withing the EFI system partition on the device specified in the active boot option determine by reference to BootNext variable or BootOrder variable processing. and later The system firmware is not required to check mass storage devices that do not contain boot target that is highest priority for boot nor to check a second EFI system partition not the target of the active boot variable. There's no accounting for two ESP's for one device, and how to resolve the ensuing ambiguity, which one is the primary one? Are you certain Windows updates distinguish between two EFI system partitions, should an update need to update the Windows bootloader or its config?
  - ComputerGuru 9y ago
    Actually, it's even worse than that. As the BIOS no longer has a concept of "active device," multiple ESPs on separate devices are also a problem; the user would have to actively pick the one to load at boot time via the non-EFI "boot device menu" at the boot screen.
cmurf 9y ago
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
- dogma1138 9y ago
  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.
  - igravious 9y ago
    Great, but what magic key combo–or combos?
    - 9y ago
jiggunjer 9y ago
I always thought it a design flaw in OSes that always keep EFI partitions mounted (and writeable). I also read horror stories where someone bricks their pc/laptop by corrupting the UEFI (not the EFI partition, the actual firmware).
OOPMan 9y ago
Why are you sharing a UEFI partition between your OSes? Pretty sure you don't have to?

johncolanduoni 9y ago

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.

Sephr 9y ago
Maybe for AMD GPUs, but getting consumer Nvidia GPUs working with VT-d on Nvidia's drivers is a little difficult. GPU passthrough is not something Nvidia wants to support on consumer GPUs. Edit: s/very/a little/
- lathiat 9y ago
  It's "very difficult" because the drivers are intentionally nerfed not to load in a virtual environment. Your statement is entirely correct.
- irth 9y ago
  One line config change to hide the hypervisor from the VM and it works. (Source: worked for me)
- johncolanduoni 9y ago
  I've had no problem using consumer Nvidia GPUs with QEMU/KVM for this. All I needed to do was (1) use kvm=off (this does not turn off KVM, it just sort of hides it from the NVidia driver) and (2) on Windows, edit the registry to force enable Message Signaled Interrupts. When I tried it with an AMD card it would periodically crash the host when it was assigned to a Linux guest.
ComputerGuru 9y ago
This was mostly intentional, tbh. Both AMD and nVidia GPUs had "officially sanctioned" cards that worked just fine with their legacy VGA ROM.

garaetjjte 9y ago

>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.

aaronmdjones 9y ago
More specifically, BIOS machines don't know what partitions are (nor partition tables), and it's only the first 446-ish bytes, not 512.
chungy 9y ago
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.
jarman 9y ago
Also GPT partitions have little use when using mdraid/dm-crypt/lvm2 (or zfs) stack. IIRC Windows have similar features with dynamic partitions, so I don't see any reason to use bios partitioning for anything beyond boot (and MBR is enough for it, even without extended partitions).

thudson 9y ago

With LinuxBoot you can use any filesystem that Linux supports, not just FAT. You can update boot entries by editing shell scripts, rather than manipulating opaque NVRAM variables. You can run Linux applications straight from the ROM if you want to do that. You can avoid legacy partitions entirely and use LVM for flexible volume management. And... You can build it yourself and verify that the reproducible build matches what others have built to ensure that the firmware is clean. You can have the firmware attest to you via TOTP that it hasn't been changed. You can have a fully encrypted disk, with secrets sealed in the TPM and only unsealed if the firmware is unmodified. You can include device drivers for things that UEFI doesn't support. You can use external hardware tokens like a Yubikey to sign the OS install and have the firmware validate the GPG signature. Or what ever else you might want to do...

Annatar 9y ago
All very good and very valid points. Just wouldn’t want to do that with Linux. OpenBSD or FreeBSD, yes; illumos, yes; Linux - out of the question.
- pferde 9y ago
  You're probably getting downvoted because you did not follow up with "...because $reasons", so your post comes off as petty Linux hate (is there such word as "anti-fanboyism"?).
  - Annatar 9y ago
    Thanks for the clarification. In the context, most other posts here contain no technical detail whatsoever either and are nothing more than unsubstantiated opinions (same as mine); they just really dislike that there is someone out there who doesn’t think that Linux is phenomenal. In the days of Microsoft dominance, we called that monoculture. Volumes have been written and videos filmed on all the inadequacies of the GNU/Linux kernel, far more than I could cram into one “Hacker News” post. I for example get a painful reminder of just how unfit the Linux kernel is as firmware every time I turn on my television set which runs it (ARM V7 Linux for the curious). After that, I don’t want any more. That is not an isolated scenario. Apropos petty, my hate of GNU/Linux is epic.

Hello71 9y ago

> 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 handles this. in fact, it handles it much better than some firmwares, which usually have bugs relating to, among others, random rearrangement of boot order, failure to persist changes, and permanently adding entries for every flash drive you plug in. these have never happened to me with grub, and I do not expect them to. OTOH, I expect to see stupid bugs caused by firmware vendors de facto supporting single-drive Windows only, at least until the end of the PC platform as we know it. > I can forgo bootloaders entirely and use Linux as UEFI application. I guess this is nice, but honestly three binaries wasn't significantly worse than two. > I can use GPT and finally partition as much as I want. you can use GPT with BIOS too, it's just that MS doesn't feel like testing it so they lock it out for everybody.

danudey 9y ago
/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.

ComputerGuru 9y ago

I (see footnote) started off hating the UEFI because it changed everything for me and others working with bootloaders, but at this point I'm just ambivalent about it. It trades one set of problems for another. The biggest problem is with shoddy implementations and poor development/engineering practices by hardware and software vendors (I have some devices lying around from R&D that brick themselves if the ESP is erased; you can't even access the "BIOS" even if you remove the CMOS battery, can't boot from a removable disk, nada. Need to insert a physical, non-removable disk with an ESP compatible with that PC or mail it back in to the vendor for an RMA!) That said, your argument really boils down to a straw man. None of your points are really in favor of UEFI and some show a misunderstanding of the previous situation. I really recommend anyone that wants to better understand the (traditional) boot process have a read of this guide we wrote, complete with flowcharts and breakdowns, entitled "Everything you ever wanted to know about how your PC starts up (but were too afraid to ask)": https://neosmart.net/blog/2015/everything-you-ever-wanted-to-know-about-how-your-pc-boots-up/ https://neosmart.net/blog/2015/everything-you-ever-wanted-to... Anyway, to address your remarks: 1) I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. That has always been the case, at least any time in contemporary PC history. Ever since bootloaders grew past the 1 sector limit, the only code at the start of the drive has been a pointer (that can even be copied and pasted between Windows and Linux, etc. because it serves a universal purpose) that looks for and loads the first active, primary partition on the drive. That is where the actual bootloader code resides. 2) I can easily update, add and remove boot entries from the OS command line. This isn't anything to do with UEFI either, it's just a matter of your OS providing an interface for doing so. Microsoft did that back in 2006 for legacy bootloaders with bcdedit (that's where our free EasyBCD tool comes in) and we've developed standalone cli utilities for doing the same for GRUB under Linux. 3) I can forgo bootloaders entirely and use Linux as UEFI application. Sure. But that bootloader code has been integrated into the OS and the firmware. Really it's just reduced the abstraction and increased blurring between the layers. Makes it hard to swap out components. 4) I can use GPT and finally partition as much as I want. GPT is independent of UEFI. Many operating systems support the use of GPT partitioning in a BIOS environment (see Windows and FreeBSD, until recently, FreeBSD defaulted to doing so. Not sure if it still does, would have to spin up a VM and check against FreeBSD 12-CURRENT). GPT is a partition management scheme, UEFI is a bootloader scheme that requires GPT (interestingly, while it requires GPT to be understood, it does not require GPT to be necessarily used and can actually function with MBR drives, though in practice this does not happen. Mostly.). In addition, the GPT spec is purposely backwards compatible with BIOS by reserving the first 512 bytes of the disk (where the 446 bytes of MBR bootloader code followed by the 66 bytes of partition descriptors would be located), which can be used to point the traditional "BIOS bootloader" to a GPT partition to serve as a shoe-in. (I'm the developer of EasyBCD [0] and numerous other boot utilities that deal heavily with EFI/GPT dark magic [1]) [0]: https://neosmart.net/EasyBCD/ https://neosmart.net/EasyBCD/ [1]: https://NeoSmart.net/EasyRE/ https://NeoSmart.net/EasyRE/