For the curious‎ > ‎

The world of bootstrapping

This page gives an overview over some basic concepts about booting operating systems.
It is based on a conversation with dfe in #puredarwin.


Linux needs two files to boot.  A kernel, and an initrd
any time you upgrade your kernel you've got to build a new initrd to go with it
which pulls needed drivers off the filesystem as is and puts them into the initrd
now in Linux's case you're typically not going to be adding a driver needed at boot time to the filesystem after the fact
but in the case of Windows or OS X you'll have a lot of third-party drivers which the user might want to install at any time
therefore the bootloader must be able to read all of those drivers
which means the bootloader must be able to read the root filesystem
which the bootloader will do using BIOS calls to read sectors and its own code to read the filesystem

Windows NTLDR

NTLDR does basically the same thing
the boot sector knows barely enough to get NTLDR loaded, just like boot1 knows barely enough to get boot (a.k.a. boot2) loaded
once there, the second-stage bootloader (be it NTLDR or boot) has enough code to read the filesystem and locate the kernel and drivers
in NTLDR's case it even has enough code to read a registry hive which tells it which drivers to load rather than simply loading any drivers that might be needed for boot
which is also why windows won't boot if you move the hard drive to a different system.  The system registry hive only says to load say the 440bx HD controller driver, not the ICH-7 driver or the VIA driver or whatever
that's part of the reason why EFI is such a big deal. 


With EFI you've got a decent 32-bit callable interface to read sectors from the hard drive
plus you're guaranteed to be able to read FAT32
plus you can supply drivers for other filesystems
so it enables you to write bootloaders that can read quite a bit, certainly enough to get all the individual drivers loaded
Now take something like GRUB for instance.  GRUB is actually advanced enough that it code theoretically load a vmlinuz and a  number of .ko files to get the system loaded.  But which .ko files would it load?
if you look on a macbook you'll note that everything you need to boot is in ROM
there's hardly anything in the EFI partition
well there never was anything on the service partition because Apple has enough in the firmware that it doesn't need the service partition
but that's because Apple wants to explicitly support booting of OS X which is an addition to the EFI spec
and to boot from CD apple may have used the EFI El Torito spec to load enough to get the HFS+ driver and boot.efi loaded
then boot.efi could take over as per usual
yeah, take the linux case for instance
assume you had everything to do from scratch and there was no legacy of initrds
what you would probably do is write an ext2/3 driver for EFI
and you might then have a bootloader which looked for a config file to tell it which kernel and set of drivers to load
yeah, if OS X was made to run on generic PCs then the CD might have a custom loader that was just good enough to load an HFS+ driver and the real second-stage booter (boot.efi)
notice how nothing really changes from x86 boot here.  You still have the situation of a first stage loader good enough to load the second stage loader which is good enough to load the OS
welcome to the world of bootstrapping


multiboot is an open specification designed to allow you to boot a kernel straight into protected mode
for it to have any chance of working you've either got to have enough in the kernel itself to be able to root or you've got to supply modules to the kernel
the multiboot spec can supply modules to the kernel though
but again you wind up in a similar situation.  Now part of your bootstrapping code is sort of in the kernel
at least it has to have enough code to know how to link in the additional modules because let's face it, at some point you need to root a filesystem
there's no getting around that
typically multiboot is used primarily for toy operating systems
yes, multiboot doesn't really give you a whole lot
basically all it does is say that your kernel and some number of additional files will have been loaded by the bootloader
basically all it does is say that your kernel and some number of additional files will have been loaded by the bootloader
and then the bootloader will jump into your code which will start in protected mode

Modified boot-132 to run as multiboot kernel

kernel being boot-132 in our special case
well the reason for multiboot in boot-132 is to avoid having to replace the startup file to develop it
and boot-132 uses multiboot in a rather queer way
basically there's an alternative entrypoint coming from the multiboot bootloader
that entrypoint sets up enough to get a stack and whatnot and from there runs the bootloader as per usual
i.e. it still thunks into real-mode to make BIOS calls
Q: So in a nutshell, it's BIOS/EFI -> (GRUB) and/or boot1 (our "kernel" for argument's sake) -> boot2 -> xnu (our "real" kernel)?
when using multiboot there is no boot1
GRUB boots boot(2) directly
that is the point of it
the reason being that 512 bytes for boot1h is barely enough to find the HFS+ startupfile and load it
now it's really the case that you're guaranteed to have 1024 bytes available which as we've seen is actually enough to read some of the HFS+ directory structure and find a file in the root
but even then the 1024-byte is really not enough to do it right

Network booting

Q: from a server's perspective the i386 network boot mechanisms are all the same?
yeah, just provide an IP via DHCP and files via TFTP


PXE is an x86 thing
it does use TFTP like basically everything else out there to grab the kernel and modules (extensions) though
actually bootstrapping over the network is interesting
regardless of platform this is basically how it is supposed to go down
DHCP or BootP so the firmware can get itself an IP address
TFTP to actually grab the bootloader
which depending on system might be a first-stage loader (PXE tends to require this) or might be THE loader
PXE tends to require it primarily because PXE spec says to only force the firmware to load 32k
so 32k is usually only enough to get your own code in place that can load the larger real booter
either way you'll eventually get the real (second-stage) booter loaded

BootX (PPC)

for PPC that'd be BootX
so BootX itself would be loaded by OpenFirmware
from there BootX will make open firmware calls to load more files from tftp, including the kernel and hopefully the Extensions.mkext package

Netboot (PPC)

although PPC Macs have the whole netboot spec too
which is some more stuff on top of TFTP/DHCP
there is a command to do a netboot in openfirmware
typically just hold down N


ditto for Windows NT, it has a special server program
there's actually a server program that tells the client which drivers it needs
the Windows PXE client enumerates PCI devices and sends that info to this special server
the special server responds back and tells it which drivers it needs to download via TFTP


the thing is that this kinda goes back to what I was talking about earlier on having to know which drivers to load
there's different ways to accomplish it
Windows actually has a client/server thing to do this and the client side tells the server about the hardware and the server then does the hard work of sifting through the INF files to determine which SYS files to load
a typical Linux setup uses an initrd
for something like Fedora the initrd intended for PXE boot will basically contain any driver (.ko) that might possibly be needed to root locally or over the network
for OS X it's similar except that instead of an initrd you have an Extensions.mkext