0

Running RHEL7 Virtual Machine in my home lab. /boot is separated from "/".

root@localhost ~# grep part anaconda-ks.cfg -A4
clearpart --none --initlabel
# Disk partitioning information
part pv.251 --fstype="lvmpv" --ondisk=sda --size=12808
part /boot --fstype="xfs" --ondisk=sda --size=512
volgroup rhel --pesize=4096 pv.251
logvol swap  --fstype="swap" --size=512 --name=swap --vgname=rhel
logvol /home  --fstype="xfs" --size=1024 --name=home --vgname=rhel
logvol /  --fstype="xfs" --size=11264 --name=root --vgname=rhel

I deleted "/boot" entry from /etc/fstab to see what will happen(I expected an error about missing grub2 or initramfs). But what happens is nothing! RHEL7 boots up and login prompt presented to me and I am able to login to the system. I can not figure out how grub2, then initramfs, and kernel have been loaded without /boot?

1
  • added an important note to the answer May 22, 2016 at 15:36

1 Answer 1

0

I can not figure out how grub2, then initramfs, and kernel have been loaded without /boot?

Because all those things will have already happened before /etc/fstab is read.

  1. the firmware loads GRUB
  2. GRUB loads the kernel & initramfs;
  3. the kernel starts init;
  4. init reads /etc/fstab.

Therefore neither the firmware nor GRUB can depend on /etc/fstab – they use their own mechanisms:

  • BIOS firmwares always run the bootcode from the disk's 0th sector (where the MBR is). In your case, that 0th sector would have the GRUB stage1.

  • UEFI firmwares keep boot configuration in NVRAM – the RHEL installer configures it to look for grubx64.efi in an "EFI system partition", which is detected by UUID.

  • Once GRUB is started, it already knows its own partition, finds grub.cfg in it, and searches for the Linux kernel based on UUID defined there. (Of course, grub.cfg is often generated based on fstab contents during installation.)

(GRUB has its own drivers for ext4 and even LVM. Some bootloaders, e.g. systemd-boot, use UEFI to access files in the "EFI system partition". LILO used to remember the kernel's sector position on disk, I think.)


The other reason is that /etc/fstab is an OS-specific configuration, therefore having GRUB directly depend on it would prevent it from correctly booting operating systems which don't have such a fstab.

(The same is even more important for the first step (firmware loading GRUB). Just think about it – if /etc/fstab was required for that, how would the firmware boot Windows?)


Note, however, that /boot needs to be in fstab – or mounted some other way – for kernel updates to work correctly. If you forget to mount /boot, the next upgrade will install new modules but not the kernel itself. Since you cannot mix different kernel and module versions, the system won't boot correctly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .