System Administration
Showing results for 
Search instead for 
Did you mean: 

How to identify the bootdisk on RHEL

Occasional Contributor

How to identify the bootdisk on RHEL

On hpux we use "echo "boot_string/S" | adb -k /stand/vmunix /dev/kmem" to find from which disk it booted from whereas in RHEL 4 how to find from which disk it boot where the boot disk is mirrored usring software raid
Steven E. Protter
Exalted Contributor

Re: How to identify the bootdisk on RHEL


fdisk -l

There will be an asterisk marking the boot disk.

[root@prottervm ~]# fdisk -l

Disk /dev/hda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 1044 8281507+ 8e Linux LVM

Steven E Protter
Owner of ISN Corporation
Honored Contributor

Re: How to identify the bootdisk on RHEL

SEP suggested "fdisk -l", but if a software RAID has been set up correctly, you will find either two disks with one bootable partition on each - or none.

Why none? If the bootloader (e.g. GRUB or LILO) has been installed into the MBR of the disk, the "bootable" flag in the partition table is irrelevant: most Linux bootloaders completely ignore it. The "bootable" flag is significant only if MBR contains standard PC boot code (which may be used to start a Linux bootloader embedded into the beginning of a Linux partition, to make things even more confusing).

Warning: a very technical explanation follows...

At boot time, PC hardware relies on BIOS to select the boot disk. The method for this selection is not well-defined: the only de-facto standard is that the BIOS will present the "bootable" disk as "the first disk found by the BIOS", also known as BIOS hard disk number 0x80. In old DOS/pre-Windows2k terminology, this is also known as "drive C:".

The BIOS loads the MBR from disk 0x80, and if it's valid, executes it. A standard PC MBR will then read the partition table on the same disk, find a primary partition with the "bootable" flag, read the first block from that partition, and execute it. This will contain the first part of an OS-specific bootloader, which will then take control of the system. In the case of RHEL, this is usually GRUB.

If GRUB was installed into MBR, it takes control as soon as MBR is executed, and the "first partition marked as bootable" step is completely omitted.

GRUB will then use the BIOS routines to read other parts of itself into memory, present a boot menu, load the kernel and initrd files, and finally give control to the Linux kernel.

At that point, the Linux kernel will transition the machine out of the legacy DOS-compatible "real mode" and into "protected mode" which is used by most modern PC operating systems. This transition will completely change the system's memory map, so any hardware information that the BIOS might provide will be lost, unless the kernel moves it to where it can be found after the transition.

After the transition, the Linux kernel starts the hardware detection essentially from scratch: all it has is the drivers in the initrd file, and the scraps of information it got from the BIOS.

Only relatively recently a standard was created to allow BIOS to tell the OS which disk was used to boot the system. This standard is known as EDD. This standard is still optional in PC hardware, so EDD information may or may not exist in your system.

Look into directory /sys/firmware/edd: if your system's BIOS has supplied any EDD information to the OS, there will be sub-directories named like "int13_dev80", "int13_dev81" etc. Each of these sub-directories will contain information about one of the disks detected by the BIOS. Of these, "int13_dev80" will be the disk that was used to load the bootloader.

All files in the directory can be viewed as text. The existence and content of these files depend on your BIOS: some BIOSes supply more information than others.

If /sys/firmware/edd/int13_dev80/host_bus exists, it will identify the disk controller and channel used to boot the system. With IDE controllers, channel 0 is the master disk. The controller is usually identified by its PCI ID: refer to "lspci" listing to get the name of the controller.

For example, on this laptop, "cat /sys/firmware/edd/int13_dev80" outputs:
PCI 00:1f.7 channel: 0

The lspci output lists three functions for the PCI device 00:1f:
00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01)

Of these, 00:1f.1 is the device.
That is the primary (and only) IDE controller on this laptop, and channel 0 is the master disk.

With this information, I could positively identify the physical disk used for booting the system. (Although in the case of a laptop it's trivial, because there is only one disk :-)

(Why EDD lists 00:1f.7 instead of 00:1f.1, you might ask? I don't know for sure, but I guess it's probably related to different modes on the IDE controller: legacy DOS-compatible vs. native mode. BIOS uses the legacy mode, while Linux uses the native mode.)