How does Grub Stage1, exactly, access/load stage 2?
Clash Royale CLAN TAG#URR8PPP
This is my first ever question, I have put this question in front of Red Hat Instructors but didn't find any satisfying answers.
I'm using RHEL/CENTOS6, GRUB Legacy 0.97, and have consulted heaps of documentation explaining linux boot process.
Almost all of the blogs, documentation etc. successfully explain the steps involved and the whole process but fail unanimously at as what actually takes place when loading grub stage2.
Here is my understanding of the process and have done a bit of testing as well;
- BIOS(not using EFI) reads MBR, finds partition table, and loads GRUB
stage1 (first 446 bytes) into memory - 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. Some documentation I have consulted mentions that
stage1.5 is located right after MBR before sector 63, while others
suggest that it can be anywhere in first 1MB of disk and yet another
group claimed that stage1.5 is just a GRUB v2 thing and does not
apply on GRUB legacy. - GRUB stage2 has all the necessary drivers/modules to read file
systems and thus loads kernel and ramdisk and handover control to
kernel. - Kernel kicks off init on RHEL/CENTOS 6 and systemd on RHEL/CENTOS 7.
I have dumped all the data from the 1st MB of the disk and can confirm that there is nothing except MBR. I get confused as to how 446 byte GRUB stage1 can load stage2 from a file system? According to some images on wikipedia and a few documents, when GRUB is installed, stage1 contains a LBA48 pointed to stage2.
Playing on the fact, I tried to test if systems boots when stage2 in removed or renamed from /boot/grub/ directory. The systems was still bootable even when there was no stage2 in the filesystem.
1st MB from /dev/sda
[root@chief zul.kifal]# dd if=/dev/sda bs=1024k count=1 | hexdump -C
00000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.H..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02 |.........|...t..|
00000040 80 00 00 80 fc 49 08 00 00 08 fa 90 90 f6 c2 80 |.....I..........|
00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......|
00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 |. ..@|<.t...R...|
00000070 74 54 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 |tT.A..U..ZRrI..U|
00000080 aa 75 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 |.uC.A|..u....t7f|
00000090 8b 4c 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 |.L...|.D..f..D|.|
000000a0 04 10 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 |....D...f...D..|
000000b0 70 66 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 |pf1..D.f.D..B..r|
000000c0 05 bb 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f |...p.}....s.....|
000000d0 84 f0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 |........|.D..f1.|
000000e0 88 f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 |..@f.D.1........|
000000f0 88 f4 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 |..@.D.1......f..|
00000100 66 a1 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 |f.D|f1.f.4.T.f1.|
00000110 66 f7 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a |f.t..T..D.;D.}<.|
00000120 54 0d c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a |T.....L......l.Z|
00000130 8a 74 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 |.t...p..1......r|
00000140 2a 8c c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 |*....H|.......1.|
00000150 31 ff fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 |1.....a.&B|..}.@|
00000160 00 eb 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 |.....}.8.....}.0|
00000170 00 be 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 |...}.*...GRUB .G|
00000180 65 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 |eom.Hard Disk.Re|
00000190 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd |ad. Error.......|
000001a0 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 |..<.u...........|
000001b0 00 00 00 00 00 00 00 00 19 aa 09 00 00 00 80 20 |............... |
000001c0 21 00 83 dd 1e 3f 00 08 00 00 00 a0 0f 00 00 dd |!....?..........|
000001d0 1f 3f 8e fe ff ff 00 a8 0f 00 00 58 f0 04 00 00 |.?.........X....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0184614 s, 56.8 MB/s
Magic word 0044-0047h = 0x000849fc
00000040 80 00 00 80 **fc 49 08 00** 00 08 fa 90 90 f6 c2 80 |.....I..........|
[root@chief zul.kifal]# dd if=/dev/sda skip=$((0x849fc)) bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00260914 s, 196 kB/s
00000000 52 56 5e bf f8 81 66 8b 2d 83 7d 04 00 0f 84 c4 |RV^...f.-.}.....|
00000010 00 80 7c ff 00 74 3e 66 8b 1d 66 31 c0 b0 7f 39 |..|..t>f..f1...9|
00000020 45 04 7f 03 8b 45 04 29 45 04 66 01 05 c7 04 10 |E....E.)E.f.....|
00000030 00 89 44 02 66 89 5c 08 c7 44 06 00 70 50 66 31 |..D.f...D..pPf1|
00000040 c0 89 44 04 66 89 44 0c b4 42 cd 13 0f 82 93 00 |..D.f.D..B......|
00000050 bb 00 70 eb 56 66 8b 05 66 31 d2 66 f7 34 88 54 |..p.Vf..f1.f.4.T|
00000060 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c 3b 44 |.f1.f.t..T..D.;D|
00000070 08 7d 68 8b 04 2a 44 0a 39 45 04 7f 03 8b 45 04 |.}h..*D.9E....E.|
00000080 29 45 04 66 01 05 8a 54 0d c0 e2 06 8a 4c 0a fe |)E.f...T.....L..|
00000090 c1 08 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e |....l.ZR.t.P..p.|
000000a0 c3 31 db b4 02 cd 13 72 3a 8c c3 8e 45 06 58 c1 |.1.....r:...E.X.|
000000b0 e0 05 01 45 06 60 1e c1 e0 04 89 c1 31 ff 31 f6 |...E........1.1.|
000000c0 8e db fc f3 a4 1f 61 83 7d 04 00 0f 85 42 ff 83 |......a.}....B..|
000000d0 ef 08 e9 34 ff 5a ea 00 82 00 00 be 05 81 e8 3d |...4.Z.........=|
000000e0 00 eb 06 be 0a 81 e8 35 00 be 0f 81 e8 2f 00 eb |.......5...../..|
000000f0 fe 4c 6f 61 64 69 6e 67 20 73 74 61 67 65 32 00 |.Loading stage2.|
00000100 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 64 00 20 |.....Geom.Read. |
00000110 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 46 8a 04 |Error........F..|
00000120 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 00 00 00 |<.u.............|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 fd 49 08 00 f6 00 20 08 |.........I.... .|
00000200
(/boot) starts at 2048.
# fdisk -lu /dev/sda
Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009aa19
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux Par...
/dev/sda2 1026048 83886079 41430016 8e Linux LVM
Will really appreciate if anyone can explain it.
linux boot grub
migrated from serverfault.com Feb 1 '16 at 19:23
This question came from our site for system and network administrators.
add a comment |
This is my first ever question, I have put this question in front of Red Hat Instructors but didn't find any satisfying answers.
I'm using RHEL/CENTOS6, GRUB Legacy 0.97, and have consulted heaps of documentation explaining linux boot process.
Almost all of the blogs, documentation etc. successfully explain the steps involved and the whole process but fail unanimously at as what actually takes place when loading grub stage2.
Here is my understanding of the process and have done a bit of testing as well;
- BIOS(not using EFI) reads MBR, finds partition table, and loads GRUB
stage1 (first 446 bytes) into memory - 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. Some documentation I have consulted mentions that
stage1.5 is located right after MBR before sector 63, while others
suggest that it can be anywhere in first 1MB of disk and yet another
group claimed that stage1.5 is just a GRUB v2 thing and does not
apply on GRUB legacy. - GRUB stage2 has all the necessary drivers/modules to read file
systems and thus loads kernel and ramdisk and handover control to
kernel. - Kernel kicks off init on RHEL/CENTOS 6 and systemd on RHEL/CENTOS 7.
I have dumped all the data from the 1st MB of the disk and can confirm that there is nothing except MBR. I get confused as to how 446 byte GRUB stage1 can load stage2 from a file system? According to some images on wikipedia and a few documents, when GRUB is installed, stage1 contains a LBA48 pointed to stage2.
Playing on the fact, I tried to test if systems boots when stage2 in removed or renamed from /boot/grub/ directory. The systems was still bootable even when there was no stage2 in the filesystem.
1st MB from /dev/sda
[root@chief zul.kifal]# dd if=/dev/sda bs=1024k count=1 | hexdump -C
00000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.H..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02 |.........|...t..|
00000040 80 00 00 80 fc 49 08 00 00 08 fa 90 90 f6 c2 80 |.....I..........|
00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......|
00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 |. ..@|<.t...R...|
00000070 74 54 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 |tT.A..U..ZRrI..U|
00000080 aa 75 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 |.uC.A|..u....t7f|
00000090 8b 4c 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 |.L...|.D..f..D|.|
000000a0 04 10 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 |....D...f...D..|
000000b0 70 66 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 |pf1..D.f.D..B..r|
000000c0 05 bb 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f |...p.}....s.....|
000000d0 84 f0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 |........|.D..f1.|
000000e0 88 f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 |..@f.D.1........|
000000f0 88 f4 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 |..@.D.1......f..|
00000100 66 a1 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 |f.D|f1.f.4.T.f1.|
00000110 66 f7 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a |f.t..T..D.;D.}<.|
00000120 54 0d c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a |T.....L......l.Z|
00000130 8a 74 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 |.t...p..1......r|
00000140 2a 8c c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 |*....H|.......1.|
00000150 31 ff fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 |1.....a.&B|..}.@|
00000160 00 eb 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 |.....}.8.....}.0|
00000170 00 be 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 |...}.*...GRUB .G|
00000180 65 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 |eom.Hard Disk.Re|
00000190 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd |ad. Error.......|
000001a0 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 |..<.u...........|
000001b0 00 00 00 00 00 00 00 00 19 aa 09 00 00 00 80 20 |............... |
000001c0 21 00 83 dd 1e 3f 00 08 00 00 00 a0 0f 00 00 dd |!....?..........|
000001d0 1f 3f 8e fe ff ff 00 a8 0f 00 00 58 f0 04 00 00 |.?.........X....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0184614 s, 56.8 MB/s
Magic word 0044-0047h = 0x000849fc
00000040 80 00 00 80 **fc 49 08 00** 00 08 fa 90 90 f6 c2 80 |.....I..........|
[root@chief zul.kifal]# dd if=/dev/sda skip=$((0x849fc)) bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00260914 s, 196 kB/s
00000000 52 56 5e bf f8 81 66 8b 2d 83 7d 04 00 0f 84 c4 |RV^...f.-.}.....|
00000010 00 80 7c ff 00 74 3e 66 8b 1d 66 31 c0 b0 7f 39 |..|..t>f..f1...9|
00000020 45 04 7f 03 8b 45 04 29 45 04 66 01 05 c7 04 10 |E....E.)E.f.....|
00000030 00 89 44 02 66 89 5c 08 c7 44 06 00 70 50 66 31 |..D.f...D..pPf1|
00000040 c0 89 44 04 66 89 44 0c b4 42 cd 13 0f 82 93 00 |..D.f.D..B......|
00000050 bb 00 70 eb 56 66 8b 05 66 31 d2 66 f7 34 88 54 |..p.Vf..f1.f.4.T|
00000060 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c 3b 44 |.f1.f.t..T..D.;D|
00000070 08 7d 68 8b 04 2a 44 0a 39 45 04 7f 03 8b 45 04 |.}h..*D.9E....E.|
00000080 29 45 04 66 01 05 8a 54 0d c0 e2 06 8a 4c 0a fe |)E.f...T.....L..|
00000090 c1 08 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e |....l.ZR.t.P..p.|
000000a0 c3 31 db b4 02 cd 13 72 3a 8c c3 8e 45 06 58 c1 |.1.....r:...E.X.|
000000b0 e0 05 01 45 06 60 1e c1 e0 04 89 c1 31 ff 31 f6 |...E........1.1.|
000000c0 8e db fc f3 a4 1f 61 83 7d 04 00 0f 85 42 ff 83 |......a.}....B..|
000000d0 ef 08 e9 34 ff 5a ea 00 82 00 00 be 05 81 e8 3d |...4.Z.........=|
000000e0 00 eb 06 be 0a 81 e8 35 00 be 0f 81 e8 2f 00 eb |.......5...../..|
000000f0 fe 4c 6f 61 64 69 6e 67 20 73 74 61 67 65 32 00 |.Loading stage2.|
00000100 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 64 00 20 |.....Geom.Read. |
00000110 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 46 8a 04 |Error........F..|
00000120 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 00 00 00 |<.u.............|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 fd 49 08 00 f6 00 20 08 |.........I.... .|
00000200
(/boot) starts at 2048.
# fdisk -lu /dev/sda
Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009aa19
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux Par...
/dev/sda2 1026048 83886079 41430016 8e Linux LVM
Will really appreciate if anyone can explain it.
linux boot grub
migrated from serverfault.com Feb 1 '16 at 19:23
This question came from our site for system and network administrators.
2
Have you zeroed out the existing file? Because deleting it is unlikely to remove the actual data that grub is referring to from the disc.
– Anthon
Jan 31 '16 at 13:03
Took the system back to original state. dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. Verified that whole file had been zeroed. Rebooted. System still boots successfully.
– Zul K Irshad
Jan 31 '16 at 13:14
Comments are not for extended discussion; this conversation has been moved to chat.
– terdon♦
Feb 2 '16 at 10:58
add a comment |
This is my first ever question, I have put this question in front of Red Hat Instructors but didn't find any satisfying answers.
I'm using RHEL/CENTOS6, GRUB Legacy 0.97, and have consulted heaps of documentation explaining linux boot process.
Almost all of the blogs, documentation etc. successfully explain the steps involved and the whole process but fail unanimously at as what actually takes place when loading grub stage2.
Here is my understanding of the process and have done a bit of testing as well;
- BIOS(not using EFI) reads MBR, finds partition table, and loads GRUB
stage1 (first 446 bytes) into memory - 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. Some documentation I have consulted mentions that
stage1.5 is located right after MBR before sector 63, while others
suggest that it can be anywhere in first 1MB of disk and yet another
group claimed that stage1.5 is just a GRUB v2 thing and does not
apply on GRUB legacy. - GRUB stage2 has all the necessary drivers/modules to read file
systems and thus loads kernel and ramdisk and handover control to
kernel. - Kernel kicks off init on RHEL/CENTOS 6 and systemd on RHEL/CENTOS 7.
I have dumped all the data from the 1st MB of the disk and can confirm that there is nothing except MBR. I get confused as to how 446 byte GRUB stage1 can load stage2 from a file system? According to some images on wikipedia and a few documents, when GRUB is installed, stage1 contains a LBA48 pointed to stage2.
Playing on the fact, I tried to test if systems boots when stage2 in removed or renamed from /boot/grub/ directory. The systems was still bootable even when there was no stage2 in the filesystem.
1st MB from /dev/sda
[root@chief zul.kifal]# dd if=/dev/sda bs=1024k count=1 | hexdump -C
00000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.H..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02 |.........|...t..|
00000040 80 00 00 80 fc 49 08 00 00 08 fa 90 90 f6 c2 80 |.....I..........|
00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......|
00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 |. ..@|<.t...R...|
00000070 74 54 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 |tT.A..U..ZRrI..U|
00000080 aa 75 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 |.uC.A|..u....t7f|
00000090 8b 4c 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 |.L...|.D..f..D|.|
000000a0 04 10 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 |....D...f...D..|
000000b0 70 66 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 |pf1..D.f.D..B..r|
000000c0 05 bb 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f |...p.}....s.....|
000000d0 84 f0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 |........|.D..f1.|
000000e0 88 f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 |..@f.D.1........|
000000f0 88 f4 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 |..@.D.1......f..|
00000100 66 a1 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 |f.D|f1.f.4.T.f1.|
00000110 66 f7 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a |f.t..T..D.;D.}<.|
00000120 54 0d c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a |T.....L......l.Z|
00000130 8a 74 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 |.t...p..1......r|
00000140 2a 8c c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 |*....H|.......1.|
00000150 31 ff fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 |1.....a.&B|..}.@|
00000160 00 eb 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 |.....}.8.....}.0|
00000170 00 be 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 |...}.*...GRUB .G|
00000180 65 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 |eom.Hard Disk.Re|
00000190 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd |ad. Error.......|
000001a0 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 |..<.u...........|
000001b0 00 00 00 00 00 00 00 00 19 aa 09 00 00 00 80 20 |............... |
000001c0 21 00 83 dd 1e 3f 00 08 00 00 00 a0 0f 00 00 dd |!....?..........|
000001d0 1f 3f 8e fe ff ff 00 a8 0f 00 00 58 f0 04 00 00 |.?.........X....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0184614 s, 56.8 MB/s
Magic word 0044-0047h = 0x000849fc
00000040 80 00 00 80 **fc 49 08 00** 00 08 fa 90 90 f6 c2 80 |.....I..........|
[root@chief zul.kifal]# dd if=/dev/sda skip=$((0x849fc)) bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00260914 s, 196 kB/s
00000000 52 56 5e bf f8 81 66 8b 2d 83 7d 04 00 0f 84 c4 |RV^...f.-.}.....|
00000010 00 80 7c ff 00 74 3e 66 8b 1d 66 31 c0 b0 7f 39 |..|..t>f..f1...9|
00000020 45 04 7f 03 8b 45 04 29 45 04 66 01 05 c7 04 10 |E....E.)E.f.....|
00000030 00 89 44 02 66 89 5c 08 c7 44 06 00 70 50 66 31 |..D.f...D..pPf1|
00000040 c0 89 44 04 66 89 44 0c b4 42 cd 13 0f 82 93 00 |..D.f.D..B......|
00000050 bb 00 70 eb 56 66 8b 05 66 31 d2 66 f7 34 88 54 |..p.Vf..f1.f.4.T|
00000060 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c 3b 44 |.f1.f.t..T..D.;D|
00000070 08 7d 68 8b 04 2a 44 0a 39 45 04 7f 03 8b 45 04 |.}h..*D.9E....E.|
00000080 29 45 04 66 01 05 8a 54 0d c0 e2 06 8a 4c 0a fe |)E.f...T.....L..|
00000090 c1 08 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e |....l.ZR.t.P..p.|
000000a0 c3 31 db b4 02 cd 13 72 3a 8c c3 8e 45 06 58 c1 |.1.....r:...E.X.|
000000b0 e0 05 01 45 06 60 1e c1 e0 04 89 c1 31 ff 31 f6 |...E........1.1.|
000000c0 8e db fc f3 a4 1f 61 83 7d 04 00 0f 85 42 ff 83 |......a.}....B..|
000000d0 ef 08 e9 34 ff 5a ea 00 82 00 00 be 05 81 e8 3d |...4.Z.........=|
000000e0 00 eb 06 be 0a 81 e8 35 00 be 0f 81 e8 2f 00 eb |.......5...../..|
000000f0 fe 4c 6f 61 64 69 6e 67 20 73 74 61 67 65 32 00 |.Loading stage2.|
00000100 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 64 00 20 |.....Geom.Read. |
00000110 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 46 8a 04 |Error........F..|
00000120 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 00 00 00 |<.u.............|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 fd 49 08 00 f6 00 20 08 |.........I.... .|
00000200
(/boot) starts at 2048.
# fdisk -lu /dev/sda
Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009aa19
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux Par...
/dev/sda2 1026048 83886079 41430016 8e Linux LVM
Will really appreciate if anyone can explain it.
linux boot grub
This is my first ever question, I have put this question in front of Red Hat Instructors but didn't find any satisfying answers.
I'm using RHEL/CENTOS6, GRUB Legacy 0.97, and have consulted heaps of documentation explaining linux boot process.
Almost all of the blogs, documentation etc. successfully explain the steps involved and the whole process but fail unanimously at as what actually takes place when loading grub stage2.
Here is my understanding of the process and have done a bit of testing as well;
- BIOS(not using EFI) reads MBR, finds partition table, and loads GRUB
stage1 (first 446 bytes) into memory - 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. Some documentation I have consulted mentions that
stage1.5 is located right after MBR before sector 63, while others
suggest that it can be anywhere in first 1MB of disk and yet another
group claimed that stage1.5 is just a GRUB v2 thing and does not
apply on GRUB legacy. - GRUB stage2 has all the necessary drivers/modules to read file
systems and thus loads kernel and ramdisk and handover control to
kernel. - Kernel kicks off init on RHEL/CENTOS 6 and systemd on RHEL/CENTOS 7.
I have dumped all the data from the 1st MB of the disk and can confirm that there is nothing except MBR. I get confused as to how 446 byte GRUB stage1 can load stage2 from a file system? According to some images on wikipedia and a few documents, when GRUB is installed, stage1 contains a LBA48 pointed to stage2.
Playing on the fact, I tried to test if systems boots when stage2 in removed or renamed from /boot/grub/ directory. The systems was still bootable even when there was no stage2 in the filesystem.
1st MB from /dev/sda
[root@chief zul.kifal]# dd if=/dev/sda bs=1024k count=1 | hexdump -C
00000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.H..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02 |.........|...t..|
00000040 80 00 00 80 fc 49 08 00 00 08 fa 90 90 f6 c2 80 |.....I..........|
00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......|
00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 |. ..@|<.t...R...|
00000070 74 54 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 |tT.A..U..ZRrI..U|
00000080 aa 75 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 |.uC.A|..u....t7f|
00000090 8b 4c 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 |.L...|.D..f..D|.|
000000a0 04 10 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 |....D...f...D..|
000000b0 70 66 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 |pf1..D.f.D..B..r|
000000c0 05 bb 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f |...p.}....s.....|
000000d0 84 f0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 |........|.D..f1.|
000000e0 88 f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 |..@f.D.1........|
000000f0 88 f4 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 |..@.D.1......f..|
00000100 66 a1 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 |f.D|f1.f.4.T.f1.|
00000110 66 f7 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a |f.t..T..D.;D.}<.|
00000120 54 0d c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a |T.....L......l.Z|
00000130 8a 74 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 |.t...p..1......r|
00000140 2a 8c c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 |*....H|.......1.|
00000150 31 ff fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 |1.....a.&B|..}.@|
00000160 00 eb 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 |.....}.8.....}.0|
00000170 00 be 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 |...}.*...GRUB .G|
00000180 65 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 |eom.Hard Disk.Re|
00000190 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd |ad. Error.......|
000001a0 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 |..<.u...........|
000001b0 00 00 00 00 00 00 00 00 19 aa 09 00 00 00 80 20 |............... |
000001c0 21 00 83 dd 1e 3f 00 08 00 00 00 a0 0f 00 00 dd |!....?..........|
000001d0 1f 3f 8e fe ff ff 00 a8 0f 00 00 58 f0 04 00 00 |.?.........X....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0184614 s, 56.8 MB/s
Magic word 0044-0047h = 0x000849fc
00000040 80 00 00 80 **fc 49 08 00** 00 08 fa 90 90 f6 c2 80 |.....I..........|
[root@chief zul.kifal]# dd if=/dev/sda skip=$((0x849fc)) bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00260914 s, 196 kB/s
00000000 52 56 5e bf f8 81 66 8b 2d 83 7d 04 00 0f 84 c4 |RV^...f.-.}.....|
00000010 00 80 7c ff 00 74 3e 66 8b 1d 66 31 c0 b0 7f 39 |..|..t>f..f1...9|
00000020 45 04 7f 03 8b 45 04 29 45 04 66 01 05 c7 04 10 |E....E.)E.f.....|
00000030 00 89 44 02 66 89 5c 08 c7 44 06 00 70 50 66 31 |..D.f...D..pPf1|
00000040 c0 89 44 04 66 89 44 0c b4 42 cd 13 0f 82 93 00 |..D.f.D..B......|
00000050 bb 00 70 eb 56 66 8b 05 66 31 d2 66 f7 34 88 54 |..p.Vf..f1.f.4.T|
00000060 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c 3b 44 |.f1.f.t..T..D.;D|
00000070 08 7d 68 8b 04 2a 44 0a 39 45 04 7f 03 8b 45 04 |.}h..*D.9E....E.|
00000080 29 45 04 66 01 05 8a 54 0d c0 e2 06 8a 4c 0a fe |)E.f...T.....L..|
00000090 c1 08 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e |....l.ZR.t.P..p.|
000000a0 c3 31 db b4 02 cd 13 72 3a 8c c3 8e 45 06 58 c1 |.1.....r:...E.X.|
000000b0 e0 05 01 45 06 60 1e c1 e0 04 89 c1 31 ff 31 f6 |...E........1.1.|
000000c0 8e db fc f3 a4 1f 61 83 7d 04 00 0f 85 42 ff 83 |......a.}....B..|
000000d0 ef 08 e9 34 ff 5a ea 00 82 00 00 be 05 81 e8 3d |...4.Z.........=|
000000e0 00 eb 06 be 0a 81 e8 35 00 be 0f 81 e8 2f 00 eb |.......5...../..|
000000f0 fe 4c 6f 61 64 69 6e 67 20 73 74 61 67 65 32 00 |.Loading stage2.|
00000100 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 64 00 20 |.....Geom.Read. |
00000110 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 46 8a 04 |Error........F..|
00000120 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 00 00 00 |<.u.............|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 fd 49 08 00 f6 00 20 08 |.........I.... .|
00000200
(/boot) starts at 2048.
# fdisk -lu /dev/sda
Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009aa19
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux Par...
/dev/sda2 1026048 83886079 41430016 8e Linux LVM
Will really appreciate if anyone can explain it.
linux boot grub
linux boot grub
edited Feb 2 '16 at 10:51
terdon♦
128k31252427
128k31252427
asked Jan 31 '16 at 13:21
Zul K Irshad
10216
10216
migrated from serverfault.com Feb 1 '16 at 19:23
This question came from our site for system and network administrators.
migrated from serverfault.com Feb 1 '16 at 19:23
This question came from our site for system and network administrators.
2
Have you zeroed out the existing file? Because deleting it is unlikely to remove the actual data that grub is referring to from the disc.
– Anthon
Jan 31 '16 at 13:03
Took the system back to original state. dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. Verified that whole file had been zeroed. Rebooted. System still boots successfully.
– Zul K Irshad
Jan 31 '16 at 13:14
Comments are not for extended discussion; this conversation has been moved to chat.
– terdon♦
Feb 2 '16 at 10:58
add a comment |
2
Have you zeroed out the existing file? Because deleting it is unlikely to remove the actual data that grub is referring to from the disc.
– Anthon
Jan 31 '16 at 13:03
Took the system back to original state. dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. Verified that whole file had been zeroed. Rebooted. System still boots successfully.
– Zul K Irshad
Jan 31 '16 at 13:14
Comments are not for extended discussion; this conversation has been moved to chat.
– terdon♦
Feb 2 '16 at 10:58
2
2
Have you zeroed out the existing file? Because deleting it is unlikely to remove the actual data that grub is referring to from the disc.
– Anthon
Jan 31 '16 at 13:03
Have you zeroed out the existing file? Because deleting it is unlikely to remove the actual data that grub is referring to from the disc.
– Anthon
Jan 31 '16 at 13:03
Took the system back to original state. dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. Verified that whole file had been zeroed. Rebooted. System still boots successfully.
– Zul K Irshad
Jan 31 '16 at 13:14
Took the system back to original state. dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. Verified that whole file had been zeroed. Rebooted. System still boots successfully.
– Zul K Irshad
Jan 31 '16 at 13:14
Comments are not for extended discussion; this conversation has been moved to chat.
– terdon♦
Feb 2 '16 at 10:58
Comments are not for extended discussion; this conversation has been moved to chat.
– terdon♦
Feb 2 '16 at 10:58
add a comment |
3 Answers
3
active
oldest
votes
From https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
GRUB loads itself into memory in the following stages:
The Stage 1 or primary boot loader is read into memory by the BIOS
from the MBR[1]. The primary boot loader exists on less than 512 bytes
of disk space within the MBR and is capable of loading either the
Stage 1.5 or Stage 2 boot loader.
The Stage 1.5 boot loader is read into memory by the Stage 1 boot
loader, if necessary. Some hardware requires an intermediate step to
get to the Stage 2 boot loader. This is sometimes true when the /boot/
partition is above the 1024 cylinder head of the hard drive or when
using LBA mode. The Stage 1.5 boot loader is found either on the
/boot/ partition or on a small part of the MBR and the /boot/
partition.
The Stage 2 or secondary boot loader is read into memory. The
secondary boot loader displays the GRUB menu and command environment.
This interface allows selection of the kernel or operating system to
boot, pass arguments to the kernel, or look at system parameters.
It seems rather obvious stage 2 is the actual grub binary. In fact, the documentation states grub 2 is loaded by name.
I would try to do:
dd if=/dev/zero of=/boot/stage2
Additional data:
Inspecting /boot/grub:
copy of stage1 bootloader:
stage1
Files for stage1_5:
e2fs_stage1_5
fat_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
xfs_stage1_5
File for stage2:
stage2
Link to grub image:
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
please do asudo grub-install /dev/sda
and reboot
– Rui F Ribeiro
Jan 31 '16 at 13:56
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
|
show 3 more comments
In computers that conform to the IBM PC boot BIOS sequence:
- The MBR (absolute sector 0) from disk is loaded by BIOS at memory 0000:7C00.
- That code is executed.
Form IBM to W7
The code used by IBM PC to boot could be seen here:
First version of MBR from IBM® Personal Computer™ DOS 2.00
That code has many versions that are also presented in the starman's pages.
An start point about those many versions could be this page:
from MS-DOS 3.30 through MS-Windows™ 95 (A)
One of the most common MBR codes is this:
MBR for: MS-Windows™ 95B, 98, 98SE and ME
Most of that code versions used to just load the next VBR (Volume Boot Record). The VBR of the partition marked as boot-able in the partition table and then transfer execution to it.
(Please Understand that the VBR is not the absolute disk sector 0 or W7 MBR)
Search for this assembler note at the W7 MBR page:
; The following code uses INT 13, Function 42h ("Extended Read") to read the
; first sector (VBR) of the bootable partition into Memory at location 0x7c00.
Windows™ 7 (and Vista) VBR ( Volume Boot Record )
It is interesting to read this from the W7VBR page:
; The following code uses INT 13, Function 42h ("Extended Disk Read") to read
; 1 sector at a time of the remaining 15 sectors of the Boot Record Area into
; Memory; starting at location 7E00.
As you can confirm, the boot code started at the MBR (disk sector 0), loaded the VBR (Volume Boot record) and many (15 in W7) following sectors.
GRUB
But we are talking about GRUB here, so, go to the GRUB page:
And search for this code:
[7C44] -> Note: A very important location for anyone using GRUB!
This (4-byte) Quad-Word contains the location of GRUB's
stage2 file in sectors! It's called "stage2_sector" in
the stage1.S code. If GRUB is installed in the MBR by a
distro that always includes a number of sectors from
stage2 immediately following the GRUB MBR, you will see
the bytes 01 00 00 00 in this location; otherwise, it
will point to stage2 in the "/boot/grub" directory.
That is almost always 01 00 00 00
(or just: the next sector).
What that means is that BIOS load absolute sector 0 (MBR), GRUB code installed in the MBR keeps reading following sectors. Up to the size of core.img
(GRUB2) in recent distros (about 60 sectors, or ~30 kB). Present day drives leave a full Mega-byte free after the MBR, so there is no problem. EFI disks have a separate partition for all this code and there is even less problem (for size, that is).
Answer
Legacy GRUB write stage2, or optionally stage 1.5 in some corner cases, to the MBR and several/many of the following 62 sectors.
And that is also explained in images in the Wikipedia Grub page.
From GNU site 10 GRUB image files:
stage1
This is an essential image used for booting up GRUB. Usually, this is
embedded in an MBR or the boot sector of a partition. Because a PC boot
sector is 512 bytes, the size of this image is exactly 512 bytes.
All stage1 must do is to load Stage 2 or Stage 1.5 from a local disk.
Because of the size restriction, stage1 encodes the location of Stage 2
(or Stage 1.5) in a block list format, so it never understand any
filesystem structure.
NOTE: The stage2 might be written to other Physical disk. From the GRUB page:
[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
booting systems, if your Linux installation with GRUB's
See: remaining software (stage2, menu file, etc.) is located
7C5A somewhere other than on the Primary Master drive, this
value will be 81, 82, etc. depending upon which drive
that Linux OS's /boot/grub directory is located. In the
stage1.S file, it's called the GRUB_INVALID_DRIVE byte
and commented as: "the disk to load stage2 from." (The
word INVALID has something to do with the code logic.)
1
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
You said you tested deletingstage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for thestage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of thestage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstallstage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.
– telcoM
May 19 '18 at 9:13
add a comment |
What I did is configure and install Hiren's boot cd to load on a usb flash drive with the automated grub loader from hiren.info once I had the bootable Hiren's usb drive I resized the primary partition on the hdd reducing one gb form the back end of the flash drive. Then I created an ext4 partition in the unallocated space. Next all I did is run grub2config command in xterm on RIPLinuX and the installation was relatively automated. The wizard allows you to select the partition and directory that grub2 is installed in. I set the loader to the mbr on the primary partition of the flash drive and the ext4 /boot/grub as the installation directory for the grub2 files.
What happens is the grub2 grldr replaces the previous grldr in the root directory of the primary partition on the flash drive. The previous menu.lst file will likely be backed up before replacement with the new menu.lst file with the boot options you selected in the automated wizard. Once you complete the 4 or 5 step process (depending on your configuration preference) simply reboot the system selecting the usb disk as your boot device and when the grub2 menu.lst loads with your boot options just type the letter "c" to enter the grub2 command interface. Now you can fully load and boot to portable grub2 environment.
additional screenshots posted here:
https://www.minds.com/groups/profile/924192575922864128
I hope this helps.
Best wishes,
Raoul
1
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f259143%2fhow-does-grub-stage1-exactly-access-load-stage-2%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
From https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
GRUB loads itself into memory in the following stages:
The Stage 1 or primary boot loader is read into memory by the BIOS
from the MBR[1]. The primary boot loader exists on less than 512 bytes
of disk space within the MBR and is capable of loading either the
Stage 1.5 or Stage 2 boot loader.
The Stage 1.5 boot loader is read into memory by the Stage 1 boot
loader, if necessary. Some hardware requires an intermediate step to
get to the Stage 2 boot loader. This is sometimes true when the /boot/
partition is above the 1024 cylinder head of the hard drive or when
using LBA mode. The Stage 1.5 boot loader is found either on the
/boot/ partition or on a small part of the MBR and the /boot/
partition.
The Stage 2 or secondary boot loader is read into memory. The
secondary boot loader displays the GRUB menu and command environment.
This interface allows selection of the kernel or operating system to
boot, pass arguments to the kernel, or look at system parameters.
It seems rather obvious stage 2 is the actual grub binary. In fact, the documentation states grub 2 is loaded by name.
I would try to do:
dd if=/dev/zero of=/boot/stage2
Additional data:
Inspecting /boot/grub:
copy of stage1 bootloader:
stage1
Files for stage1_5:
e2fs_stage1_5
fat_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
xfs_stage1_5
File for stage2:
stage2
Link to grub image:
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
please do asudo grub-install /dev/sda
and reboot
– Rui F Ribeiro
Jan 31 '16 at 13:56
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
|
show 3 more comments
From https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
GRUB loads itself into memory in the following stages:
The Stage 1 or primary boot loader is read into memory by the BIOS
from the MBR[1]. The primary boot loader exists on less than 512 bytes
of disk space within the MBR and is capable of loading either the
Stage 1.5 or Stage 2 boot loader.
The Stage 1.5 boot loader is read into memory by the Stage 1 boot
loader, if necessary. Some hardware requires an intermediate step to
get to the Stage 2 boot loader. This is sometimes true when the /boot/
partition is above the 1024 cylinder head of the hard drive or when
using LBA mode. The Stage 1.5 boot loader is found either on the
/boot/ partition or on a small part of the MBR and the /boot/
partition.
The Stage 2 or secondary boot loader is read into memory. The
secondary boot loader displays the GRUB menu and command environment.
This interface allows selection of the kernel or operating system to
boot, pass arguments to the kernel, or look at system parameters.
It seems rather obvious stage 2 is the actual grub binary. In fact, the documentation states grub 2 is loaded by name.
I would try to do:
dd if=/dev/zero of=/boot/stage2
Additional data:
Inspecting /boot/grub:
copy of stage1 bootloader:
stage1
Files for stage1_5:
e2fs_stage1_5
fat_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
xfs_stage1_5
File for stage2:
stage2
Link to grub image:
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
please do asudo grub-install /dev/sda
and reboot
– Rui F Ribeiro
Jan 31 '16 at 13:56
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
|
show 3 more comments
From https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
GRUB loads itself into memory in the following stages:
The Stage 1 or primary boot loader is read into memory by the BIOS
from the MBR[1]. The primary boot loader exists on less than 512 bytes
of disk space within the MBR and is capable of loading either the
Stage 1.5 or Stage 2 boot loader.
The Stage 1.5 boot loader is read into memory by the Stage 1 boot
loader, if necessary. Some hardware requires an intermediate step to
get to the Stage 2 boot loader. This is sometimes true when the /boot/
partition is above the 1024 cylinder head of the hard drive or when
using LBA mode. The Stage 1.5 boot loader is found either on the
/boot/ partition or on a small part of the MBR and the /boot/
partition.
The Stage 2 or secondary boot loader is read into memory. The
secondary boot loader displays the GRUB menu and command environment.
This interface allows selection of the kernel or operating system to
boot, pass arguments to the kernel, or look at system parameters.
It seems rather obvious stage 2 is the actual grub binary. In fact, the documentation states grub 2 is loaded by name.
I would try to do:
dd if=/dev/zero of=/boot/stage2
Additional data:
Inspecting /boot/grub:
copy of stage1 bootloader:
stage1
Files for stage1_5:
e2fs_stage1_5
fat_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
xfs_stage1_5
File for stage2:
stage2
Link to grub image:
From https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html
GRUB loads itself into memory in the following stages:
The Stage 1 or primary boot loader is read into memory by the BIOS
from the MBR[1]. The primary boot loader exists on less than 512 bytes
of disk space within the MBR and is capable of loading either the
Stage 1.5 or Stage 2 boot loader.
The Stage 1.5 boot loader is read into memory by the Stage 1 boot
loader, if necessary. Some hardware requires an intermediate step to
get to the Stage 2 boot loader. This is sometimes true when the /boot/
partition is above the 1024 cylinder head of the hard drive or when
using LBA mode. The Stage 1.5 boot loader is found either on the
/boot/ partition or on a small part of the MBR and the /boot/
partition.
The Stage 2 or secondary boot loader is read into memory. The
secondary boot loader displays the GRUB menu and command environment.
This interface allows selection of the kernel or operating system to
boot, pass arguments to the kernel, or look at system parameters.
It seems rather obvious stage 2 is the actual grub binary. In fact, the documentation states grub 2 is loaded by name.
I would try to do:
dd if=/dev/zero of=/boot/stage2
Additional data:
Inspecting /boot/grub:
copy of stage1 bootloader:
stage1
Files for stage1_5:
e2fs_stage1_5
fat_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
xfs_stage1_5
File for stage2:
stage2
Link to grub image:
edited May 19 '18 at 1:53
answered Jan 31 '16 at 13:45
Rui F Ribeiro
39.2k1479130
39.2k1479130
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
please do asudo grub-install /dev/sda
and reboot
– Rui F Ribeiro
Jan 31 '16 at 13:56
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
|
show 3 more comments
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
please do asudo grub-install /dev/sda
and reboot
– Rui F Ribeiro
Jan 31 '16 at 13:56
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
I have already zeroed the stage2 file, dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. It didn't effect the system at all.
– Zul K Irshad
Jan 31 '16 at 13:54
please do a
sudo grub-install /dev/sda
and reboot– Rui F Ribeiro
Jan 31 '16 at 13:56
please do a
sudo grub-install /dev/sda
and reboot– Rui F Ribeiro
Jan 31 '16 at 13:56
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
according to this, it should work en.wikipedia.org/wiki/GNU_GRUB
– Rui F Ribeiro
Jan 31 '16 at 13:59
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
grub-install /dev/sda has regenerated /boot/grub/stage2 binary and system is still bootable.
– Zul K Irshad
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
maybe dd is creating a new file actually instead of overwriting the old one.
– Rui F Ribeiro
Jan 31 '16 at 14:02
|
show 3 more comments
In computers that conform to the IBM PC boot BIOS sequence:
- The MBR (absolute sector 0) from disk is loaded by BIOS at memory 0000:7C00.
- That code is executed.
Form IBM to W7
The code used by IBM PC to boot could be seen here:
First version of MBR from IBM® Personal Computer™ DOS 2.00
That code has many versions that are also presented in the starman's pages.
An start point about those many versions could be this page:
from MS-DOS 3.30 through MS-Windows™ 95 (A)
One of the most common MBR codes is this:
MBR for: MS-Windows™ 95B, 98, 98SE and ME
Most of that code versions used to just load the next VBR (Volume Boot Record). The VBR of the partition marked as boot-able in the partition table and then transfer execution to it.
(Please Understand that the VBR is not the absolute disk sector 0 or W7 MBR)
Search for this assembler note at the W7 MBR page:
; The following code uses INT 13, Function 42h ("Extended Read") to read the
; first sector (VBR) of the bootable partition into Memory at location 0x7c00.
Windows™ 7 (and Vista) VBR ( Volume Boot Record )
It is interesting to read this from the W7VBR page:
; The following code uses INT 13, Function 42h ("Extended Disk Read") to read
; 1 sector at a time of the remaining 15 sectors of the Boot Record Area into
; Memory; starting at location 7E00.
As you can confirm, the boot code started at the MBR (disk sector 0), loaded the VBR (Volume Boot record) and many (15 in W7) following sectors.
GRUB
But we are talking about GRUB here, so, go to the GRUB page:
And search for this code:
[7C44] -> Note: A very important location for anyone using GRUB!
This (4-byte) Quad-Word contains the location of GRUB's
stage2 file in sectors! It's called "stage2_sector" in
the stage1.S code. If GRUB is installed in the MBR by a
distro that always includes a number of sectors from
stage2 immediately following the GRUB MBR, you will see
the bytes 01 00 00 00 in this location; otherwise, it
will point to stage2 in the "/boot/grub" directory.
That is almost always 01 00 00 00
(or just: the next sector).
What that means is that BIOS load absolute sector 0 (MBR), GRUB code installed in the MBR keeps reading following sectors. Up to the size of core.img
(GRUB2) in recent distros (about 60 sectors, or ~30 kB). Present day drives leave a full Mega-byte free after the MBR, so there is no problem. EFI disks have a separate partition for all this code and there is even less problem (for size, that is).
Answer
Legacy GRUB write stage2, or optionally stage 1.5 in some corner cases, to the MBR and several/many of the following 62 sectors.
And that is also explained in images in the Wikipedia Grub page.
From GNU site 10 GRUB image files:
stage1
This is an essential image used for booting up GRUB. Usually, this is
embedded in an MBR or the boot sector of a partition. Because a PC boot
sector is 512 bytes, the size of this image is exactly 512 bytes.
All stage1 must do is to load Stage 2 or Stage 1.5 from a local disk.
Because of the size restriction, stage1 encodes the location of Stage 2
(or Stage 1.5) in a block list format, so it never understand any
filesystem structure.
NOTE: The stage2 might be written to other Physical disk. From the GRUB page:
[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
booting systems, if your Linux installation with GRUB's
See: remaining software (stage2, menu file, etc.) is located
7C5A somewhere other than on the Primary Master drive, this
value will be 81, 82, etc. depending upon which drive
that Linux OS's /boot/grub directory is located. In the
stage1.S file, it's called the GRUB_INVALID_DRIVE byte
and commented as: "the disk to load stage2 from." (The
word INVALID has something to do with the code logic.)
1
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
You said you tested deletingstage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for thestage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of thestage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstallstage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.
– telcoM
May 19 '18 at 9:13
add a comment |
In computers that conform to the IBM PC boot BIOS sequence:
- The MBR (absolute sector 0) from disk is loaded by BIOS at memory 0000:7C00.
- That code is executed.
Form IBM to W7
The code used by IBM PC to boot could be seen here:
First version of MBR from IBM® Personal Computer™ DOS 2.00
That code has many versions that are also presented in the starman's pages.
An start point about those many versions could be this page:
from MS-DOS 3.30 through MS-Windows™ 95 (A)
One of the most common MBR codes is this:
MBR for: MS-Windows™ 95B, 98, 98SE and ME
Most of that code versions used to just load the next VBR (Volume Boot Record). The VBR of the partition marked as boot-able in the partition table and then transfer execution to it.
(Please Understand that the VBR is not the absolute disk sector 0 or W7 MBR)
Search for this assembler note at the W7 MBR page:
; The following code uses INT 13, Function 42h ("Extended Read") to read the
; first sector (VBR) of the bootable partition into Memory at location 0x7c00.
Windows™ 7 (and Vista) VBR ( Volume Boot Record )
It is interesting to read this from the W7VBR page:
; The following code uses INT 13, Function 42h ("Extended Disk Read") to read
; 1 sector at a time of the remaining 15 sectors of the Boot Record Area into
; Memory; starting at location 7E00.
As you can confirm, the boot code started at the MBR (disk sector 0), loaded the VBR (Volume Boot record) and many (15 in W7) following sectors.
GRUB
But we are talking about GRUB here, so, go to the GRUB page:
And search for this code:
[7C44] -> Note: A very important location for anyone using GRUB!
This (4-byte) Quad-Word contains the location of GRUB's
stage2 file in sectors! It's called "stage2_sector" in
the stage1.S code. If GRUB is installed in the MBR by a
distro that always includes a number of sectors from
stage2 immediately following the GRUB MBR, you will see
the bytes 01 00 00 00 in this location; otherwise, it
will point to stage2 in the "/boot/grub" directory.
That is almost always 01 00 00 00
(or just: the next sector).
What that means is that BIOS load absolute sector 0 (MBR), GRUB code installed in the MBR keeps reading following sectors. Up to the size of core.img
(GRUB2) in recent distros (about 60 sectors, or ~30 kB). Present day drives leave a full Mega-byte free after the MBR, so there is no problem. EFI disks have a separate partition for all this code and there is even less problem (for size, that is).
Answer
Legacy GRUB write stage2, or optionally stage 1.5 in some corner cases, to the MBR and several/many of the following 62 sectors.
And that is also explained in images in the Wikipedia Grub page.
From GNU site 10 GRUB image files:
stage1
This is an essential image used for booting up GRUB. Usually, this is
embedded in an MBR or the boot sector of a partition. Because a PC boot
sector is 512 bytes, the size of this image is exactly 512 bytes.
All stage1 must do is to load Stage 2 or Stage 1.5 from a local disk.
Because of the size restriction, stage1 encodes the location of Stage 2
(or Stage 1.5) in a block list format, so it never understand any
filesystem structure.
NOTE: The stage2 might be written to other Physical disk. From the GRUB page:
[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
booting systems, if your Linux installation with GRUB's
See: remaining software (stage2, menu file, etc.) is located
7C5A somewhere other than on the Primary Master drive, this
value will be 81, 82, etc. depending upon which drive
that Linux OS's /boot/grub directory is located. In the
stage1.S file, it's called the GRUB_INVALID_DRIVE byte
and commented as: "the disk to load stage2 from." (The
word INVALID has something to do with the code logic.)
1
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
You said you tested deletingstage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for thestage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of thestage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstallstage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.
– telcoM
May 19 '18 at 9:13
add a comment |
In computers that conform to the IBM PC boot BIOS sequence:
- The MBR (absolute sector 0) from disk is loaded by BIOS at memory 0000:7C00.
- That code is executed.
Form IBM to W7
The code used by IBM PC to boot could be seen here:
First version of MBR from IBM® Personal Computer™ DOS 2.00
That code has many versions that are also presented in the starman's pages.
An start point about those many versions could be this page:
from MS-DOS 3.30 through MS-Windows™ 95 (A)
One of the most common MBR codes is this:
MBR for: MS-Windows™ 95B, 98, 98SE and ME
Most of that code versions used to just load the next VBR (Volume Boot Record). The VBR of the partition marked as boot-able in the partition table and then transfer execution to it.
(Please Understand that the VBR is not the absolute disk sector 0 or W7 MBR)
Search for this assembler note at the W7 MBR page:
; The following code uses INT 13, Function 42h ("Extended Read") to read the
; first sector (VBR) of the bootable partition into Memory at location 0x7c00.
Windows™ 7 (and Vista) VBR ( Volume Boot Record )
It is interesting to read this from the W7VBR page:
; The following code uses INT 13, Function 42h ("Extended Disk Read") to read
; 1 sector at a time of the remaining 15 sectors of the Boot Record Area into
; Memory; starting at location 7E00.
As you can confirm, the boot code started at the MBR (disk sector 0), loaded the VBR (Volume Boot record) and many (15 in W7) following sectors.
GRUB
But we are talking about GRUB here, so, go to the GRUB page:
And search for this code:
[7C44] -> Note: A very important location for anyone using GRUB!
This (4-byte) Quad-Word contains the location of GRUB's
stage2 file in sectors! It's called "stage2_sector" in
the stage1.S code. If GRUB is installed in the MBR by a
distro that always includes a number of sectors from
stage2 immediately following the GRUB MBR, you will see
the bytes 01 00 00 00 in this location; otherwise, it
will point to stage2 in the "/boot/grub" directory.
That is almost always 01 00 00 00
(or just: the next sector).
What that means is that BIOS load absolute sector 0 (MBR), GRUB code installed in the MBR keeps reading following sectors. Up to the size of core.img
(GRUB2) in recent distros (about 60 sectors, or ~30 kB). Present day drives leave a full Mega-byte free after the MBR, so there is no problem. EFI disks have a separate partition for all this code and there is even less problem (for size, that is).
Answer
Legacy GRUB write stage2, or optionally stage 1.5 in some corner cases, to the MBR and several/many of the following 62 sectors.
And that is also explained in images in the Wikipedia Grub page.
From GNU site 10 GRUB image files:
stage1
This is an essential image used for booting up GRUB. Usually, this is
embedded in an MBR or the boot sector of a partition. Because a PC boot
sector is 512 bytes, the size of this image is exactly 512 bytes.
All stage1 must do is to load Stage 2 or Stage 1.5 from a local disk.
Because of the size restriction, stage1 encodes the location of Stage 2
(or Stage 1.5) in a block list format, so it never understand any
filesystem structure.
NOTE: The stage2 might be written to other Physical disk. From the GRUB page:
[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
booting systems, if your Linux installation with GRUB's
See: remaining software (stage2, menu file, etc.) is located
7C5A somewhere other than on the Primary Master drive, this
value will be 81, 82, etc. depending upon which drive
that Linux OS's /boot/grub directory is located. In the
stage1.S file, it's called the GRUB_INVALID_DRIVE byte
and commented as: "the disk to load stage2 from." (The
word INVALID has something to do with the code logic.)
In computers that conform to the IBM PC boot BIOS sequence:
- The MBR (absolute sector 0) from disk is loaded by BIOS at memory 0000:7C00.
- That code is executed.
Form IBM to W7
The code used by IBM PC to boot could be seen here:
First version of MBR from IBM® Personal Computer™ DOS 2.00
That code has many versions that are also presented in the starman's pages.
An start point about those many versions could be this page:
from MS-DOS 3.30 through MS-Windows™ 95 (A)
One of the most common MBR codes is this:
MBR for: MS-Windows™ 95B, 98, 98SE and ME
Most of that code versions used to just load the next VBR (Volume Boot Record). The VBR of the partition marked as boot-able in the partition table and then transfer execution to it.
(Please Understand that the VBR is not the absolute disk sector 0 or W7 MBR)
Search for this assembler note at the W7 MBR page:
; The following code uses INT 13, Function 42h ("Extended Read") to read the
; first sector (VBR) of the bootable partition into Memory at location 0x7c00.
Windows™ 7 (and Vista) VBR ( Volume Boot Record )
It is interesting to read this from the W7VBR page:
; The following code uses INT 13, Function 42h ("Extended Disk Read") to read
; 1 sector at a time of the remaining 15 sectors of the Boot Record Area into
; Memory; starting at location 7E00.
As you can confirm, the boot code started at the MBR (disk sector 0), loaded the VBR (Volume Boot record) and many (15 in W7) following sectors.
GRUB
But we are talking about GRUB here, so, go to the GRUB page:
And search for this code:
[7C44] -> Note: A very important location for anyone using GRUB!
This (4-byte) Quad-Word contains the location of GRUB's
stage2 file in sectors! It's called "stage2_sector" in
the stage1.S code. If GRUB is installed in the MBR by a
distro that always includes a number of sectors from
stage2 immediately following the GRUB MBR, you will see
the bytes 01 00 00 00 in this location; otherwise, it
will point to stage2 in the "/boot/grub" directory.
That is almost always 01 00 00 00
(or just: the next sector).
What that means is that BIOS load absolute sector 0 (MBR), GRUB code installed in the MBR keeps reading following sectors. Up to the size of core.img
(GRUB2) in recent distros (about 60 sectors, or ~30 kB). Present day drives leave a full Mega-byte free after the MBR, so there is no problem. EFI disks have a separate partition for all this code and there is even less problem (for size, that is).
Answer
Legacy GRUB write stage2, or optionally stage 1.5 in some corner cases, to the MBR and several/many of the following 62 sectors.
And that is also explained in images in the Wikipedia Grub page.
From GNU site 10 GRUB image files:
stage1
This is an essential image used for booting up GRUB. Usually, this is
embedded in an MBR or the boot sector of a partition. Because a PC boot
sector is 512 bytes, the size of this image is exactly 512 bytes.
All stage1 must do is to load Stage 2 or Stage 1.5 from a local disk.
Because of the size restriction, stage1 encodes the location of Stage 2
(or Stage 1.5) in a block list format, so it never understand any
filesystem structure.
NOTE: The stage2 might be written to other Physical disk. From the GRUB page:
[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
booting systems, if your Linux installation with GRUB's
See: remaining software (stage2, menu file, etc.) is located
7C5A somewhere other than on the Primary Master drive, this
value will be 81, 82, etc. depending upon which drive
that Linux OS's /boot/grub directory is located. In the
stage1.S file, it's called the GRUB_INVALID_DRIVE byte
and commented as: "the disk to load stage2 from." (The
word INVALID has something to do with the code logic.)
answered Feb 1 '16 at 22:35
user79743
1
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
You said you tested deletingstage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for thestage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of thestage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstallstage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.
– telcoM
May 19 '18 at 9:13
add a comment |
1
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
You said you tested deletingstage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for thestage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of thestage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstallstage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.
– telcoM
May 19 '18 at 9:13
1
1
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
Thanks for your answer, it is by far the closest response I have yet received. I had a look at the GRUB page already yesterday and did a bit of reverse engineering. 4-byte (Quad) Word located at offsets 0044h-0047h got me to the location of stage2 on disk. It was something like 256MB from the start of disk (/boot on a standard partition), I looked up /boot/grub/stage2's inode using debugfs, both of them were different locations. I zeroed stage2 in the file-system, but Quad word still took me to a valid stage2. My question now becomes, can I look at this valid file from file-system?
– Zul K Irshad
Feb 1 '16 at 22:44
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
I have had a look at the whole first MB of disk, there is nothing but 512bytes of MBR. By looking at the magic Quad word, I did conclude that it is looking at a different location rather than /boot/grub/stage2, what bothers me is that why that location (pointed by Quad Word) is 256MB deep into the disk.
– Zul K Irshad
Feb 1 '16 at 23:01
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
The disk started at sector 2048 ~ 1MB. Have updated the question with more details.
– Zul K Irshad
Feb 2 '16 at 0:00
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
@BinaryZebra. Your statement "By far, the usual way to install stage2 to the MBR" is absolute rubbish. An MBR cannot hold GRUB Legacy stage2
– fpmurphy
Feb 2 '16 at 1:28
You said you tested deleting
stage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for the stage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of the stage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstall stage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.– telcoM
May 19 '18 at 9:13
You said you tested deleting
stage2
from the filesystem. If your first such test did not involve actually overwriting the file, it is likely that the filesystem found a different location for the stage2
file when you replaced it after the test. But since the blocks were not overwritten, the content of the stage2
is still present in those original blocks, although they may now be marked as free space in the filesystem metadata. If you don't reinstall stage1
, your GRUB will likely stop working if/when something causes those "free" blocks to be reused and overwritten.– telcoM
May 19 '18 at 9:13
add a comment |
What I did is configure and install Hiren's boot cd to load on a usb flash drive with the automated grub loader from hiren.info once I had the bootable Hiren's usb drive I resized the primary partition on the hdd reducing one gb form the back end of the flash drive. Then I created an ext4 partition in the unallocated space. Next all I did is run grub2config command in xterm on RIPLinuX and the installation was relatively automated. The wizard allows you to select the partition and directory that grub2 is installed in. I set the loader to the mbr on the primary partition of the flash drive and the ext4 /boot/grub as the installation directory for the grub2 files.
What happens is the grub2 grldr replaces the previous grldr in the root directory of the primary partition on the flash drive. The previous menu.lst file will likely be backed up before replacement with the new menu.lst file with the boot options you selected in the automated wizard. Once you complete the 4 or 5 step process (depending on your configuration preference) simply reboot the system selecting the usb disk as your boot device and when the grub2 menu.lst loads with your boot options just type the letter "c" to enter the grub2 command interface. Now you can fully load and boot to portable grub2 environment.
additional screenshots posted here:
https://www.minds.com/groups/profile/924192575922864128
I hope this helps.
Best wishes,
Raoul
1
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
add a comment |
What I did is configure and install Hiren's boot cd to load on a usb flash drive with the automated grub loader from hiren.info once I had the bootable Hiren's usb drive I resized the primary partition on the hdd reducing one gb form the back end of the flash drive. Then I created an ext4 partition in the unallocated space. Next all I did is run grub2config command in xterm on RIPLinuX and the installation was relatively automated. The wizard allows you to select the partition and directory that grub2 is installed in. I set the loader to the mbr on the primary partition of the flash drive and the ext4 /boot/grub as the installation directory for the grub2 files.
What happens is the grub2 grldr replaces the previous grldr in the root directory of the primary partition on the flash drive. The previous menu.lst file will likely be backed up before replacement with the new menu.lst file with the boot options you selected in the automated wizard. Once you complete the 4 or 5 step process (depending on your configuration preference) simply reboot the system selecting the usb disk as your boot device and when the grub2 menu.lst loads with your boot options just type the letter "c" to enter the grub2 command interface. Now you can fully load and boot to portable grub2 environment.
additional screenshots posted here:
https://www.minds.com/groups/profile/924192575922864128
I hope this helps.
Best wishes,
Raoul
1
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
add a comment |
What I did is configure and install Hiren's boot cd to load on a usb flash drive with the automated grub loader from hiren.info once I had the bootable Hiren's usb drive I resized the primary partition on the hdd reducing one gb form the back end of the flash drive. Then I created an ext4 partition in the unallocated space. Next all I did is run grub2config command in xterm on RIPLinuX and the installation was relatively automated. The wizard allows you to select the partition and directory that grub2 is installed in. I set the loader to the mbr on the primary partition of the flash drive and the ext4 /boot/grub as the installation directory for the grub2 files.
What happens is the grub2 grldr replaces the previous grldr in the root directory of the primary partition on the flash drive. The previous menu.lst file will likely be backed up before replacement with the new menu.lst file with the boot options you selected in the automated wizard. Once you complete the 4 or 5 step process (depending on your configuration preference) simply reboot the system selecting the usb disk as your boot device and when the grub2 menu.lst loads with your boot options just type the letter "c" to enter the grub2 command interface. Now you can fully load and boot to portable grub2 environment.
additional screenshots posted here:
https://www.minds.com/groups/profile/924192575922864128
I hope this helps.
Best wishes,
Raoul
What I did is configure and install Hiren's boot cd to load on a usb flash drive with the automated grub loader from hiren.info once I had the bootable Hiren's usb drive I resized the primary partition on the hdd reducing one gb form the back end of the flash drive. Then I created an ext4 partition in the unallocated space. Next all I did is run grub2config command in xterm on RIPLinuX and the installation was relatively automated. The wizard allows you to select the partition and directory that grub2 is installed in. I set the loader to the mbr on the primary partition of the flash drive and the ext4 /boot/grub as the installation directory for the grub2 files.
What happens is the grub2 grldr replaces the previous grldr in the root directory of the primary partition on the flash drive. The previous menu.lst file will likely be backed up before replacement with the new menu.lst file with the boot options you selected in the automated wizard. Once you complete the 4 or 5 step process (depending on your configuration preference) simply reboot the system selecting the usb disk as your boot device and when the grub2 menu.lst loads with your boot options just type the letter "c" to enter the grub2 command interface. Now you can fully load and boot to portable grub2 environment.
additional screenshots posted here:
https://www.minds.com/groups/profile/924192575922864128
I hope this helps.
Best wishes,
Raoul
edited Dec 25 '18 at 10:16
answered Dec 25 '18 at 7:40
Raoul
11
11
1
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
add a comment |
1
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
1
1
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
You obviously put some effort into this, and we appreciate that. But I believe that you may have misunderstood the question. As far as I can make out, the OP is asking “How does this thing work?” (i.e., “How is it implemented?”), while you seem to be answering a “How do I do X?” question. Also, please capitalize the first word of each sentence and the word “I”.
– G-Man
Dec 25 '18 at 7:55
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
I see. No problem. Thanks!
– Raoul
Dec 25 '18 at 8:01
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
The question is about GRUB Legacy and not about GRUB2.
– fpmurphy
Dec 25 '18 at 17:57
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f259143%2fhow-does-grub-stage1-exactly-access-load-stage-2%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Have you zeroed out the existing file? Because deleting it is unlikely to remove the actual data that grub is referring to from the disc.
– Anthon
Jan 31 '16 at 13:03
Took the system back to original state. dd if=/dev/zero of=/boot/grub/stage2 bs=124k count=1. Verified that whole file had been zeroed. Rebooted. System still boots successfully.
– Zul K Irshad
Jan 31 '16 at 13:14
Comments are not for extended discussion; this conversation has been moved to chat.
– terdon♦
Feb 2 '16 at 10:58