I see no problems with secure boot from a freedom perspective as long as the owner of the computer can install their own trusted public keys. There might be industry players that would like to remove that possibility. But why Poettering's work would make that easier I fail to see.

Do you think once a real secure Linux boot is possible they will remove machine owner rights and you have to buy a signed Linux from Microsoft? Or from a Microsoft/IBM/? consortium super monopoly?

It was not, ironically because of Microsoft. Shim is by policy effectively only allowed to boot grub2. So systemd-boot can't be used OOTB on secure boot enabled systems, you'd have to enroll your own key.

It has been possible for years. I have used it for 4 years myself and I was not the first adopter.

> Shim is by policy

I am not talking about shim, you don't have to use it.

Here's how to do it:

1. You erase the whole key database from UEFI (That possibility was some agreement between antitrust authorities and Intel and/or Microsoft that such possibility must be provided because Wintel was in a a dominating marketing position. On Arm devices it is often not possible, Windows / ARM is not in a dominating position and antitrust was not relevant.)

2. You generate your own key pairs.

3. The public ones you install into the secure boot database of UEFI.

4. You sign your UEFI application with your private key.

I have done that with `systemd-boot` and with the Linux kernel (containing the UEFI stub). Works in both cases. I used the instructions from https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Inst... 4 years ago and still do it the same way today.

Deleting the key database can not be done programmatically (unless UEFI has a bug). In all machines I have looked it's an option in the BIOS. So that should be clear case of warranty repair. Which of course does not help you if you do it after warranty has ended.

It's an option in the UEFI.

I guess it remains unclear whether it was a firmware bug that has since been corrected or whether it depends on how exactly the user installs their own keys.

The reply the UEFI itself would be signed and if you delete the matching keys from the relevant DB UEFI would no longer start does not sound right to me.

Good the see that the option exists for AMD, too. I guess AMD had no dominating market share when secure boot was introduced. So they would probably not be legally obliged to provide it? Hopefully market power of those requiring independence of Microsoft is big enough to keep it that way.

I can't exactly figure out how they'd use that level of control over the Linux boot, but I'm not a huge fan of them having it.

The better that Linux conforms to this range of layout structures, the more overall effectiveness you will have when multibooting, especially the massive multibooting possibilities unique to the UEFI boot method.

You're not going to figure this out on only one manufacturer's hardware, and not over a single-year period.

100MB boot partition is not enough, 500MB either. My first FAT32 partition is always the full 32GB that regular FAT32 is made for, but it's the same HDD structure. I've got plenty of space.

In UEFI I like to put my Linux kernels all on the FAT32 volume where I can handle them along with my Grub files entirely from Windows if I want. I carefully engage the Grub menu autoconfig so my custom bootmenu containing my up-to-date kernel choices is not lost or mangled.

Fundamentally in different Windows versions the particular Windows kernels are stored on the different partitions, and the bootloader just picks a partition. With Linux the different distributions are installed to their own separate EXT partitions, but are not strictly tied to the exact kernel they were issued with. When you update the kernel you can just copy it to the FAT32 volume, then put it on the bootmenu to replace the previous one, or as an alternative. Whether or not you want to update the entire remainder of any distro.

Each Grub bootmenu entry specifies which kernel will be loaded first from which folder on which partition, followed by which full distribution will be loaded next from the same or a different partition.

But this is the forbidden ESP partition, U may not want to go there but EFI already is.

To tame the beast you're going to have to change its identity (temporarily) so you can edit it willy-nilly.

Change or edit its partition GUID designation from ESP to Basic and a proper mainboard UEFI will still reboot by finding the EFI folder on the FAT32 volume as before, but in Windows you will now be able to assign a letter volume to the ordinary FAT32 partition and see the EFI folder there.

If it doesn't boot EFI without the strict ESP GUID in place, you would have to edit it "offline" from externally booted media.

As a very basic bare-metal layout all you need on a FAT32 volume is an EFI folder containing a BOOT folder (EFI\BOOT) containing a bootx64.efi file and it's off to the races.

But bootx64.efi's are squirrely beasts.

It's almost like no two are alike, god I hope these are real code and not generated.

Each OS install can have its own predictable way of overwriting the previous bootx64.efi with its own, sometimes more predictable than others.

A Windows bootx64.efi will then look for an \EFI\Microsoft folder, drill down to EFI\Microsoft\Boot\BCD and run the Windows bootloader

A Ubuntu bootx64.efi will look for \EFI\ubuntu and run the Grub found there

Each OS installed adds its own specific \EFI\XXX folder to the ESP and they are all independent.

But by convention the latest installed OS takes over as the bootloader going forward, simply by overwriting bootx64.efi with its own, and you may need to rely on an autodetect process to update your new bootmenu in its corresponding \EFI\XXX folder, to list all OS's that were previously installed to their partitions.

Otherwise you may need to fill out the config file bootmenu entries custom or manually, or switch back to one of the previous bootloaders which update Grub to include additional distros more ideally.

You will see that different distros sometimes have Grub fully in the ESP, which can include the kernels or not, and others where a good number of the Grub files are on their EXT volume, but mounted interestingly after you have booted. When kernels are only present by default on the EXT volume, I leave them there but place a copy into the working ESP folder(s) additionally.

>Boot Partition Discovery

>The traditional boot partition was not recognizable by looking just at the partition table. On MBR systems it was directly referenced from the boot sector of the disk

Actually not so. The partition table is only the final few bytes of sector 0, and whichever of the 4 possible primary partitions is currently marked for bootability has always been clear to see. It will be the one with the 80h, all others are supposed to have 00 as a boot flag.

Therefore you can (I advise) have duplicate or alternative boot files on each primary legacy partiton, each of which can boot its own OS, or boot to any of the other primary or logical volumes from the flagged partition's own unique (or identical) bootmenu. You choose which primary partition's boot files will be "Active" by placement of the boot flag, and it reboots accordingly. All other boot files remain dormant on their non-flagged partitions.

Except for the partition table at the end, the bulk of sector 0 is the Master Boot Record itself for that HDD, which is the code that runs to find a primary partiton marked Active. Control then transfers to the active partition's first sector which is supposed to be a Volume Boot Record commonly known as a boot sector.

A DOS bootsector then seeks IO.SYS on that volume in a filesystem it understands, an NT5 bootsector would seek NTLDR, and an NT6 bootsector seeks BOOTMGR from there before parsing any multiboot menus contained in config.sys, boot.ini, or BCD, respectively.

In Linux a Syslinux bootsector seeks ldlinux.sys, Grub seeks grub.cfg.

>ESP can be auto-discovered from the partition table, traditional boot partition cannot.

Nope, not true, this is the same misconception as above.