Go to the first, previous, next, last section, table of contents.
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.