When installing Linux (CentOS 7), a guide instructed me to press TAB or ESCAPE to enter a CLI with a boot: prompt, to learn about booting with kickstart.

I'm just curious, is this CLI prompt GRUB2? Or does it have something to do with the 'Anaconda' Installer? Do I have access to most Linux commands, such as editing files on mounted drives etc...?


The answer is, surprisingly, "it depends on how exactly you're booting".

By pressing TAB or ESCAPE when the first message that speaks about CentOS appears, you're going to access the bootloader, and have the opportunity to add various boot options if necessary. This will result in the boot: prompt.

If you're booting in legacy BIOS style from optical media, the boot:prompt will be from ISOLINUX, the optical media variant of the SYSLINUX bootloader. You can see its configuration in the /isolinux/ directory on the media. The actual ISOLINUX bootloader is not a file: it is embedded directly into the structure of the ISO9660 image.

If you are booting in UEFI style from optical media, then the prompt will be from GRUB2. You'll find the UEFI bootloader (both 32-bit and 64-bit UEFI versions of it!) in the /EFI/BOOT directory on the media. There is also a second copy of the UEFI bootloaders in /images/efiboot.img on the media. It depends on the firmware implementation which copy of the bootloaders is actually being used, but because they both have the same content, it does not matter.

The El Torito boot structures of the ISO9660 filesystem of the CentOS installation media will have one set of boot parameters for legacy BIOS-style booting (referring to embedded ISOLINUX), and two more sets of boot parameters for UEFI booting: one for 32-bit ia32 UEFI, and another for 64-bit x64 UEFI. Both of these UEFI parameters will point into efiboot.img. You can use the dumpet tool to view the complete El Torito boot structures; other tools I've tried tend to show only the first set of boot parameters.

Here's an example output:

# dumpet -i CentOS-7-x86_64-DVD-1708.iso 
Validation Entry:
        Header Indicator: 0x01 (Validation Entry)
        PlatformId: 0x00 (80x86)
        ID: ""
        Checksum: 0x55aa
        Key bytes: 0x55aa
Boot Catalog Default Entry:
        Entry is bootable
        Boot Media emulation type: no emulation
        Media load segment: 0x0 (0000:7c00)
        System type: 0 (0x00)
        Load Sectors: 4 (0x0004)
        Load LBA: 5074 (0x000013d2)
Section Header Entry:
        Header Indicator: 0x91 (Final Section Header Entry)
        PlatformId: 0xef (EFI)
        Section Entries: 1
        ID: ""
Boot Catalog Section Entry:
        Entry is bootable
        Boot Media emulation type: no emulation
        Media load address: 0 (0x0000)
        System type: 0 (0x00)
        Load Sectors: 17976 (0x4638)
        Load LBA: 580 (0x00000244)

But if you have used dd to write the ISO image to USB media and are using that to boot the installer, the system will find the bootloaders in a different way.

First, the isohybrid preparation process has embedded a finely-crafted MBR partition table to the very beginning of the ISO image, indicating that the USB media now has two partitions: one covering the full size of the ISO image, with type ID 0x00, and another small partition (~ 10M or less) that seems to be embedded within the first partition, with type ID 0xef, indicating that it is an EFI system partition (ESP) on a MBR-partitioned disk. The second "partition" actually points to the contents of the efiboot.img file. There is also a GPT partition table structure that contains basically the same information.

(Yes, indicating that one partition lives inside another is technically a violation of the expected structure of the MBR, but the boot firmware is unlikely to be fussy about such details...)

The MBR block also contains an actual Master Boot Record of ISOLINUX, which covers the case of BIOS-style booting from an installation image written on the USB media. An UEFI firmware in native boot mode will ignore the MBR and look at the ESP, from where it will find the UEFI bootloaders (either 32- or 64-bit).

If you want to see how the ISO image works out when written to USB media, use losetup -P /dev/loop0 CentOS-7-x86_64-DVD-1708.iso and then use fdisk -l and similar tools to look at the partition structure:

# losetup -P /dev/loop0 CentOS-7-x86_64-DVD-1708.iso
# fdisk -l /dev/loop0
Disk /dev/loop0: 4.2 GiB, 4521459712 bytes, 8830976 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1302a8b3

Device       Boot Start     End Sectors  Size Id Type
/dev/loop0p1 *        0 8830975 8830976  4.2G  0 Empty
/dev/loop0p2       2320   20295   17976  8.8M ef EFI (FAT-12/16/32)

(The first partition is of type "Empty" probably because there is no valid MBR partition type ID for a ISO9660 filesystem...)

You can now even mount both partitions (read-only to avoid damage) and check what is inside each of them.

You may notice that the dumpet output identifies the beginning of the ESP boot image as LBA #580, while the fdisk indicates it starts at block #2320. This is because ISO9660 optical media uses a block size of 2048 bytes, while USB media uses the more common 512-byte block size.

  • 1
    Thanks for the explicit detail! – ChrisW Oct 21 at 16:22
  • @ChrisW A bigger thank you can be provided to telcoM by clicking on the up arrowhead to the left of the beginning of the answer, and also clicking on the check mark a little below that. – K7AAY Oct 21 at 23:14
  • I'm too new for it to be advertised! @K7AAY – ChrisW Oct 24 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.