Hi, David Christensen quoted Max Nikulin: > > UEFI almost certainly can boot from mbr (DOS) partition, otherwise it > > will be impossible to boot from USB pen drive. ...
Yes it can boot from a partition marked in a MBR/DOS partition table which if formatted as FAT filesystem. But a USB stick could alternatively have a GPT (GUID partition table) with a partition with FAT filesystem. (Legacy mode CSM can boot from the machine code in the MBR and needs no partitions at all for that stage.) David Christensen wrote: > AIUI the USB pen drive must be partitioned specially, each partition must be > formatted specially (e.g. raw machine code, binary data structures, > filesystems, etc.), and the various boot loader stages must be coded > specially for a USB pen drive to boot in both BIOS computers and in UEFI > computers. Not that special. For EFI there must be a FAT filesystem and a start program must have been found at predefined paths or marked by an EFI program which possibly interacts with the user. The predefined paths depend on the CPU type: \EFI\BOOT\BOOT*.EFI E.g. \EFI\BOOT\BOOTX64.EFI for amd64 and BOOTIA32.EFI for i386. > The Debian installer "ISO hybrid" format adds an additional dimension in > that the image can be burned either to an optical disc or to a USB disk, and > both media will boot in both BIOS and UEFI computers. Very "trick", indeed. Very dirty tricks. In legacy BIOS mode, the firmware hops from the MBR machine code to the CD boot image which then boots a SYSLINUX system. In EFI mode, the FAT filesystem image is marked by an MBR partition as hard disk system partition and also in the CD boot catalog as boot image. An invalid GPT mock-up is present to let older versions of OVMF EFI skip over its inappropriate demand for GPT. This FAT filesystem contains EFI programs by GRUB which bring up a full fledged GRUB system. > All of the above is predicted upon architecture, revision, and > configuration -- motherboard, processor, chipset, firmware, Setup > settings, expansion bus, adapters/firmware, optical/disk/flash > drives, etc.. That's mostly the job of the boot loader, SYSLINUX or GRUB or whatever. They use the services offered by the BIOS and their own software to start kernel and initrd of Debian GNU/Linux. Disks and optical media have to offer well known entry points in form of boot records, boot catalogs, or system partitions. By these entry points the firmwares learn about the boot loader software which it has to start. The entry points are firmware specific and thus in part specific to the CPU architecture. The spectrum of Debian bootable CDs is covered by my cheat sheet https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_sectors.txt In particular: EL Torito CD booting, for PC-BIOS x86, PowerPC, (old) Mac, EFI. Master Boot Record (MBR), for PC-BIOS x86 from (pseudo-) hard disk Apple Partition Map (APM), for more modern Mac GUID Partition Table (GPT), for EFI from (pseudo-) hard disk MIPS Volume Header, for MIPS Big Endian, e.g. SGI Indigo2. DEC Boot Block, for MIPS Little Endian , e.g. DECstation. SUN Disk Label and boot images, for SUN SPARC PowerPC Reference Platform (PReP), for IBM PowerPC Common Hardware Reference Platform (CHRP), for IBM PowerPC HP-PA via PALO header version 4 HP-PA via PALO header version 5 DEC Alpha SRM boot sector, for Alpha architecture Some of these architectures are decommissioned in Debian meanwhile. Have a nice day :) Thomas
