"GRUB" well!! so you want know about grub in computing,
WHAT IS GRUB??
there is gnu grub, which which stands for GNU GRand Unified Bootloader is a bootlader package from the GNU Project. GRUB is 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 kernels configuration available on a particular operating system's partitions.
GNU GRUB was developed from a package called the Grand Unified Bootloader. It is predominantly used for Unix-like systems. The GNU operating system uses GNU GRUB as its boot loader, as do most Linux distributions. The Solaris operating system has used GRUB as its boot loader on x86 systems, starting with the Solaris 10 1/06 release.
GRUB is highly portable. It supports multiple executable formats and is geometry-translation independent. It supports all commonly used Unix file systems, the Windows file systems FAT and NTFS, and logical block addressing (LBA). GRUB allows users to view the contents of files on any supported file system.
GRUB can download operating system boot images from network, thus supporting diskless systems. It also supports automatic decompression of the boot images before booting them. GRUB supports operating systems that do not multi-boot, by using chain loading. It uses the same two or three lines of command sequences to boot any DOS, Windows, Linux, BSD or Solaris system, making it very easy to work with it. The chain loaders for the supported Unix-like OSes are built into GRUB.
GRUB can be used with a variety of user interfaces. Most Linux distributions take advantage of GRUB's support for a graphical interface to provide a customized boot menu with a background image. A modification of GRUB's text interface can use a serial link so that a remote terminal can have access to the boot loader.
GRUB uses a scrollable screen for operating system boot selection. This means 150 or more boot choices can be easily controlled by GRUB by adding them to the
The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes. 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 totally sufficient for very simple boot loaders, 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 thus split into pieces, where the smallest piece fits into and resides within the MBR, while larger piece(s) are stored in other locations (for example, into empty sectors between the MBR and the first partition) and invoked by the boot loader's MBR code.
Operating system kernel images are in most cases 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 content of those files, so it can be read from the hard disk, loaded into the RAM and executed.
One of the possible approaches for boot loaders is to load the kernel images by directly accessing hard disk sectors occupied by the actual kernel image, without understanding the underlying file system. Usually, 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, thus providing information to the boot loader about where to find the kernel image's underlying sectors. 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.
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 file system 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 the kernel images are added or moved around. 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. As a result, the possibility for things to go wrong during various system updates is significantly reduced. As a downside, such boot loaders have increased internal complexity and even bigger footprints.[8]
GNU GRUB uses the second approach, by understanding the underlying file systems. The boot loader itself is split into multiple stages, allowing for itself to fit within the MBR boot scheme.
Two major versions of GRUB are in common use. GRUB version 2, called GRUB 2, was written from scratch and intended to replace its predecessor GRUB version 1, and it is now used by a majority of Linux distributions. GRUB version 1, called GRUB legacy, is only prevalent in older releases of Linux distributions, among which some are still in use and supported, for example in Ubuntu 10.04 or CentOS 5.
Stage 1 can load the stage 2 directly, but it is normally set up to load the stage 1.5. GRUB stage 1.5 is located in the first 30 KB of hard disk immediately following the MBR and before the first partition. If 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. This enables the stage 1.5 to directly load stage 2 from any known location in the filesystem, for example from
In the operating system selection menu GRUB accepts a couple of commands:
If the usage of dm-crypt is intended, the contents of
Some of the goals of the GRUB 2 project include support for non-x86 platforms, internationalization/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.
Three of the most widely used Linux distributions use GRUB 2 as their mainstream boot loader:
Ubuntu adopted GRUB 2 as the default boot loader in its 9.10 version of October 2009.
Fedora has been using GRUB 2 as its default boot loader since Fedora 16 released in November 2011.
openSUSE adopted GRUB 2 as the default boot loader with its 12.2 release of September 2012.
GNU GRUB version 2.00 was officially released on June 26, 2012.
StartUp-Manager, a program used to configure GRUB
GRUB Customizer, another tool to configure GRUB
The setup tools in use by various distributions often include modules to
set up GRUB: for example, YaST2 on SUSE/openSUSE distributions and
Anaconda on Fedora/RHEL distributions. StartUp-Manager and GRUB
Customizer are graphical configuration editor for Debian based
distributions of GRUB.
For GRUB 2 there are KDE Control Modules. GRLDR ICE is a tiny tool for modifying the default configuration of grldr file for GRUB4DOS.
GRUB Utilities is a collection of multi-platform utilities for GRUB Legacy, GRUB 2 and GRUB for DOS.
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 and will be included in the future versions of Ubuntu.
WHAT IS GRUB??
there is gnu grub, which which stands for GNU GRand Unified Bootloader is a bootlader package from the GNU Project. GRUB is 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 kernels configuration available on a particular operating system's partitions.
GNU GRUB was developed from a package called the Grand Unified Bootloader. It is predominantly used for Unix-like systems. The GNU operating system uses GNU GRUB as its boot loader, as do most Linux distributions. The Solaris operating system has used GRUB as its boot loader on x86 systems, starting with the Solaris 10 1/06 release.
Features
Users can dynamically configure the GRUB subsystem. GRUB loads its configuration at startup, allowing boot-time changes, such as selecting different kernels or initial RAM disks. To this end, GRUB provides a simple, bash-like, command line interface, which lets users write new boot sequences on the fly, in addition to the normal menu lists.GRUB is highly portable. It supports multiple executable formats and is geometry-translation independent. It supports all commonly used Unix file systems, the Windows file systems FAT and NTFS, and logical block addressing (LBA). GRUB allows users to view the contents of files on any supported file system.
GRUB can download operating system boot images from network, thus supporting diskless systems. It also supports automatic decompression of the boot images before booting them. GRUB supports operating systems that do not multi-boot, by using chain loading. It uses the same two or three lines of command sequences to boot any DOS, Windows, Linux, BSD or Solaris system, making it very easy to work with it. The chain loaders for the supported Unix-like OSes are built into GRUB.
GRUB can be used with a variety of user interfaces. Most Linux distributions take advantage of GRUB's support for a graphical interface to provide a customized boot menu with a background image. A modification of GRUB's text interface can use a serial link so that a remote terminal can have access to the boot loader.
GRUB uses a scrollable screen for operating system boot selection. This means 150 or more boot choices can be easily controlled by GRUB by adding them to the
grub.cfg configuration file. The arrow
keys are used to select which operating system to boot. In addition to
the normal menu interface, GRUB also provides a bash-like
terminal command-prompt that provides a rich set of commands to allow a
user to view or alter any part of the boot process. With these tools
one can, without prior knowledge of what is installed on a computer, use
GRUB from an external device such as a floppy disk, USB device or a CD-ROM to boot up an installed operating system.Operation
Booting
See also: UEFI disk device compatibility
When a computer is turned on, the computer's BIOS finds the configured
primary bootable device (usually the computer's hard disk) and loads and
executes the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk, with zero as its physical offset
(sectors counting starts at zero). For a long time, the size of a
sector has been 512 bytes, but since 2009 there are hard disks available
with a sector size of 4096 bytes, called Advanced Format disks. As of October 2013, such hard disks are still accessed in 512-byte sectors, by utilizing the 512e emulation.[6]The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes. 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 totally sufficient for very simple boot loaders, 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 thus split into pieces, where the smallest piece fits into and resides within the MBR, while larger piece(s) are stored in other locations (for example, into empty sectors between the MBR and the first partition) and invoked by the boot loader's MBR code.
Operating system kernel images are in most cases 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 content of those files, so it can be read from the hard disk, loaded into the RAM and executed.
One of the possible approaches for boot loaders is to load the kernel images by directly accessing hard disk sectors occupied by the actual kernel image, without understanding the underlying file system. Usually, 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, thus providing information to the boot loader about where to find the kernel image's underlying sectors. 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.
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 file system 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 the kernel images are added or moved around. 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. As a result, the possibility for things to go wrong during various system updates is significantly reduced. As a downside, such boot loaders have increased internal complexity and even bigger footprints.[8]
GNU GRUB uses the second approach, by understanding the underlying file systems. The boot loader itself is split into multiple stages, allowing for itself to fit within the MBR boot scheme.
Two major versions of GRUB are in common use. GRUB version 2, called GRUB 2, was written from scratch and intended to replace its predecessor GRUB version 1, and it is now used by a majority of Linux distributions. GRUB version 1, called GRUB legacy, is only prevalent in older releases of Linux distributions, among which some are still in use and supported, for example in Ubuntu 10.04 or CentOS 5.
GRUB version 1 (GRUB legacy)
The master boot record (MBR) usually contains GRUB stage 1, but can contain another bootloader which can chain boot GRUB stage 1 from another boot sector such as a partition's volume boot record. 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 the stage 2 directly, but it is normally set up to load the stage 1.5. GRUB stage 1.5 is located in the first 30 KB of hard disk immediately following the MBR and before the first partition. If 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. This enables the stage 1.5 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.GRUB version 2 (GRUB)
boot.img has the exact size of 446 bytes and is written to the MBR (sector 0). core.img
is written to the empty sectors between the MBR and the first
partition, if available (for legacy reasons the first partition starts
at sector 63 instead of sector 1, but this is not mandatory). The /boot/grub directory can be located on an distinct partition, or on the root partition.- Stage 1:
boot.imgis stored in the master boot record (MBR), or optionally in any of the volume boot records (VBRs), and addresses the next stage by an LBA48 address (the 1024 cylinder boundary of GRUB legacy is omitted); at installation time it is configured to load the first sector ofcore.img. - Stage 1.5:
core.imgis by default written to the sectors between the MBR and the first partition, when these sectors are free and available. For legacy reasons, the first partition of a hard drive does not begin at sector 1 (counting begins with 0) but at sector 63, leaving a gap of 62 sectors of empty space. That space is not part of any partition or file system, and therefore not prone to any problems related with it. Once executed,core.imgwill load its configuration file and any other modules needed, particularly file system drivers; at installation time, it is generated fromdiskboot.imgand configured to load the stage 2 by its file path. - Stage 2: files belonging to the stage 2 are all being held in the
/boot/grubdirectory, which is a subdirectory of the/bootdirectory specified by the Filesystem Hierarchy Standard (FHS).
In the operating system selection menu GRUB accepts a couple of commands:
- By pressing e, it is possible to edit parameters for the selected operating system before the operating system is started.
Typically, this is used to change kernel parameters for a Linux system.
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, appendmodprobe.blacklist=nvidia-currentat 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.
If the usage of dm-crypt is intended, the contents of
/boot, i.e. /boot/grub, the Linux kernel and initramfs respectively initrd
need to be on a distinct non-encrypted partition, because the logic to
handle encrypted partitions resides inside the Linux kernel.Installation
The GNU GRUB (version 2) software package contains several executable files:- is a script file that will execute following tasks:
- create the directory
/boot/grubif it does not exist - generate the file
core.imgor respectivelygrub*.efi - write
boot.imgto either the MBR or a volume boot record (VBR), as specified in a command-line option - write
core.imginto space between the MBR and first partition or respectively copygrub*.efito the EFI System partition
- is a utility used to generate a new
grub.cfgfile - is a stub used for running
grub-mkconfig -o /boot/grub/grub.cfg
Adoption
The majority of Linux distributions adopted GNU GRUB 2. Another notable example is the Sony's PlayStation 4, which also uses GNU GRUB.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. 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.Development
GRUB version 1 (also known as "GRUB Legacy") is no longer under development and is being phased out The GNU GRUB developers have switched their focus to GRUB 2 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/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.
Three of the most widely used Linux distributions use GRUB 2 as their mainstream boot loader:
Ubuntu adopted GRUB 2 as the default boot loader in its 9.10 version of October 2009.
Fedora has been using GRUB 2 as its default boot loader since Fedora 16 released in November 2011.
openSUSE adopted GRUB 2 as the default boot loader with its 12.2 release of September 2012.
GNU GRUB version 2.00 was officially released on June 26, 2012.
Variants
GNU GRUB is free and open-source software, so several variants have been created. Some notables one, which have not been merged into GRUB mainline:- OpenSolaris includes a modified GRUB Legacy that supports BSD disklabels, automatic 64-bit kernel selection, and booting from ZFS (with compression and multiple boot environments).
- The Syllable project made a modified version of GRUB to load the system from its AtheOS File System.
Utilities
GRUB configuration tools
For GRUB 2 there are KDE Control Modules. GRLDR ICE is a tiny tool for modifying the default configuration of grldr file for GRUB4DOS.
Other utilities
GRUB Utilities is a collection of multi-platform utilities for GRUB Legacy, GRUB 2 and GRUB for DOS.
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 and will be included in the future versions of Ubuntu.
No comments:
Post a Comment