GNU GRUB

Last updated

GNU GRUB
Original author(s) Erich Boleyn
Developer(s) GNU Project
Initial release1995;29 years ago (1995)
Stable release
2.12 [1]   OOjs UI icon edit-ltr-progressive.svg / 20 December 2023
Preview release
2.12-rc1 [2]   OOjs UI icon edit-ltr-progressive.svg / 10 July 2023
Repository
Written in Assembly, C [3]
Operating system Linux, GNU/Hurd, macOS, BSD, (Solaris/ illumos (x86 port)), and Windows (through chainloading)
Platform IA-32, x86-64, IA-64, ARM, PowerPC, s390x, MIPS, RISC-V, LoongArch and SPARC
Available in English and others
Type Bootloader
License 2007: GPL-3.0-or-later [lower-alpha 1] [5]
1999: GPL-2.0-or-later [lower-alpha 2]
Website www.gnu.org/software/grub

GNU GRUB (short for GNU GRand Unified Bootloader, commonly referred to as GRUB) is a boot loader package from the GNU Project. GRUB is the reference implementation of the Free Software Foundation's Multiboot Specification, which provides a user the choice to boot one of multiple operating systems installed on a computer or select a specific kernel configuration available on a particular operating system's partitions.

Contents

GNU GRUB was developed from a package called the Grand Unified Bootloader (a play on Grand Unified Theory [6] ). It is predominantly used for Unix-like systems.

Operation

GRUB2 on MBR-partitioned hard drive; stage 1 (boot.img) can alternatively be written into one of the partition boot sectors. GNU GRUB on MBR partitioned hard disk drives.svg
GRUB2 on MBR-partitioned hard drive; stage 1 (boot.img) can alternatively be written into one of the partition boot sectors.
GRUB2 on a GPT-partitioned hard drive, booting on BIOS firmware, or UEFI compatibility mode (CSM) GNU GRUB on GPT partitioned hard disk drives.svg
GRUB2 on a GPT-partitioned hard drive, booting on BIOS firmware, or UEFI compatibility mode (CSM)

Booting

When a computer is turned on, its BIOS finds the primary bootable device (usually the computer's hard disk) and runs the initial bootstrap program from the master boot record (MBR). The MBR is the first 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 bytes. Since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks, but as of October 2013, such hard disks are still accessed in 512-byte sectors, using the 512e emulation. [7] The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes, combined. Together with the optional disk signature (four bytes) and disk timestamp (six bytes), this leaves between 434 and 446 bytes available for the machine code of a boot loader. Although such a small space can be sufficient for very simple boot loaders, [8] it is not big enough to contain a boot loader supporting complex and multiple file systems, 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. 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  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. [9]

Another approach is to make a boot loader aware of the underlying file systems, so kernel images are configured and accessed using their actual file paths. 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. [9]

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.

Version 0 (GRUB Legacy)

GRUB v1 menu (running as part of Ubuntu 8.04 installation) GRUB screenshot.png
GRUB v1 menu (running as part of Ubuntu 8.04 installation)

GRUB 0.x follows a two-stage approach. The master boot record (MBR) usually contains GRUB stage 1, or can contain a standard MBR implementation which chainloads GRUB stage 1 from the active partition's boot sector. Given the small size of a boot sector (512 bytes), stage 1 can do little more than load the next stage of GRUB by loading a few disk sectors from a fixed location near the start of the disk (within its first 1024 cylinders).

Stage 1 can load stage 2 directly, but it is normally set up to load the stage 1.5., located in the first 30 KiB of hard disk immediately following the MBR and before the first partition. In case this space is not available (unusual partition table, special disk drivers, GPT or LVM disk) the install of stage 1.5 will fail. The stage 1.5 image contains file system drivers, enabling it to directly load stage 2 from any known location in the filesystem, for example from /boot/grub. Stage 2 will then load the default configuration file and any other modules needed.

Version 2 (GRUB 2)

GRUB 2 - MBR vs. GPT partitioning and boot sequence visualized (systems using BIOS firmware). GNU GRUB components.svg
GRUB 2 – MBR vs. GPT partitioning and boot sequence visualized (systems using BIOS firmware).

Startup on systems using BIOS firmware

  • See illustration in last image on the right. [10]
  • boot.img (stage 1) is written to the first 440 bytes of the Master Boot Record (MBR boot code in sector 0), or optionally in a partition boot sector (PBR). It addresses diskboot.img by a 64-bit LBA address. The actual sector number is written by grub-install. diskboot.img is the first sector of core.img with the sole purpose to load the rest of core.img identified by LBA sector numbers also written by grub-install.
    • On MBR partitioned disks, core.img (stage 1.5) is stored in the empty sectors (if available) between the MBR and the first partition. Recent operating systems suggest a 1 MiB gap here for alignment (2047 512-byte, or 255 4KiB, sectors). This gap used to be 62 sectors (31 KiB) as a reminder of the sector number limit of Cylinder-Head-Sector (C/H/S) addressing used by BIOS before 1996, therefore core.img is designed to be smaller than 32 KiB.
    • On GPT partitioned disks core.img is written to its own partition. It must be flagged "BIOS_grub", must not be formatted and can be as tiny as 1 MiB.
  • stage 2:core.img loads /boot/grub/i386-pc/normal.mod from the partition configured by grub-install. If the partition index has changed, GRUB will be unable to find the normal.mod, and presents the user with the GRUB Rescue prompt.
  • Depending on how GRUB2 was installed, the /boot/grub/ is either in the root partition of the Linux distribution, or in the separate /boot partition.
  • after normal.mod loaded:normal.mod parses /boot/grub/grub.cfg, optionally loads modules (eg. for graphical UI and file system support) and shows the menu.

Startup on systems using UEFI firmware

  • /efi/<distro>/grubx64.efi (for x64 UEFI systems) is installed as a file in the EFI System Partition, and booted by the firmware directly, without a boot.img in MBR sector 0. This file is like stage1 and stage1.5.
  • /boot/grub/ can be installed on the EFI System Partition or the separate /boot partition, among others.
  • For x64 UEFI systems, stage2 are the /boot/grub/x86_64-efi/normal.mod file and other /boot/grub/ files.

After startup

GRUB presents a menu where the user can choose from operating systems (OS) found by grub-install. GRUB can be configured to automatically load a specified OS after a user-defined timeout. If the timeout is set to zero seconds, pressing and holding ⇧ Shift while the computer is booting makes it possible to access the boot menu. [11]

In the operating system selection menu GRUB accepts a couple of commands:

  • By pressing e, it is possible to edit kernel parameters of the selected menu item before the operating system is started. The reason for doing this in GRUB (i.e. not editing the parameters in an already booted system) can be an emergency case: the system has failed to boot. Using the kernel parameters line it is possible, among other things, to specify a module to be disabled (blacklisted) for the kernel. This could be required if the specific kernel module is broken and thus prevents boot-up. For example, to blacklist the kernel module nvidia-current, one could append modprobe.blacklist=nvidia-current at the end of the kernel parameters.
  • By pressing c, the user enters the GRUB command line. The GRUB command line is not a regular Linux shell, like e.g. bash, and accepts only certain GRUB-specific commands, documented by various Linux distributions. [12]

Once boot options have been selected, GRUB loads the selected kernel into memory and passes control to the kernel. Alternatively, GRUB can pass control of the boot process to another boot loader, using chain loading . This is the method used to load operating systems that do not support the Multiboot Specification or are not supported directly by GRUB.

Identifying partitions (UUID workaround)

A computer can have multiple hard disks connected to it. These could be identified via their SATA port. Each time the computer POSTs, the hard disk connected to a specific motherboard port could be assigned the same identifier, for example hd0, hd1, …. But what if such consistency cannot be guaranteed? What if the constellation of connected hard disks changed from one start up to another? What if a hard disk will be connected to another computer?

By entering ls into either the GRUB rescue console (available after loading core.img ) or the GRUB console (available after loading normal.mod) a list of all available hard disks and partitions can be obtained. For example, ls (hd0,5)/) will show numbers that can be assigned to actual hard disks and partitions.

As it cannot be guaranteed that the "hd0"style numbering of hard disks via device numbers is consistent, GNU GRUB can use a Universally Unique Identifier (UUID) to identify partitions (actually file system instances).

The file systems ext2, ext3, ext4 and xfs use a UUID to uniquely identify an instance. The UUID is created when a partition is formatted. The UUID is part of the file system and written to the superblock. All operations other than formatting should leave the UUID unaltered. It is possible to change the UUID or duplicate it by using dd to clone an entire partition.

The file grub.cfg is used to configure GRUB. It contains commands to be executed during each start-up. Without an existing and valid grub.cfg, GRUB will present a prompt.

An absolute minimal grub.cfg might contain only the following two commands (cf. initial ramdisk):

linux (hd0,1)/kernel/vmlinuz-3.20.1-4 ro  # use the file name "vmlinuz-…" located in the directory /kernel on the first partition of the first hard disk as linux kernel image initrd (hd0,1)/boot/initrd.img-3.20.1-4   # use the file named "initrd.img–…" located in the directory /boot on the first partition of the first hard disk as initial ramdisk 

A fancier grub.cfg will describe a menu to be presented, use multiple colors, and may specify a background picture.

History

GRUB was initially developed by Erich Boleyn as part of work on booting the operating system GNU/Hurd, developed by the Free Software Foundation. [13] In 1999, Gordon Matzigkeit and Yoshinori K. Okuji made GRUB an official software package of the GNU Project and opened the development process to the public. [13] As of 2014, the majority of Linux distributions have adopted GNU GRUB 2, as well as other systems such as Sony's PlayStation 4. [14]

Development

GRUB version 0 (also known as "GRUB Legacy") is no longer under development and is being phased out. [15] The GNU GRUB developers have switched their focus to GRUB 2, [16] a complete rewrite with goals including making GNU GRUB cleaner, more robust, more portable and more powerful. GRUB 2 started under the name PUPA. PUPA was supported by the Information-technology Promotion Agency (IPA) in Japan. PUPA was integrated into GRUB 2 development around 2002, when GRUB version 0.9x was renamed GRUB Legacy.

Some of the goals of the GRUB 2 project include support for non-x86 platforms, internationalization and localization, non-ASCII characters, dynamic modules, memory management, a scripting mini-language, migrating platform specific (x86) code to platform specific modules, and an object-oriented framework. GNU GRUB version 2.00 was officially released on June 26, 2012. [17] [18]

Three of the most widely used Linux distributions use GRUB 2 as their mainstream boot loader. [19] [20] [21] Ubuntu adopted it as the default boot loader in its 9.10 version of October 2009. [22] Fedora followed suit with Fedora 16 released in November 2011. [23] OpenSUSE adopted GRUB 2 as the default boot loader with its 12.2 release of September 2012. [24] Solaris also adopted GRUB 2 on the x86 platform in the Solaris 11.1 release. [25] Buildroot also uses GNU GRUB for x86 and x86_64 targets.

In late 2015, the exploit of pressing backspace 28 times to bypass the login password was found and quickly fixed. [26] [27]

Variants

GNU GRUB is free software, so several variants have been created. Some notable ones, which have not been merged into GRUB mainline:

Utilities

GRUB configuration tools

StartUp-Manager, a program used to configure GRUB StartUp-Manager.png
StartUp-Manager, a program used to configure GRUB

The setup tools in use by various distributions often include modules to set up GRUB. For example, YaST2 on SUSE Linux and openSUSE distributions and Anaconda on Fedora/RHEL distributions. StartUp-Manager and GRUB Customizer are graphical configuration editors for Debian-based distributions. The development of StartUp-Manager stopped on 6 May 2011 after the lead developer cited personal reasons for not actively developing the program. [37] GRUB Customizer is also available for Arch-based distributions.

For GRUB 2 there are KDE Control Modules. [38] [39]

GRLDR ICE is a tiny tool for modifying the default configuration of grldr file for GRUB4DOS. [40]

Boot repair utilities

Boot-Repair is a simple graphical tool for recovering from frequent boot-related problems with GRUB and Microsoft Windows bootloader. This application is available under GNU GPL license. Boot-Repair can repair GRUB on multiple Linux distributions including, but not limited to, Debian, Ubuntu, Mint, Fedora, openSUSE, and Arch Linux.

GRUB Customizer GRUB customizer.png
GRUB Customizer

Installer for Windows

Grub2Win is a Windows open-source software package. It allows GNU GRUB to boot from a Windows directory. The setup program installs GNU GRUB version 2.12 to an NTFS partition. A Windows GUI application is then used to customize the GRUB boot menu, themes, UEFI boot order, scripts etc. All GNU GRUB scripts and commands are supported for both UEFI and legacy systems. Grub2Win can configure GRUB for multiboot of Windows, Ubuntu, openSuse, Fedora and many other Linux distributions. It is freely available under GNU GPL License at SourceForge.

Alternative boot managers

The strength of GRUB is the wide range of supported platforms, file systems, and operating systems, making it the default choice for distributions and embedded systems.

However, there are boot managers targeted at the end user that give more friendly user experience, graphical OS selector and simpler configuration:

Non-graphical alternatives:

How-Tos and troubleshooting

Distribution wikis have many solutions for common issues and custom setups that might help you:

Documentation

Introductory articles

Technicalities

See also

Notes

  1. GPL-3.0-or-later since 2007-07-21. [4]
  2. GPL-2.0-or-later from 1999 until 2007-07-02.

Related Research Articles

<span class="mw-page-title-main">Booting</span> Process of starting a computer

In computing, booting is the process of starting a computer as initiated via hardware such as a button on the computer or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system.

<span class="mw-page-title-main">Boot sector</span> Sector of a persistent data storage device

A boot sector is the sector of a persistent data storage device which contains machine code to be loaded into random-access memory (RAM) and then executed by a computer system's built-in firmware.

dyne:bolic Linux distribution

dyne:bolic GNU/Linux is a Live CD/DVD distribution based on the Linux kernel. It is shaped by the needs of media activists, artists and creators to be a practical tool with a focus on multimedia production, that delivers a large assortment of applications. It allows manipulation and broadcast of both sound and video with tools to record, edit, encode, and stream. In addition to multimedia specific programs, dyne:bolic also provides word processors and common desktop computing tools.

<span class="mw-page-title-main">Multi-booting</span> Act of installing multiple operating systems on a single computer

Multi-booting is the act of installing multiple operating systems on a single computer, and being able to choose which one to boot. The term dual-booting refers to the common configuration of specifically two operating systems. Multi-booting may require a custom boot loader.

<span class="mw-page-title-main">Bootloader</span> Software responsible for starting the Computer and Load other software to the CPU memory

A bootloader, also spelled as boot loader or called bootstrap loader, is a computer program that is responsible for booting a computer. If it also provides an interactive menu with multiple boot choices then it's often called a boot manager.

<span class="mw-page-title-main">UEFI</span> Operating system and firmware specification

Unified Extensible Firmware Interface is a specification that defines an architecture for the platform firmware used for booting a computer's hardware and its interface for interaction with the operating system. Examples of firmware that implement the specification are AMI Aptio, Phoenix SecureCore, TianoCore EDK II, InsydeH2O.

vmlinux Executable file containing the Linux kernel

vmlinux is a statically linked executable file that contains the Linux kernel in one of the object file formats supported by Linux, which includes Executable and Linkable Format (ELF) and Common Object File Format (COFF). The vmlinux file might be required for kernel debugging, symbol table generation or other operations, but must be made bootable before being used as an operating system kernel by adding a multiboot header, bootsector and setup routines.

<span class="mw-page-title-main">GUID Partition Table</span> Computer disk partitioning standard

The GUID Partition Table (GPT) is a standard for the layout of partition tables of a physical computer storage device, such as a hard disk drive or solid-state drive, using universally unique identifiers (UUIDs), which are also known as globally unique identifiers (GUIDs). Forming a part of the Unified Extensible Firmware Interface (UEFI) standard, it is nevertheless also used for some BIOSs, because of the limitations of master boot record (MBR) partition tables, which use 32 bits for logical block addressing (LBA) of traditional 512-byte disk sectors.

The Multiboot specification is an open standard describing how a boot loader can load an x86 operating system kernel. The specification allows any compliant boot-loader implementation to boot any compliant operating-system kernel. Thus, it allows different operating systems and boot loaders to work together and interoperate, without the need for operating system–specific boot loaders. As a result, it also allows easier coexistence of different operating systems on a single computer, which is also known as multi-booting.

loadlin is a Linux boot loader that runs under 16-bit real-mode DOS. It allows the Linux system to load and replace the running DOS without altering existing DOS system files.

<span class="mw-page-title-main">EFI system partition</span> Partition used by Unified Extensible Firmware Interface

The EFIsystem partition or ESP is a partition on a data storage device that is used by computers that have the Unified Extensible Firmware Interface (UEFI). When a computer is booted, UEFI firmware loads files stored on the ESP to start operating systems and various utilities.

<span class="mw-page-title-main">Windows Boot Manager</span> Boot process used in modern Windows NT-based products

The Windows Boot Manager (BOOTMGR) is the bootloader provided by Microsoft for Windows NT versions starting with Windows Vista and Windows Server 2008. It is the first program launched by the BIOS or UEFI of the computer and is responsible for loading the rest of Windows. It replaced the NTLDR present in older versions of Windows.

<span class="mw-page-title-main">Wubi (software)</span> Ubuntu Linux installer for Windows

Wubi is a free software Ubuntu installer, that was the official Windows-based software, from 2008 until 2013, to install Ubuntu from within Windows, to a single file within an existing Windows partition.

The following tables compare general and technical information for a number of available bootloaders.

The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process. When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the power-on self-test, invoking the reset vector to start a program at a known address in flash/ROM, then load the bootloader into RAM for later execution. In IBM PC–compatible personal computers (PCs), this firmware/program is either a BIOS or a UEFI monitor, and is stored in the mainboard. In embedded Linux systems, this firmware/program is called boot ROM. After being loaded into RAM, the bootloader will execute to load the second-stage bootloader. The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image. The second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc. Finally, the first user-space process starts, and other high-level system initializations are performed.

The BIOS boot partition is a partition on a data storage device that GNU GRUB uses on legacy BIOS-based personal computers in order to boot an operating system, when the actual boot device contains a GUID Partition Table (GPT). Such a layout is sometimes referred to as BIOS/GPT boot.

<span class="mw-page-title-main">EasyBCD</span> Software for Microsoft Windows

EasyBCD is a program developed by NeoSmart Technologies to configure and tweak the Boot Configuration Data (BCD), a boot database first introduced in Windows Vista and used in all subsequent Windows releases. EasyBCD can be used to set up multi-boot environments for computers on which some versions of Windows, Linux, BSD and Mac OS X can be simultaneously installed; EasyBCD can also be used for adding entries to bootable tools and utilities, as well as modifying and controlling the behavior of the Windows boot menu. EasyBCD 2.3 introduced additional support for creating and managing entries for UEFI-based Windows entries in the boot menu. As of June 20, 2011 with the release of EasyBCD 2.1, it is no longer free for use in commercial environments which require the purchase of a paid license, however it remains free for home and non-profit use without limitations.

A master boot record (MBR) is a type of boot sector in the first block of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.

In Linux, and other Unix-like operating systems, the /boot/ directory holds files used in booting the operating system. The usage is standardized in the Filesystem Hierarchy Standard.

<span class="mw-page-title-main">Ventoy</span> Live USB bootloader

Ventoy is a free and open-source utility used for creating bootable usb media storage device with files such as .iso, .wim, .img, .vhd(x), and .efi. Once Ventoy is installed onto a USB drive, there is no need to reformat the disk to update it with new installation files; it is enough to copy the .iso, .wim, .img, .vhd(x), or .efi file(s) to the USB drive and boot from them directly. Ventoy will present the user with a boot menu to select one of these files. Currently, the project has been on hold in the absence of the main developer longpanda since June, 2024. Some users expressed fear of discontinuation of the project on the official forum, with no affirmation from the developer.

References

  1. Daniel Kiper (December 20, 2023). "GRUB 2.12 released" . Retrieved December 20, 2023.
  2. "GRUB 2.12 release candidate 1". July 10, 2023.
  3. "Ohloh Analysis Summary – GNU GRUB". Ohloh. Archived from the original on February 4, 2009. Retrieved May 12, 2010.
  4. "Migrate to GNU General Public License Version 3". July 21, 2007. Archived from the original on October 27, 2021. Retrieved October 27, 2021.
  5. "GNU GRUB license". Archived from the original on September 11, 2013.
  6. EnterpriseLinux.com Definitions Archived December 3, 2010, at the Wayback Machine Definition of GRand Unified Bootloader
  7. Smith, Ryan (December 18, 2009). "Western Digital's Advanced Format: The 4K Sector Transition Begins". AnandTech. Archived from the original on March 12, 2012. Retrieved October 10, 2013.
  8. "mbldr (Master Boot LoaDeR)". mbldr.sourceforge.net. 2009. Archived from the original on March 16, 2013. Retrieved October 10, 2013.
  9. 1 2 "Booting and Boot Managers". SUSE. Archived from the original on September 17, 2013. Retrieved October 10, 2013.
  10. "GNU GRUB Manual 2.04". www.gnu.org. Archived from the original on April 3, 2018. Retrieved November 10, 2020.
  11. Hoffman, Chris (September 22, 2014). "How to Configure the GRUB2 Boot Loader's Settings". HowToGeek.com. Archived from the original on April 28, 2015. Retrieved April 25, 2015.
  12. "GNU GRUB documentation". Archived from the original on April 18, 2014. Retrieved April 16, 2014.
  13. 1 2 GRUB Manual – 1.2 Grub History Archived April 16, 2014, at the Wayback Machine . Gnu.org (2012-06-23). Retrieved on 2012-12-01.
  14. "PS4 runs Orbis OS, a modified version of FreeBSD that's similar to Linux". extremetech.com. June 24, 2013. Archived from the original on November 18, 2020. Retrieved October 23, 2013.
  15. GNU GRUB – GRUB Legacy Archived April 20, 2014, at the Wayback Machine . Gnu.org. Retrieved on 2012-12-01.
  16. "GNU GRUB – GRUB 2". Archived from the original on June 7, 2008. Retrieved April 18, 2014.{{cite web}}: CS1 maint: bot: original URL status unknown (link).
  17. Serbinenko, Vladimir (June 28, 2012). "GRUB 2.00 released". grub-devel (Mailing list). Archived from the original on January 13, 2013. Retrieved December 1, 2012.
  18. Larabel, Michael. "GRUB 2.00 Boot-Loader Officially Released". Phoronix.com. Archived from the original on September 13, 2016. Retrieved June 28, 2012.
  19. Haddon, Tom (January 26, 2012). "An Introduction to Ubuntu". WebJunction. Archived from the original on October 28, 2012. Retrieved September 21, 2012.
  20. Janssen, Cory. "What is Red Hat Enterprise Linux (RHEL)?". Technopedia. Archived from the original on October 3, 2012. Retrieved September 21, 2012.
  21. Varghese, Sam (September 20, 2012). "SUSE chief lists progress since privatisation". Archived from the original on September 22, 2012. Retrieved September 21, 2012.
  22. "9.10 Karmic GRUB version". Distrowatch.com. Archived from the original on May 9, 2012. Retrieved July 8, 2012.
  23. GRUB 2 Archived August 5, 2012, at the Wayback Machine . FedoraProject. Retrieved on 2012-12-01.
  24. openSUSE:Upcoming features – openSUSE Archived September 20, 2012, at the Wayback Machine . En.opensuse.org. Retrieved on 2012-12-01.
  25. Solaris 11.1 Archived June 19, 2018, at the Wayback Machine . Oracle Retrieved 2015-03-19.
  26. Khandelwal, Swati (December 16, 2015). "You can Hack into a Linux Computer just by pressing 'Backspace' 28 times". thehackernews.com. Archived from the original on April 30, 2017. Retrieved March 13, 2017.
  27. Marco and, Hector; Ripoll, Ismael (December 2015). "Back to 28: Grub2 Authentication 0-Day". Archived from the original on May 17, 2017. Retrieved March 13, 2017.
  28. x86: Modifying Boot Behavior by Editing the GRUB Menu at Boot Time Archived July 19, 2011, at the Wayback Machine , Modifying Solaris Boot Behavior on x86 Based Systems (Task Map) – System Administration Guide: Basic Administration
  29. x86: Supported GRUB Implementations Archived October 21, 2009, at the Wayback Machine , (System Administration Guide: Basic Administration) – Sun Microsystems
  30. Peng, Tao. "Grub4ext4". Archived from the original on December 31, 2016. Retrieved June 13, 2017.
  31. 2.3 Why does Syllable have its own version of GRUB? Archived January 7, 2011, at the Wayback Machine , Syllable Documentation
  32. "TrustedGRUB project". sourceforge.net. June 5, 2013. Archived from the original on November 29, 2014. Retrieved November 18, 2014.
  33. BIOS Implementation Test Suite Archived October 19, 2016, at the Wayback Machine , Official BITS website
  34. "grub4dos". Google Site. Archived from the original on April 7, 2019. Retrieved April 7, 2019.
  35. "GRUB for DOS Introduction". grub4dos.sourceforge.net. 2007. Archived from the original on April 7, 2019. Retrieved April 7, 2019.
  36. grub4dos on GitHub
  37. "StartUp-Manager is dead : StartUp-Manager". launchpad.net. May 6, 2011. Archived from the original on August 1, 2020. Retrieved April 9, 2017.
  38. GRUB2 Bootloader Editor Archived September 7, 2015, at the Wayback Machine . Kde-apps.org (2012-06-18). Retrieved on 2012-12-01.
  39. "Grub2 KCM". KDE-Apps.org. Archived from the original on September 6, 2015. Retrieved January 27, 2011.
  40. "Grub4dos tutorial". Narod.ru. Archived from the original on May 3, 2015. Retrieved April 25, 2015.