Stage 1 and stage 2 bootloader

GRUB can load many operating systems in addition to Oracle Linux and it can chain-load proprietary operating systems. GRUB understands the formats of file systems and kernel executables, which allows it to load an arbitrary operating system without needing to know the exact location of the kernel on the boot device. GRUB requires only the file name and drive partitions to load a kernel. You can configure this information by editing the /boot/grub/grub.conf file, by using the GRUB menu, or by entering it on the command line. A portion of the GRUB bootloader code (stage 1 code) is written to the MBR, and the remainder is written to the /boot partition.

The GRUB bootloader is modular and operates in the following stages:

Stage 1

Stage 1 code is stored in the MBR. This code contains a block list that points to the next stage of GRUB, which is either stage1_5 or stage 2, depending on the file system type.

An unamended copy of the stage 1 code can be found in the file /boot/grub/stage1.

Stage1_5 code allows GRUB to interpret different types of file system. For some file system types such as ext4, GRUB does not need to load stage1_5. The code for each file system type is stored as files in /boot/grub:

Stage 2

Stage 2 code reads /boot/grub/grub.conf to determine how to load the kernel. The stage 2 code is stored in the file /boot/grub/stage2:

GRUB Legacy can be installed in several ways: with or without Stage 1.5.

When installed with Stage 1.5, the pointer in the MBR points to the beginning of Stage 1.5. The MBR code loads the first block of Stage 1.5; the code in that block includes a list of further blocks to load, and a BIOS partition number and a filename specifying where to find Stage 2.

But in the OP's case, GRUB Legacy has been installed without Stage 1.5, as indicated by the text Loading stage2 in the second hex dump. In this case, MBR loads the first block of Stage 2 directly, and like in the case of Stage 1.5, the first block will have a list of further blocks to load embedded in it.

The separation between stage 1.5 and stage2 existed to allow embedding stage 1.5 between the MBR and the beginning of the first partition even on disks that used the old DOS-compatible convention of starting the first partition at the beginning of track #1, head #0, rather than from block #2048 (i.e. exactly 1 MiB from the start of the disk) as modern operating systems do. Stage 2 might not fit into the area between the MBR and the beginning of the partition, but stage 1.5 is smaller, since it only needs to be able to read one filesystem type.

When installed with Stage 1.5, the Stage 2 of GRUB Legacy can be treated like a regular file, since it is loaded by filename, not by absolute block numbers. But when installed without Stage 1.5, Stage 2 may not be moved on disk from whatever block location it was placed by the installer. Filesystem-type-specific actions should be performed to make sure that the file won't be accidentally moved: for example, on a VFAT filesystem, the Stage 2 file should be marked with the "system" and "read-only" attributes.

Of course, the installer can embed Stage 2 between the MBR and the beginning of the first partition if it fits in the available space, in which case protection from in-filesystem manipulations will not be an issue.

Here's the tail end of the OP's second hex dump:

It contains the specification of further blocks to load, as a number of 8-byte block list structures. In this case there is just one of them: "load 0x00f6 blocks starting from block# 0x000849fd to 16-bit segment address 0x0820". Note that the block number is only 32-bit, not a full LBA48 block number: this restricts GRUB Legacy from accessing the full capacity of large disks.

1. BIOS(not using EFI) reads MBR, finds partition table, and loads GRUB stage1 (first 446 bytes) into memory

This is entirely correct.

1. I have /boot partition under 1024 cylinders, and the idea I have extracted from a bunch of documentation is that GRUB stage1 can directly load stage2 if it is located at some place under 1024 cylinders.

Technically, "at any location that is addressable by a 32-bit LBA block number", but otherwise correct. The "under 1024 cylinders" would come into play if the BIOS had no support for LBA access, and GRUB had to fall back to old C/H/S style BIOS calls... but in any post-Y2K hardware, this should not be an issue.

Some documentation I have consulted mentions that stage1.5 is located right after MBR before sector 63,

If stage1.5 is used, this is where it usually ends up. It does not have to be there, though. The "before sector 63" comes from the old DOS convention for the location of the beginning of the first partition, as I stated above.

while others suggest that it can be anywhere in first 1MB of disk

It actually can be anywhere that is addressable by a 32-bit block number, but again, the first 1 MB is where it usually is, when Stage 1.5 is used at all. The "first 1 MB" comes from the modern SSD/SAN-friendly convention of setting the beginning of the partition at exactly 1 MiB from the beginning of the disk, which is a nice big even power-of-2 so it will be aligned nicely with larger block sizes, RAID stripe sizes and/or whatever other alignment preferences the storage hardware might have.

and yet another group claimed that stage1.5 is just a GRUB v2 thing and does not apply on GRUB legacy.

This documentation gets it exactly backwards: stage1.5 is specifically GRUB Legacy thing only.

1. GRUB stage2 has all the necessary drivers/modules to read file systems and thus loads kernel and ramdisk and handover control to kernel.

Correct.

1. Kernel kicks off init on RHEL/CENTOS 6 and systemd on RHEL/CENTOS 7.

A bit of simplification, but essentially correct.

In RHEL/CentOS 6, the very first userspace process initially runs /init within the initial ramdisk file, which is actually a script, whose last action is to run exec switch_root <mountpoint_of_real_root_filesystem> /sbin/init <arguments> or similar.

In RHEL/CentOS 7, the /init is actually a link to /usr/lib/systemd/systemd within the initramfs, which will start a special version of systemd that recognizes some systemd-specific parameters with a rd. prefix. Like the /init script in older versions, it sets up whatever is needed to access the root filesystem, then exec()s the "full" version of systemd on the real root filesystem.

What is a 2 stage boot loader?

What is a first stage bootloader?

What are the different stages of GRUB?

Where is the stage 1 of GRUB usually located?