Re­solv­ing Boot Loader Is­sues

Boot loader is­sues of­ten plague com­puter sys­tems. This ar­ti­cle de­mys­ti­fies the boot­ing process, both for BIOS based sys­tems as well as UEFI sys­tems.

OpenSource For You - - Contents -

ABa­sic In­put Out­put Sys­tem (BIOS) pow­ered sys­tem goes through a num­ber of steps from when it is pow­ered up to when it runs a Red Hat En­ter­prise Linux (RHEL) sys­tem. The fol­low­ing list of steps gives a high-level overview of what ex­actly takes place. This list also ap­plies to vir­tual ma­chines that em­u­late a tra­di­tional BIOS sys­tem. The list as­sumes that the GRUB2 boot loader is be­ing used. For dif­fer­ent boot load­ers, the list will dif­fer. 1) The BIOS firmware is started and per­forms a ‘power on

self-test’ (POST).

2) The BIOS scans for pos­si­ble boot de­vices, and or­ders

them ac­cord­ing to a user-set pref­er­ence.

3) The boot de­vices are scanned for boot firmware (such as a PXE ROM on net­work cards), a Master Boot Record (MBR), or a par­ti­tion marked as bootable. If found, the BIOS ex­e­cutes them.

4) The first­stage boot loader stored in the MBR loads the Stage 1.5 (driv­ers) and Stage 2 boot load­ers from the disk, and ex­e­cutes them.

5) The boot loader loads a con­fig­u­ra­tion file from the disk. In the case of GRUB2, this will be /boot/grub2/grub.cfg. The file is shown in Fig­ure 1. This file is auto gen­er­ated and should not nor­mally be edited man­u­ally.

6) The con­fig­u­ra­tion file is parsed and, based on its con­tents,

a boot en­try is se­lected au­to­mat­i­cally by the user.

7) The ker­nel and ini­tial RAM disk ref­er­enced in the boot en­try are loaded from the disk, and con­trol is handed over to the ker­nel.

8) The ker­nel starts and ini­tialises hard­ware us­ing the driv­ers found in the ini­tial RAM disk. A sim­ple init sys­tem is also started from the RAM disk.

9) The scripts in the ini­tial RAM disk mount the root file sys­tem of the tar­get sys­tem; they then switch the root to the newly mounted file sys­tem and hand over con­trol to /sbin/ init on the tar­get root file sys­tem.

10) The init sys­tem mounts file sys­tems and starts ser­vices

ac­cord­ing to its con­fig­u­ra­tion.

GRUB2

The boot loader used on RHEL is GRUB2, the sec­ond ma­jor ver­sion of the GRand Uni­fied Boot­loader. GRUB2 stores its files on a BIOS sys­tem in a num­ber of dif­fer­ent lo­ca­tions, as listed be­low.

/boot/

The ker­nel and ini­tial RAM disks are stored here. Sub­di­rec­to­ries con­tain other files.

/boot/grub2/ This con­tains the con­fig­u­ra­tion files, ex­ten­sion mod­ules

and themes. /boot/grub2/grub.cfg

This has the main GRUB2 con­fig­u­ra­tion file. This file is auto gen­er­ated, and should nor­mally not be edited man­u­ally. As a con­ve­nience, /etc/grub2.cfg is a sym­bolic link to this file.

/etc/grub.d/

This direc­tory con­tains a helper script to gen­er­ate a main GRUB2 con­fig­u­ra­tion file.

/etc/de­faults/grub

This file con­tains vari­ables used in the gen­er­a­tion of the main GRUB2 con­fig­u­ra­tion file, as shown in Fig­ure 2.

/boot/grub2/grubenv

This con­tains a file of ex­actly 1KiB, which is used as stor­age for vari­ables, such as a de­fault or ‘saved’ boot en­try.

The grub2-editenv tool can be used to read and mod­ify these set­tings.

The Master Boot Record (MBR)

In or­der to boot GRUB2 from the disk on a BIOS sys­tem, there are two op­tions—store the first part of the GRUB2 boot loader in the Master Boot Record (MBR) of a disk, or store it in the first sec­tor of a par­ti­tion that is marked as ‘bootable’.

The prob­lem with the MBR

There is a ma­jor con­straint with us­ing the MBR. A typ­i­cal MBR is only 512 bytes in size, and part of that space is used for the par­ti­tion ta­ble of that disk, leav­ing only 446 bytes for the boot loader.

To work around this is­sue, GRUB2 can use the ‘boot track’, ‘MBR gap’, or ‘em­bed­ding area’ on the disk to store the ex­tra mod­ules and files it needs. This is the space be­tween the MBR and the first par­ti­tion on the disk. In or­der to work re­li­ably, there needs to be at least 31KiB of space avail­able this way (63 sec­tors on a 512-byte sec­tor disk). If a disk has been par­ti­tioned by Ana­conda, the first par­ti­tion will usu­ally start at sec­tor 2048, leav­ing roughly 1MiB of space for the em­bed­ding area, which is am­ple room for GRUB2.

Note: The ibi (or bi­nary pre­fix) units KiB, MiB, GiB are based on 2^10(1024) whereas stan­dard dec­i­mal units (KB, MB, GB) are based on 10^3(1000). In this ar­ti­cle, we have used the units KiB, MiB and TiB.

1KB= 1000 bytes 1KiB=1024 bytes

1MB=1000KB 1MiB=1024KB

1GB=1000MB 1GiB=1024MB

1TB=1000GB 1TiB= 024GB

Con­fig­ur­ing GRUB2

Un­der nor­mal cir­cum­stances, an ad­min­is­tra­tor should not have to man­u­ally con­fig­ure the GRUB2 boot loader.

When a new ker­nel is in­stalled, it will be added to the con­fig­u­ra­tion au­to­mat­i­cally and when a ker­nel is re­moved, the cor­re­spond­ing en­try in the boot loader menu is re­moved au­to­mat­i­cally as well.

An ad­min­is­tra­tor might want to tweak some pa­ram­e­ters that are passed into the ker­nel at startup by GRUB2. The best way to do this is by edit­ing /etc/de­faults/grub and then forc­ing a re­cre­ation of the main GRUB2 con­fig­u­ra­tion file.

The set­tings in /etc/de­faults/grub that are of in­ter­est are listed here.

GRUB_TIMEOUT

This is the num­ber of sec­onds the GRUB2 menu is dis­played be­fore the de­fault en­try is booted au­to­mat­i­cally.

GRUB_DEFAULT

This is the num­ber of the de­fault en­try that should be started when­ever a user does not se­lect an­other en­try, which is

when GRUB2 starts count­ing at 0. If this vari­able is set to the string saved, the en­try will be taken from /boot/grub2/ grubenv.

GRUB_CMDLINE_LINUX

This vari­able con­tains a list of ex­tra ker­nel com­man­d­line op­tions that should be added to ev­ery sin­gle Linux ker­nel. Typ­i­cal uses in­clude ‘rhgb quiet’ for a graph­i­cal boot, ‘con­sole=xxxxxx’ for se­lect­ing a ker­nel con­sole de­vice, and ‘crashk­er­nel=xxxx’ for con­fig­ur­ing au­to­matic ker­nel crash dump­ing.

After up­dat­ing the file /etc/de­fault/grub, changes can be ap­plied by run­ning the com­mand grub2­mk­con­fig –o /boot/grub2/grub.cfg. This will gen­er­ate a fresh con­fig­u­ra­tion file us­ing the scripts in /etc/grub.d and the set­tings in /etc/de­faults/grub. If no out­put file is spec­i­fied with the –o op­tion, a con­fig­u­ra­tion file will be writ­ten to the stan­dard out­put.

Re­in­stalling GRUB2 into the MBR

If, for some rea­son, the MBR, or the em­bed­ding area, has be­come dam­aged, an ad­min­is­tra­tor will have to re­in­stall GRUB2 into the MBR. Since this im­plies that the sys­tem is cur­rently un­bootable, this is typ­i­cally done from some live CD or from within the res­cue en­vi­ron­ment pro­vided by the Ana­conda in­staller.

The fol­low­ing pro­ce­dure ex­plains how to boot into a res­cue en­vi­ron­ment and re­in­stall GRUB2 into the

MBR from there. If an ad­min­is­tra­tor is still logged into a run­ning sys­tem, the pro­ce­dure can be short­ened to just the grub-in­stall com­mand.

1. Boot from an in­stal­la­tion source; this can be a DVD im­age, a net­boot CD, or from PXE pro­vid­ing a RHEL in­stal­la­tion tree.

2. In the boot menu for the in­stal­la­tion me­dia, se­lect the ‘Res­cue an in­stalled sys­tem’ op­tion, or edit the ker­nel com­mand line to in­clude the word ‘res­cue’.

3. When prompted about mount­ing the disks for the tar­get sys­tem to be res­cued, se­lect Op­tion 1 (con­tinue). This will mount the sys­tem un­der /mnt/sysim­age.

4. Press En­ter to ob­tain a shell when prompted.

This shell will live in­side the in­stal­la­tion/res­cue en­vi­ron­ment, with the tar­get sys­tem mounted un­der /mnt/sysim­age.

This shell has a num­ber of tools avail­able for res­cu­ing a sys­tem, such as all com­mon file sys­tems, disks, LVMs, and net­work­ing tools. The var­i­ous bin di­rec­to­ries of the tar­get sys­tem are added to the de­fault ex­e­cutable search path (${PATH}) as well.

5. ch­root into the /mnt/sysim­age direc­tory, us­ing the fol­low­ing com­mand:

# ch­root /mnt/sysim­age 6. Ver­ify that /boot is mounted, us­ing the com­mand given be­low. De­pend­ing on the type of in­stal­la­tion, /boot can be on a sep­a­rate par­ti­tion, or it can be part of the root file sys­tem.

# ls –l /boot.

7. Use the com­mand grub2­in­stall to re­write the boot loader sec­tions of the MBR and the em­bed­ding area. This com­mand will need the block de­vice that rep­re­sents the main disk as an ar­gu­ment. If un­sure about the name of the main disk, use ls­blk and blkid to iden­tify it.

# grub2-in­stall /dev/vda

8. Re­boot the sys­tem. This can be done by ex­it­ing both the ch­root shell and the res­cue shell.

9. Wait for the sys­tem to re­boot twice. After the first re­boot, the sys­tem will per­form an ex­ten­sive SELinux file sys­tem re­la­bel, after which it will re­boot again au­to­mat­i­cally to en­sure that proper con­texts are be­ing used. This re­la­bel is trig­gered au­to­mat­i­cally by the Ana­conda res­cue sys­tem cre­at­ing the /. au­tore­la­bel.

Fig­ure 1: The con­fig­u­ra­tion file of boot loader

Fig­ure 2: Vari­ables used in the gen­er­a­tion of the main GRUB2 con­fig­u­ra­tion file

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.