8

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

Improve this question
3
  • Isn't the answer already in the question?
    – 炸鱼薯条德里克
    Feb 22, 2019 at 13:58
  • No, it isn't...
    – Tim
    Feb 22, 2019 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, 2019 at 6:44

2 Answers 2

Reset to default
7

/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.

Improve this answer
10
  • 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, 2019 at 13:29
  • 2
    boot.img is too limited because of size constraints.
    – Stephen Kitt
    Feb 22, 2019 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, 2019 at 16:49
  • 1
    UEFI solves the problem of multi-stage booting, where each stage consists of a primitive program that can load a more sophisticated program, and after repeating this sufficiently many times, the kernel can be loaded and started. On really old computers you would have to enter a program into memory using front panel switches. This program was barely enough to read a paper tape containing another program that could read sectors from a disk, which contained a program that understood the disk file system. UEFI is able to load the kernel from a disk file and start it in a single step.
    – Johan Myréen
    Feb 23, 2019 at 9:45
  • 1
    UEFI can load the kernel and start it in a single step, but often other EFI programs are started before the kernel. For example, in a multi-boot scenario, a chooser program like Refind or systemd-boot can be started first. The chooser program lets the user select which operating system to start, and then loads the appropriate kernel. Although the kernel can be loaded directly by the UEFI (or the chooser program), distros for some reason boot by first running GRUB, which then is used to load the kernel, although GRUB is redundant on UEFI machines.
    – Johan Myréen
    Feb 23, 2019 at 9:53
0

Source: https://www.gnu.org/software/grub/manual/grub/html_node/Images.html

Think of it like this:

boot.img is Stage 1
core.img is Stage 1.5
/boot/grub is Stage 2

The core.img has modules which allow the boot process to read disk types such as LVM and RAID, which the boot.img (in MBR) cannot read.

core.img IS a component of boot loader that has been split out of /boot/grub to make things more efficient by making it modular.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .