I find it best to keep in mind that an IBM-compatible PC is designed foremost to run Microsoft OS's which are much less flexible. Major distributions already conform well to the default way that recent Windows versions structure a brand new blank HDD from scratch, as well as the various derived ways PC vendors prepare their OEM hardware which is supplied with Windows pre-installed.
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.
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.