mjhjmtu

I think all the confusions in this post come from coexistence of old and new technologies and abuse of terminology such as mentioned in https://en.wikipedia.org/wiki/System_partition_and_boot_partition. I am not sure if creators of computer technologies or terms already try to avoid making things that are confusing and make things clearly and coherently documented. I can't figure them out on my own.

https://en.wikipedia.org/wiki/BIOS_boot_partition seems to mention different scenarios for different combinations of boot sector (GPT or MBR), firmware (BIOS or UEFI), bootloader (GRUB or ...?). I feel lost in reading it:

A BIOS boot partition is needed on GPT-partitioned storage devices to
hold the second stages of GRUB. On traditional MBR-partitioned
devices, the disk sectors immediately following the first are usually
unused, as the partitioning scheme does not designate them for any
special purpose and partitioning tools avoid them for alignment
purposes. On GPT-based devices, the sectors hold the actual partition
table, necessitating the use of an extra partition. On MBR-partitioned
disks, boot loaders are usually implemented so the portion of their
code stored within the MBR, which cannot hold more than 512 bytes,
operates as a first stage that serves primarily to load a more
sophisticated second stage, which is, for example, capable of reading
and loading an operating system kernel from a file system.

There is also an article for EFI partition https://en.wikipedia.org/wiki/EFI_system_partition. Since UEFI replaces BIOS, and BIOS is stored in ROM not in any partition, I thought UEFI is stored in ROM too, but fell into confusion when seeing "EFI partition". Is "EFI partition" a partition dedicated to store UEFI, or some bootloader program?

I also found https://askubuntu.com/a/579259/1471 which seems to explain better, but am still lost in the wording "booting Linux in legacy mode" and "booting another legacy operating system" and more.

Can you try to use plain language to describe what scenarios there are?

What are being deprecated and what are being adopted more and more and therefore worth my time to know?

Here is what I heard

1. Some OS books, such as Modern Operating System, say that part of a boot loader is stored in the MBR sector of a boot disk and and the rest of it is stored in the boot sector of a boot partition. There doesn't seem to be a partition dedicate to firmware or bootloader. I understand that a boot partition is where OS is installed, not a partition dedecated to store (part of) a bootloader. The MBR sector of a boot disk is also not a partition dedicated to store (part of) a bootloader.



2. 
   

   I have an old laptop, with GPT boot disk and a BIOS GRUB partition. I don't know if that partition is dedicate to store the full program of GRUB, or just part of GRUB, and the rest of GRUB is stored in the boot sector of the partition where the OS is installed, or ...?

   
   
   

   $ sudo parted -l
   [sudo] password for t: 
   Model: ATA ST1000LM014-1EJ1 (scsi)
   Disk /dev/sda: 1000GB
   Sector size (logical/physical): 512B/4096B
   Partition Table: gpt
   Disk Flags: 
   
   Number Start End Size File system Name Flags
    1 1049kB 2097kB 1049kB bios_grub
    2 2097kB 16.0GB 16.0GB linux-swap(v1)
    4 116GB 716GB 600GB ext4
    3 716GB 1000GB 284GB ext4
   

   
   


3. 
   

   I found an old but newer laptop, with GPT boot disk and a UEFI
   partition. I have similar questions as in 2, and I don't know if the UEFI partition stores UEFI or some bootloader (partial or full).

   
   
   

   $ sudo parted -l
   [sudo] password for t: 
   Model: ATA TOSHIBA MQ01ABF0 (scsi)
   Disk /dev/sda: 500GB
   Sector size (logical/physical): 512B/512B
   Partition Table: gpt
   Disk Flags: 
   
   Number Start End Size File system Name Flags
    1 1049kB 538MB 537MB fat32 EFI System Partition boot, esp
    2 538MB 500GB 500GB ext4
   

   
   
   

   Thanks.

   
   

I think it helps if you try to walk across the entire chain starting where you as a computer just finished Power On Self Test and have been issued to start an operating system from a particular disk. With MBR you face a lot of historic limitations and have to go very tiny steps and can only do very simple things. With UEFI you have platform drivers that can help you abstract hardware and tasks.

MBR chain:

• Boot loader code (vector) in the partition table.


• Master Boot Record with boot loader code between the end of the partition table and the first partition.


• Volume Boot Record on the OS or dedicated boot partition.


• Full boot loader with menu such as Grub on the OS or dedicated boot partition (to hold the OS kernel with drivers to read filesystems not supported by the boot loader).

MBR with GPT chain:

• Boot loader code on the BIOS boot partition.


• Volume Boot Record on the OS or dedicated boot partition.


• Full boot loader with menu such as Grub on the OS or dedicated boot partition (to hold the OS kernel with drivers to read filesystems not supported by the boot loader).

Since you are still booting the old way, you have to rely on old mechanisms like finding the next boot stage of the OS on the OS partition in the special first sector of the partition.

One of the unusual things I saw was how chrx developers boot 3rd party Linux on Chromebooks which have a special ChromeOS-GPT layout, as far as I remember I haven't seen a BIOS boot partition. Grub complains that it is unsafe to boot with block lists, but many users boot their Chromebooks with custom Linux this way.

UEFI chain:

• Boot loader in default or OS specific directory (e.g. /boot/efi/EFI/ubuntu) on the EFI System Partition on the OS partition.


• Full boot loader with menu such as Grub on the OS or dedicated boot partition (to hold the OS kernel with drivers to read filesystems not supported by the boot loader).

I have rsynced root partitions and only had to place the Grub image on the EFI partition in the right place (and the ESP partition flagged as such). This usually does not work with the more complex MBR boot chain where you have to ensure that not just files are in the right place but data patterns in the partition table, behind the partition table, that your OS partition isn't outside the range where it can be addressed from the boot loader code at this stage and that it is one of up to 4 primary partitions, not extended partitions (Grub can manage to boot in some of these scenarios too though).

I hope I did not cause more confusion. Sorry I can't put it any simpler at the moment, nor do I think that I have grasped the entire topic myself and I'm not involved with writing any code in this regard.