What are the differences between the purposes of core.img and files in /boot/grub? Thanks.

I often heard of two stage bootloading. while here seems to be three stage bootloading in https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB)

Stage 1: boot.img is stored in the master boot record (MBR) or optionally in any of the volume boot records (VBRs), and addresses the next stage by an LBA48 address (thus, the 1024-cylinder limitation of GRUB legacy is avoided); at installation time it is configured to load the first sector of core.img.

Stage 1.5: core.img is by default written to the sectors between the MBR and the first partition, when these sectors are free and available. For legacy reasons, the first partition of a hard drive does not begin at sector 1 (counting begins with 0) but at sector 63, leaving 62 sectors of empty space not part of any partition or file system, and therefore not prone to any problems related with it. Once executed, core.img will load its configuration file and any other modules needed, particularly file system drivers; at installation time, it is generated from diskboot.img and configured to load the stage 2 by its file path.

Stage 2: files belonging to the stage 2 are all held in /boot/grub, which is a subdirectory of the /boot directory specified by the Filesystem Hierarchy Standard (FHS).

enter image description here

  • Isn't the answer already in the question? – 炸鱼薯条德里克 Feb 22 at 13:58
  • No, it isn't... – Tim Feb 22 at 14:06
  • They're used to show you the general idea of how grub works, doesn't mean all bootloader work like this. It can be completely different. – 炸鱼薯条德里克 Feb 23 at 6:44

/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition maps, methods of interaction with the user, etc.

core.img contains a small subset of GRUB, typically aiming for 32KiB or less. Its purpose is to provide access to /boot/grub: it contains a minimal user interface, and whatever modules are necessary to find and read /boot/grub. It is built specifically for each system it is installed on, based on the requirements of that system, using the grub-mkimage program. See the list of images in the GRUB documentation.

  • Thanks. I saw the link. But I think core.img is the main part of GRUB. If Its purpose is to provide access to /boot/grub, why not just make boot.img access directly /boot/grub? – Tim Feb 22 at 13:29
  • boot.img is too limited because of size constraints. – Stephen Kitt Feb 22 at 13:35
  • This exemplifies the huge technical difference between booting using the legacy BIOS and UEFI. The only thing the BIOS is capable of doing is provide a primitive interface to read a disk sector by sector, read the MBR into memory an start execution of the code. UEFI, on the other hand, contains code in ROM that is able to read files from a FAT file system, and provides a rich assortment of system services that the EFI executables can use. – Johan Myréen Feb 22 at 16:49
  • Is this a three stage boot loading? Then what about the two-stage boot loading often heard and seen in OS textbooks: first stage bootloader code is in MBR of a boot disk, and second stage bootloader code in boot sector of a partition? – Tim Feb 23 at 2:50
  • @JohanMyréen How many stages are there in the bootloading stages in UEFI? I am trying to picture a diagram for the bootloading stages in UEFI, similar to the diagram of bootloading stages in BIOS in upload.wikimedia.org/wikipedia/commons/4/45/…? – Tim Feb 23 at 3:09

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.