Editing GNU GRUB (section)

==={{Anchor|MAP-FILE}}Booting===
{{See also|UEFI disk device compatibility}}

When a computer is turned on, its [[BIOS]] finds the primary bootable device (usually the computer's hard disk) and runs the initial [[Bootstrapping (computing)|bootstrap]] program from the [[master boot record]] (MBR). The MBR is the first [[Disk sector|sector]] of the hard disk. This bootstrap program must be small because it has to fit in a single sector. For a long time, the size of a sector has been 512&nbsp;bytes. Since 2009 there are hard disks available with a sector size of 4096&nbsp;bytes, called [[Advanced Format]] disks, but {{as of|2013|10|lc=y}}, such hard disks are still accessed in 512-byte sectors, using the [[Advanced Format#512e|512e emulation]].<ref>{{cite web
 |last         = Smith
 |first        = Ryan
 |title        = Western Digital's Advanced Format: The 4K Sector Transition Begins
 |publisher    = [[AnandTech]]
 |date         = December 18, 2009
 |url          = http://www.anandtech.com/show/2888
 |access-date  = October 10, 2013
 |archive-date = March 12, 2012
 |archive-url  = https://web.archive.org/web/20120312061308/http://www.anandtech.com/show/2888
 |url-status   = live
}}</ref>
The legacy [[MBR partition table]] supports a maximum of four partitions and occupies 64&nbsp;bytes, combined. Together with the optional [[MBR disk signature|disk signature]] (four bytes) and [[MBR disk timestamp|disk timestamp]] (six bytes), this leaves between 434 and 446&nbsp;bytes available for the [[machine code]] of a boot loader. Although such a small space can be sufficient for very simple boot loaders,<ref>{{cite web
 |url          = http://mbldr.sourceforge.net/
 |title        = mbldr (Master Boot LoaDeR)
 |year         = 2009
 |access-date  = October 10, 2013
 |website      = mbldr.sourceforge.net
 |archive-date = March 16, 2013
 |archive-url  = https://web.archive.org/web/20130316062331/http://mbldr.sourceforge.net/
 |url-status   = live
}}</ref> it is not big enough to contain a boot loader supporting complex and multiple [[file system]]s, menu-driven selection of boot choices, etc. Boot loaders with bigger footprints are therefore split into pieces, where the smallest piece fits in the MBR, while one or more larger pieces are stored in other locations such as empty sectors between the MBR and the first partition. The code in the MBR then does little more than starting the second part.

The purpose of the remaining part(s) of the boot loader is to actually boot an operating system by configuring it and starting the [[kernel (operating system)|kernel]]. Kernels are in most cases stored as files residing on appropriate file systems, but the concept of a file system is unknown to the BIOS. Thus, in BIOS-based systems, the duty of a boot loader is to access the content of those files, so it can be loaded into the [[RAM]] and executed.

One possible approach for boot loaders is to load kernel images by directly accessing hard disk sectors without understanding the underlying file system. Usually, an additional level of [[indirection]] is required, in form of ''maps'' or ''map files''{{snd}} auxiliary files that contain a list of physical sectors occupied by kernel images. Such maps need to be updated each time a kernel image changes its physical location on disk, due to installing new kernel images, file system defragmentation, etc. Also, in case of the maps changing their physical location, their locations need to be updated within the boot loader's MBR code, so the sectors indirection mechanism continues to work. This is not only cumbersome, but it also leaves the system in need of manual repairs in case something goes wrong during system updates.<ref name="boot-admin">{{cite web
 | url        = http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.0/adminguide-9.0/node8.html
 | title        = Booting and Boot Managers
 | access-date        = 2013-10-10
 | publisher        = SUSE
 | archive-date        = September 17, 2013
 | archive-url        = https://web.archive.org/web/20130917130646/http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.0/adminguide-9.0/node8.html
 | url-status        = live
 }}</ref>

Another approach is to make a boot loader aware of the underlying file systems, so kernel images are configured and accessed using their actual [[Path (computing)|file path]]s. That requires a boot loader to contain a driver for each of the supported file systems, so they can be understood and accessed by the boot loader itself. This approach eliminates the need for hardcoded locations of hard disk sectors and existence of map files, and does not require MBR updates after kernel images are added or moved around. The configuration of a boot loader is stored in a regular file, which is also accessed in a file system-aware way to obtain boot configurations before the actual booting of any kernel images. Thus, fewer things can go wrong during system updates. As a downside, such boot loaders are larger and more complex.<ref name="boot-admin" />

GNU GRUB uses the second approach, by understanding the underlying file systems. The boot loader itself is split into multiple ''stages'' so that it fits in the MBR boot scheme.

Two major versions of GRUB are in common use: GRUB version 0, called ''GRUB legacy,'' is only prevalent in older releases of Linux distributions. ''GRUB 2'' was written from scratch and intended to replace its predecessor, and is now used by a majority of Linux distributions.