Go to the first, previous, next, last section, table of contents.


Embedded variables in GRUB

GRUB's stage1 and stage2 have embedded variables whose locations are well-defined, so that the installation can patch the binary file directly without recompilation of the modules.

In stage1, these are defined (The number in the parenthesis of each entry is an offset number):

stage1 version (0x3e)
This is the version bytes (should 03:00).
loading drive (0x40)
This is the BIOS drive number to load the block from. If the number is 0xff, then load from the booting drive.
stage2 sector (0x41)
This is the location of the first sector of the stage2.
stage2 address (0x45)
This is the data for the jmp command to the starting address of the component loaded by the stage1. A stage1.5 should be loaded at address 0x2000, and a stage2 should be loaded at address 0x8000. Both use a CS of 0.
stage2 segment (0x47)
This is the segment of the starting address of the component loaded by the stage1.

In the first sector of stage1.5 and stage2, the blocklists are recorded between firstlist (0x200) and lastlist (determined when assembling the file `stage2/start.S').

The trick here is that it is actually read backward, and the first 8-byte blocklist is not read here, but after the pointer is decremented 8 bytes, then after reading it, it decrements again, reads, decrements, reads, etc. until it is finished. The terminating condition is when the number of sectors to be read in the next blocklist is 0.

The format of a blocklist can be seen from the example in the code just before the firstlist label. Note that it is always from the beginning of the disk, and not relative to the partition boundaries.

In stage1.5 and stage2 (these are all defined at the beginning of `shared_src/asm.S'):

major version (0x6)
This is the major version byte (should be 3).
minor version (0x7)
This is the minor version byte (should be 0).
install_partition (0x8)
This is an unsigned long representing the partition on the currently booted disk which GRUB should expect to find it's data files and treat as the default root partition. The format of is exactly the same as the partition part (the disk part is ignored) of the data passed to an OS by a Multiboot-compliant boot loader in the boot_device data element, with one exception. The exception is that if the first level of disk partitioning is left as 0xFF (decimal 255, which is marked as no partitioning being used), but the second level does have a partition number, it looks for the first BSD-style PC partition, and finds the numbered BSD sub-partition in it. The default install_partition 0xFF00FF, would then find the first BSD-style PC partition, and use the `a' partition in it, and 0xFF01FF would use the `b' partition, etc. If an explicit first-level partition is given, then no search is performed, and it will expect that the BSD-style PC partition is in the appropriate location, else a `no such partition' error will be returned. If a stage1.5 is being used, it will pass its own install_partition to any stage2 it loads, therefore overwriting the one present in the stage2.
stage2_id (0xc)
This is the stage1.5 or stage2 identifier.
version_string (0xd)
This is the stage1.5 or stage2 version string. It isn't meant to be changed, simply easy to find.
config_file (after the terminating zero of version_string)
This is the location, using the GRUB filesystem syntax, of the config file. It will, by default, look in the install_partition of the disk GRUB was loaded from, though one can use any valid GRUB filesystem string, up to and including making it look on other disks. The boot loader itself doesn't search for the end of version_string, it simply knows where config_file is, so the beginning of the string cannot be moved after compile-time. This should be OK, since the version_string is meant to be static. The code of stage2 starts again at offset 0x70, so config_file string obviously can't go past there. Also, remember to terminate the string with a 0. Note that stage1.5 uses a tricky internal representation for config_file, which is the format of device:filename (`:' is not present actually). device is an unsigned long like install_partition, and filename is an absolute filename or a blocklist. If device is disabled, that is, the drive number is 0xff, then stage1.5 uses the boot drive and the install partition instead.


Go to the first, previous, next, last section, table of contents.