4 ms·

Debian will still support UEFI, just not SB. I use Arch and UEFI. With a kernel supporting EFISTUB, a UEFI system can boot the kernel directly, without the use

Debian will still support UEFI, just not SB. I use Arch and UEFI. With a kernel supporting EFISTUB, a UEFI system can boot the kernel directly, without the use of a bootloader - it's awesome!

mixmastamyk 9y ago
Does that mean you can skip the efi partition?
- josteink 9y ago
  No. The kernel is its own bootloader and that must be on the EFI partition. The UEFI spec pretty much says it must be there. What's your big problem with that, anyway? :)
  - mixmastamyk 9y ago
    Waste of space, and extra complexity. This is a thread about over engineering, right?
    - josteink 9y ago
      I'll agree lots of bits of the UEFI-spec represent solid over-engineering, but the EFI partition is IMO not one of those bits. It standardizes how to deploy a bootloader in a multi-boot friendly way without any cheating, tricks or risk of "competing" OSes stepping on each other's toes. It significantly reduces complexity in all cases except for the simplest of them all, and even in those cases it represents a reliable standardization so it's possible for people (like you and me!) to inspect what actually gets booted, how and why. Try that with ad-hoc MBR-written voodoo-tracks outside the FS and partitions. Now try it again as a OS-vendor who doesn't want to risk bad PR by accidentally overwriting existing bootloaders. I honestly think this part of the UEFI spec is among those which makes most sense and is least problematic.
      - mixmastamyk 9y ago
        Ok. But as a single OS user I'd prefer the space used be in the writeable area of the firmware rather than taking up my disk.
        josteink 9y ago
        > But as a single OS user I'd prefer the space used be in the writeable area of the firmware rather than taking up my disk. OK. That's your preference. But now consider this use-case: You are installing a new OS, your first OS, on a blank PC, on a new disk. All is grand. No toes to step on. How does that OS deploy its bootloader? You vote it should chose a simplistic way which is optimized for the single-OS use-case. It's primary objective: To save space, around 500MB of space, because you think that's something which matters. But let's say you were actually planning for a dual-boot scenario. Now you're in the process of installing your second OS. How should that OS deploy its bootloader? To determine that it is indeed a single-OS use-case (and this that it should use the single-OS simplistic approach, which differs from the multi-OS approach), it needs to find out if another OS and another bootloader is deployed. How should it know that? How should it be certain it doesn't overwrite something which doesn't belong to it? And since we are now moving from a single-OS solution to a multi-OS solution... Should we migrate the existing simplistically deployed bootloader to a multi-OS config and wipe the existing single-OS configuration? To put it bluntly: Should Windows move Linux's bootloader? Can you imagine the outrage? Any and every honest bug in such code would be deemed malicious by internet hotheads and be talked about for decades to come in threads filled with "M$". And this is all getting very complex, very fast, isn't it? It wasn't so simple after all, was it? With the EFI-partition there is a simple solution and simple answers for all those questions, at any point. Inspecting the state of bootloaders is simple. Deploying OSes is simple. Avoiding collisions is the default because different OSes namespace their bootloaders inside the EFI partition. Windows doesn't even need to know or care if Linux is installed! Everything just works. At a cost. The cost of allocating a few MBs in the age when Terabytes rules. And honestly, I find that a pretty good trade-off.
        mixmastamyk 9y ago

Debian will still support UEFI, just not SB. I use Arch and UEFI. With a kernel supporting EFISTUB, a UEFI system can boot the kernel directly, without the use of a bootloader - it's awesome!

mixmastamyk 9y ago

Does that mean you can skip the efi partition?

josteink 9y ago
No. The kernel is its own bootloader and that must be on the EFI partition. The UEFI spec pretty much says it must be there. What's your big problem with that, anyway? :)
- mixmastamyk 9y ago
  Waste of space, and extra complexity. This is a thread about over engineering, right?
  - josteink 9y ago
    I'll agree lots of bits of the UEFI-spec represent solid over-engineering, but the EFI partition is IMO not one of those bits. It standardizes how to deploy a bootloader in a multi-boot friendly way without any cheating, tricks or risk of "competing" OSes stepping on each other's toes. It significantly reduces complexity in all cases except for the simplest of them all, and even in those cases it represents a reliable standardization so it's possible for people (like you and me!) to inspect what actually gets booted, how and why. Try that with ad-hoc MBR-written voodoo-tracks outside the FS and partitions. Now try it again as a OS-vendor who doesn't want to risk bad PR by accidentally overwriting existing bootloaders. I honestly think this part of the UEFI spec is among those which makes most sense and is least problematic.
    - mixmastamyk 9y ago
      Ok. But as a single OS user I'd prefer the space used be in the writeable area of the firmware rather than taking up my disk.
      - josteink 9y ago
        > But as a single OS user I'd prefer the space used be in the writeable area of the firmware rather than taking up my disk. OK. That's your preference. But now consider this use-case: You are installing a new OS, your first OS, on a blank PC, on a new disk. All is grand. No toes to step on. How does that OS deploy its bootloader? You vote it should chose a simplistic way which is optimized for the single-OS use-case. It's primary objective: To save space, around 500MB of space, because you think that's something which matters. But let's say you were actually planning for a dual-boot scenario. Now you're in the process of installing your second OS. How should that OS deploy its bootloader? To determine that it is indeed a single-OS use-case (and this that it should use the single-OS simplistic approach, which differs from the multi-OS approach), it needs to find out if another OS and another bootloader is deployed. How should it know that? How should it be certain it doesn't overwrite something which doesn't belong to it? And since we are now moving from a single-OS solution to a multi-OS solution... Should we migrate the existing simplistically deployed bootloader to a multi-OS config and wipe the existing single-OS configuration? To put it bluntly: Should Windows move Linux's bootloader? Can you imagine the outrage? Any and every honest bug in such code would be deemed malicious by internet hotheads and be talked about for decades to come in threads filled with "M$". And this is all getting very complex, very fast, isn't it? It wasn't so simple after all, was it? With the EFI-partition there is a simple solution and simple answers for all those questions, at any point. Inspecting the state of bootloaders is simple. Deploying OSes is simple. Avoiding collisions is the default because different OSes namespace their bootloaders inside the EFI partition. Windows doesn't even need to know or care if Linux is installed! Everything just works. At a cost. The cost of allocating a few MBs in the age when Terabytes rules. And honestly, I find that a pretty good trade-off.
        mixmastamyk 9y ago