The quick & dirty question I have is... What app/script actually loads the Grub 2 menu system? And where is it located?

The longer question is I understand the core.img is loaded onto the first 63 sectors (stage 1.5) and after it loads I starts the stage 2 Grub bootloader which loads the Menu system. I've searched to try & figure this out but all I keep seeing are references to an ambiguous "Grub 2 bootloader"... What is the exact process of transferring the boot process between stage 1.5 and stage 2?

Can someone PLEASE help me with the specifics... at this point finding the answer has kicked in my OCD & it's driving me crazy.... Thanks!!!

References to things like the stage 1.5 etc relate to the old GRUB 1 bootloader, which is almost certainly not used any more.

GRUB2 is totally different - there is a lot of documentation at https://www.gnu.org/software/grub/manual/grub.html

Could you be more specific with your question?
Do you have a UEFI boot or a "legacy" MBR type boot?

Thank you for the reply!!!

At the moment I'm simply trying to understand how Grub 2 boots a machine in an MBR environment

The way I've understood things is under MBR boot.img is loaded into the 1st sector of a disk drive (Stage 1)... That in turn reads/loads diskboot.img... Which reads/loads core.img that's in the next 63 sectors... Which loads the file system module... Mounts the /boot/grub file system (Stage 1.5)... Unfortunately that's where documentation seems to drop off... And all I've been able to find is after that is documentation that just say's the Grub menu system loads (Stage 2) but not what's being loaded... I'm assuming the core.img is doing it, but I'm unclear on what exactly core.img is loading to start the Grub Menu system

If my understanding isn't correct please let me know... Hopefully I'ts just a matter of me learning what core.img is loading to start the Grub menu system

Once again... thank you for the reply and assistance!

The old version of GRUB would
execute a few dozen bytes of code, held in the 512 bytes of the MBR;
this was sufficient to execute a limited piece of code (the "stage 1.5" code).

This was sufficient to launch a final "stage 2" piece of code.
AFAIK this last piece of code was the only one which was variable in that it could read disk files etc
The purpose of GRUB is to initiate an actual boot - so the last piece would give control to the initial start-up program for the specified OS.

However, GRUB was replaced by GRUB2 some years ago and the old version of GRUB is no longer being actively developed.
GRUB2 is quite different.

Why do you think the scirpt is not core.img? You go from core.img directly to the boot menu displayed per the code in grub.cfg.

I don't know exactly how it works but I can tell you from past experience when I somehow lost the core.img file from a Mint install and simply copied the core.img from an Ubuntu install to the Mint partition to see what would happen. It did 'not' load the Mint grub.cfg but rather the Ubuntu grub.cfg which was on another partition. I would have expected it to go to the Mint grub.cfg?? I'm not sure if core.img contains code pointing, in this example, to a location on the drive where the Ubuntu grub.cfg is or if part of the grub.cfg is contained in core.img. The core.img cannot contain the grub.cfg because grub.cfg on both systems is quite a bit larger (in relative terms) than the respective core.img files.

If you remove either core.img or grub.cfg, your Grub2 system won't boot. Either a message core.img can't be found or you get a grub prompt.

So I would say the core.img loads the menu (grub.cfg) but I don't know what the process is.

A list of the various img files (and a brief comparison between GRUB & GRUB2) can be found at https://www.gnu.org/software/grub/ma...de/Images.html

boot.img goes in the mbr. It has the physical address of core.img, which goes in the space after the mbr. The first sector of core.img has the physical addresses of all the others, so the whole thing can be loaded without needing to know anything about filesystems. core.img then loads grub modules from /boot/grub, including the grub shell module, which reads /boot/grub/grub.cfg and creates the boot menu from it.

1 members found this post helpful.

A *SUPERB* explanation! I made it into this web-search (which returns just a few great links):

"first sector of core.img" has the physical addresses boot.img

**THANKS**!! (motivated me to fix my antiX-core [cli-installer] with boot-repair-disk.iso)