STAGE1能不能直接引导放在文件系统中的STAGE2.txt
使用GRUB的困惑：STAGE1能不能直接引导放在文件系统中的STAGE2？
blocklist (hd0,1)/boot/grub/stage2
GRUB有几个重要的文件，STAGE1、STAGE1.5、STAGE2
STAGE1：它只有512字节，通常放在MBR中，它的作用很简单，就是在系统启动时用于装载STAGE2并将控制权交给它。
STAGE2：GRUB的核心，所有的功能都是由它实现。
STAGE1.5：
介于STAGE1和STAGE2之间，是它们的桥梁，因为STAGE2较大，通常都是放在一个文件系统当中的，但是STAGE1并不能识别文件系统格式，所以才需要STAGE1.5来引导位于某个文件系统当中的STAGE2。
根据文件系统格式的不同，STAGE1.5也需要相应的文件，如：e2fs_stage1_5，fat_stage1_5，分别用于识别ext和fat的文件系统格式。
引导顺序如下：STAGE1->;STAGE1.5->;STAGE2，由于STAGE1不能识别文件系统格式，所以STAGE1只能通过如： (HD0,0)1+22的格式来读取STAGE1.5。
例：在GRUB中执行：
root (hd0,0)
setup (hd0)
其实setup就是调用了install命令来安装GRUB到硬盘上的。
详细命令如：
embed /boot/grub/e2fs_stage1_5 (hd0)
install /boot/grub/stage1 (hd0) (hd0)1+22 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf
由上面的命令看出，stage1写进了(hd0)的MBR中，stage1.5写进了(hd0)MBR以后的22个扇区中（将stage1.5写进MBR 以后的扇区中，会不会影响正常的文件系统？不会，因为stage1.5较小，只占22个扇区，硬盘上第一个文件系统的开始扇区最小也只能从0柱面，1磁头，1扇区开始。就是说MBR所在磁头就只用到了1个扇区而已，按照现在硬盘的规格来说，一般一个磁头都有60+个扇区，所以这些扇区可以用来放 STAGE1.5，但是放STAGE2就不够了，所以只能将STAGE2放进文件系统中了），为了证明这一点，执行
dd if=/boot/grub/stage1 of=/dev/hda bs=512 count=1 seek=1，
将stage1写进原本是stage1.5的位置上。结果系统引导时屏幕上不停的出现GRUB，一直这样这样循环，看来这是对的。
硬盘搞清楚了后，就来弄软盘，以前见过有人说制作引导软盘的格式如下：
dd if=/boot/grub/stage1 of=/dev/fd0
dd if=/boot/grub/stage2 of=/dev/fd0 seek=1
自己试了一下，不能进行引导，猜一下可能是直接将STAGE1写进/dev/fd0的开始扇区不行，需要配置，
于是我又加了一步，就是在GRUB环境中执行:
install /boot/grub/stage1 (fd0) (fd0)1+255，
这一步会重写fd0并进行正确的配置，指示STAGE1读(fd0)1+255以后的扇区进行引导，255是写入STAGE2需要的扇区数。用这张软盘启动，成功。在这里没有用到STAGE1.5，因为STAGE2直接写进扇区，没有放在文件系统中。这样的引导软盘有个缺点，就是不能将它格式成任何文件系统，从而导致不能将kernel放进软盘中。
后来将软盘格式化成ext2格式，安装后发现不能正确从软盘引导，放在软盘上的STAGE2文件根本不能被识别。
难道GRUB不支持软盘为ext2格式？请高手赐教。
然后又将软盘格式化成vfat格式，将stage2拷贝到根目录下，在GRUB环境中执行：install /boot/grub/stage1 (fd0) (fd0)/stage2，这样可以进行引导，这里将STAGE2放在了文件系统中，但是并没有用到STAGE1.5，为什么也可以引导STAGE2呢？ 难道STAGE1支持vfat的文件格式？
现在又回到硬盘上吧，刚才我将stage1写进(hd,0)1+1中，也就是本应该放stage1.5的地方，启动时不停的循环出现GRUB，不能正常引导，后来用软盘引导进入后，在GRUB环境中执行：install (hd0,0)/boot/grub/stage1 (hd0) (hd0,0)/boot/grub/stage2，这里没有用到STAGE1.5，重新用硬盘引导，成功。why? 为什么 STAGE1可以读取ext2文件系统中的文件？
以上是我本人在使用GRUB时遇到的一些问题，希望高手给予解答。也希望大家都来更深入的了解GRUB。
使用GRUB的困惑：STAGE1能不能直接引导放在文件系统中的STAGE2？
怎么没有人顶呀，自己顶下。
飞行员舒克
第一、MBR中只有446字节可用来写入stage1
第二、dd if=/boot/grub/stage1 of=/dev/hda bs=512 count=1 seek=1
不是将stage1写进原本是stage1.5的位置上，刚说过stage1存储在MBR上，这里怎么又成了“stage1.5的位置”了，这样写入其实是把MBR全都给破坏掉了，包括分区表。屏幕上出现GRUB是因为stage1坏了，而不是stage1.5
++++++++++++++++++++++++++++++++++++
http://student.csdn.net/space.php?uid=48851&do=blog&id=8422
linux2.6.29 启动过程详细分析
2009-07-30 13:19
突然心血来潮，想自己写个模块，于是就把linux2.6.29的启动过程有分析了一下，整理出来和大家分享下。
linux的启动大体上可以分几个步骤：
第一部分 grub部分，内核的加载过程。
这里总结一下别人的思想，因为自己没怎么看过grub的源码。
1. Bios执行int 0x19，加载MBR至0x7c00并跳转执行,这个MBR在我们通常的系统中就是stage1.S(512B)， 位于磁盘的0面0道第一扇区，程序跳到0x7c00处执行
2. stage1执行过程中会加载磁盘0面0道第二扇区的512B的一段程序至0x8000处，就是grub源码里stage2/start.S，这里start.S是stage1_5或是stage2的总入口，它才是stage1_5或者stage2的真正加载器。
3. 在stage1_5加载之前，stage2是不可能被加载的，因为stage1并不能识别文件系统
stage1_5究竟被放在哪呢？很多兄弟可能以为它就是/boot/grub/底下的哪些xxfs_stage1_5文件，但试想一下，要找到boot
分区所在的stage1_5文件，那么就必须使得stage1具备文件系统识别功能，而stage1_5本身就是文件系统的支撑代码，它必须加载
stage1_5才能具备这种功能。那么，我们又回到了那种矛盾体的悖论──要加载stage1_5来找到stage1_5？ 呵呵。
所以用来识别boot分区文件系统的stage1_5不能作为文件来被stage1读取，
它只能被存放在固定的扇区中。这里强调"用来识别boot分区文件系统"，那是因为并不是所有的stage1_5文件都被放在固定扇区的，只有boot分
区的文件系统对应的stage1_5才会被放在固定的扇区中去！比如说，你的boot分区的文件系统是ext2，那么在安装GRUB的stage1的时
候，e2fs_stage1_5就会被存放至一个固定的扇区集，而其他的如reiserfs_stage1_5就依然作为文件来存放，以供GRUB使用
root()命令来识别其他的boot分区(那时候，stage2已经被加载了，所以这个不成问题)
最后得出结论，stage1.S被放在0面0道的第1扇区，start.S被放在0面0道的第2扇区，而与boot分区相关的文件系统的xxfs_stage1_5被放在0面0道第3扇区开始的扇区里，其占据的扇区数目与该stage1_5文件的大小有关。而其余的stage1_5以及stage2都作为文件被存放在boot分区里。
上面是摘自一位网友的，但是看grub后面的版本比如0.97,好像就不存在所谓的stage1_5了？？这是个疑问。
4. 讲完了stage1以及stage1_5的执行流程以及位置关系后，就轮到stage2这个大约110KB左右的mini OS了。stage2的入口是stage2/asm.S，asm.S在设置好c运行环境之后，会调用第一个c函数 init_bios_info（stage2/common.c），这个函数在执行一些底层的初始
化之后，会调用stage2的main函数cmain（stage2/stage2.c），这样stage2这个 mini os正式开始运行了！
针对menu.lst和shell这两种情况，cmain将：
menu.lst: run_menu()(stage2.c)->run_script()(cmdline.c)->find_command->执行命令函数
shell: enter_cmdline()(cmdline.c)->find_command->执行命令函数
殊途同归，最后都归结为命令行的解释执行
find_command（stage2/cmdline.c）按照menu.lst中或者shell用户输入的命令字符串，在一个全局性struct
builtin *builtin_table[](stage2/builtin.c)变量中去找到内置命令的函数，然后执行。
值得一提的是grub的shell类似bash的命令补全和命令历史纪录。
这里需要注意的是:stage2要现进入保护模式，把操作系统内核加载到内存，然后回到保护模式，把控制权交给内核。
第二部分 linux内核的启动
1. 内核会从header.S开始执行，具体为什么会从这里运行，在以后看完grub源码后会详细解释
+++++++++++++++++++++++++++++++++++++++++++++++++
http://blog.163.com/ecy_fu/blog/static/44451262008423101650945/
Grub是非常有意思的一个软件，汇编代码加上C，无敌了。
先看看硬盘的相关信息吧。
bash-3.2# /sbin/fdisk -l
Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x83009278
Device Boot Start End Blocks Id System
/dev/sda1 1 1255 10080756 83 Linux
/dev/sda2 * 1275 7951 53627904 6 FAT16
/dev/sda3 7951 14594 53357568 7 HPFS/NTFS
/dev/sda4 1256 1274 152617+ 5 Extended
/dev/sda5 1256 1274 152586 82 Linux swap / Solaris
这是一块120GB的硬盘，一共有四个分区，三个主分区，一个扩展分区，扩展分区内只有一个逻辑分区作为Linux的swap分区。两个主分区上硬盘分别安装了两个操作系统，为Fedora Core 8（第一个分区）和Windows Vista（第二个分区）。下面接着看下一些特殊扇区的数据吧。
#dd if=/dev/sda of=/home/ecy/s1.bin count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied，0.00024336 秒，2.1 MB/秒
打开s1.bin，内容如下：
[root@localhost ~]# hexdump -c /home/ecy/s1.bin
0000000: eb48 90d0 bc00 7c8e c08e d8be 007c bf00 .H....|......|..
0000010: 06b9 0002 fcf3 a450 681c 06cb fbb9 0400 .......Ph.......
0000020: bdbe 0780 7e00 007c 0b0f 8510 0183 c510 ....~..|........
0000030: e2f1 cd18 8856 0055 c646 1105 c646 0302 .....V.U.F...F..
0000040: 8000 0080 3f80 2701 0008 fa90 90f6 c280 ....?.'.........
0000050: 7502 b280 ea59 7c00 0031 c08e d88e d0bc u....Y|..1......
0000060: 0020 fba0 407c 3cff 7402 88c2 52be 7f7d . ..@|<.t...R..}
0000070: e834 01f6 c280 7454 b441 bbaa 55cd 135a .4....tT.A..U..Z
0000080: 5272 4981 fb55 aa75 43a0 417c 84c0 7505 RrI..U.uC.A|..u.
0000090: 83e1 0174 3766 8b4c 10be 057c c644 ff01 ...t7f.L...|.D..
00000a0: 668b 1e44 7cc7 0410 00c7 4402 0100 6689 f..D|.....D...f.
00000b0: 5c08 c744 0600 7066 31c0 8944 0466 8944 \..D..pf1..D.f.D
00000c0: 0cb4 42cd 1372 05bb 0070 eb7d b408 cd13 ..B..r...p.}....
00000d0: 730a f6c2 800f 84ea 00e9 8d00 be05 7cc6 s.............|.
00000e0: 44ff 0066 31c0 88f0 4066 8944 0431 d288 D..f1...@f.D.1..
00000f0: cac1 e202 88e8 88f4 4089 4408 31c0 88d0 ........@.D.1...
0000100: c0e8 0266 8904 66a1 447c 6631 d266 f734 ...f..f.D|f1.f.4
0000110: 8854 0a66 31d2 66f7 7404 8854 0b89 440c .T.f1.f.t..T..D.
0000120: 3b44 087d 3c8a 540d c0e2 068a 4c0a fec1 ;D.}<.T.....L...
0000130: 08d1 8a6c 0c5a 8a74 0bbb 0070 8ec3 31db ...l.Z.t...p..1.
0000140: b801 02cd 1372 2a8c c38e 0648 7c60 1eb9 .....r*....H|`..
0000150: 0001 8edb 31f6 31ff fcf3 a51f 61ff 2642 ....1.1.....a.&B
0000160: 7cbe 857d e840 00eb 0ebe 8a7d e838 00eb |..}.@.....}.8..
0000170: 06be 947d e830 00be 997d e82a 00eb fe47 ...}.0...}.*...G
0000180: 5255 4220 0047 656f 6d00 4861 7264 2044 RUB .Geom.Hard D
0000190: 6973 6b00 5265 6164 0020 4572 726f 7200 isk.Read. Error.
00001a0: bb01 00b4 0ecd 10ac 3c00 75f4 c300 0000 ........<.u.....
00001b0: 0000 0000 0000 0000 7892 0083 0000 0001 ........x.......
00001c0: 0100 83fe ffff 3f00 0000 e8a3 3301 80fe ......?.....3...
00001d0: ffff 06fe ffff 0050 3801 0098 6406 00fe .......P8...d...
00001e0: ffff 07fe ffff 00e8 9c07 0058 5c06 00fe ...........X\...
00001f0: ffff 05fe ffff 27a4 3301 53a8 0400 55aa ......'.3.S...U.
一共32行，每行16个字节，32X16＝512个字节，这便是保存MBR里面的数据，Grub的stage1便是放在这里的，最后的66个字节为硬盘分区表和分区表结束标志55aa，分区表中包含的四项记录是：
0000 0100 83fe ffff 3f00 0000 e8a3 3301
80fe ffff 06fe ffff 0050 3801 0098 6406
00fe ffff 07fe ffff 00e8 9c07 0058 5c06
00fe ffff 05fe ffff 27a4 3301 53a8 0400
我们来分析第一条记录吧，将这个数字按照逻辑关系排列好。
00 00 0100 83 fe ffff 3f000000 e8a33301
1 2 3 4 5 6 7 8
1：分区状态，0x80为激活分区，0x00为未激活分区
2：分区起始磁头号
3：分区起始扇区和柱面号
4：分区类型，0x83为Linux文件系统，0x0B为FAT32文件系统，0x07为NTFS文件系统，这里是0x06，即FAT16文件系统，呵呵，有点奇怪啊，C盘明明是NTFS格式的。
5：分区结束磁头，仅仅一个单片的硬盘，不知怎么会有这么多的磁头，这个问题困扰我好久了。
6：分区结束扇区和柱面号
7：在线性寻址方式下的分区相对扇区地址
8：分区大小。注意x86 CPU使用的Little endian，所以顺序要反过来，即0133a3e8，转化为十进制就是20161512，这就是这个分区的逻辑扇区总数，每个扇区大小为512bytes，所以分区大小为9.84GB。
#dd if=/dev/sda of=/home/ecy/s2.bin skip=1 count=1 bs=512
[root@localhost ~]# hexdump -c /home/ecy/s2.bin
0000000: 5256 be03 21e8 2a01 5ebf f821 668b 2d83 RV..!.*.^..!f.-.
0000010: 7d04 000f 84ca 0080 7cff 0074 3e66 8b1d }.......|..t>f..
0000020: 6631 c0b0 7f39 4504 7f03 8b45 0429 4504 f1...9E....E.)E.
0000030: 6601 05c7 0410 0089 4402 6689 5c08 c744 f.......D.f.\..D
0000040: 0600 7050 6631 c089 4404 6689 440c b442 ..pPf1..D.f.D..B
0000050: cd13 0f82 9f00 bb00 70eb 5666 8b05 6631 ........p.Vf..f1
0000060: d266 f734 8854 0a66 31d2 66f7 7404 8854 .f.4.T.f1.f.t..T
0000070: 0b89 440c 3b44 087d 748b 042a 440a 3945 ..D.;D.}t..*D.9E
0000080: 047f 038b 4504 2945 0466 0105 8a54 0dc0 ....E.)E.f...T..
0000090: e206 8a4c 0afe c108 d18a 6c0c 5a52 8a74 ...L......l.ZR.t
00000a0: 0b50 bb00 708e c331 dbb4 02cd 1372 468c .P..p..1.....rF.
00000b0: c38e 4506 58c1 e005 0145 0660 1ec1 e004 ..E.X....E.`....
00000c0: 89c1 31ff 31f6 8edb fcf3 a41f be14 21e8 ..1.1.........!.
00000d0: 6000 6183 7d04 000f 853c ff83 ef08 e92e `.a.}....<......
00000e0: ffbe 1621 e84b 005a ea00 2200 00be 1921 ...!.K.Z.."....!
00000f0: e83f 00eb 06be 1e21 e837 00be 2321 e831 .?.....!.7..#!.1
0000100: 00eb fe4c 6f61 6469 6e67 2073 7461 6765 ...Loading stage
0000110: 312e 3500 2e00 0d0a 0047 656f 6d00 5265 1.5......Geom.Re
0000120: 6164 0020 4572 726f 7200 bb01 00b4 0ecd ad. Error.......
0000130: 1046 8a04 3c00 75f2 c300 0000 0000 0000 .F..<.u.........
0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001f0: 0000 0000 0000 0000 0200 0000 1300 2002 ...............
如果将grub目录下的所有stage1_5文件都删除掉，系统照样能正常启动，这说明stage1_5的位置放在0磁道中
一般的stage1_5大小只有10K左右，要占用20个扇区，它是完全可以放在0磁道上的。stage2就不一样了，它的大小有100多k，这个块头可就放不进0扇区了，所以将stage2删除，系统是不能正常启动的。因为我的安装系统的时候主分区是ext3文件系统，所以接下来的代码应该就是 e2fs_stage1_5的。
#dd if=/dev/sda of=/home/ecy/s2.bin skip=2 count=1 bs=512
[root@localhost ~]# hexdump -c /home/ecy/s2.bin
0000000: ea70 2200 0000 0302 ffff ff00 0000 0000 .p".............
0000010: 0200 302e 3937 00ff ff00 ff2f 626f 6f74 ..0.97...../boot
0000020: 2f67 7275 622f 7374 6167 6532 202f 626f /grub/stage2 /bo
0000030: 6f74 2f67 7275 622f 6772 7562 2e63 6f6e ot/grub/grub.con
0000040: 6600 0000 0000 0000 0000 0000 0000 0000 f...............
0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000070: fa31 c08e d88e d08e c067 6689 2dfc 2400 .1.......gf.-.$.
0000080: 0066 bdf0 1f00 0066 89ec fb67 8815 f824 .f.....f...g...$
0000090: 0000 cd13 66e8 6100 0000 bfa0 3f00 00b9 ....f.a.....?...
00000a0: 7c40 0000 29f9 30c0 fcf3 aae8 9802 0000 |@..).0.........
00000b0: e88c 0000 00f4 e9fa ffff ff8b 4424 08a3 ............D$..
00000c0: 0025 0000 89c3 668b 4424 0466 a304 2500 .%....f.D$.f..%.
00000d0: 00c1 e004 01c3 a178 4000 0089 8308 0000 .......x@.......
00000e0: 008a 1590 3f00 008b 4c24 0ce8 5100 0000 ....?...L$..Q...
00000f0: 6689 cd67 66ff 2d00 2500 00fa 6766 0f01 f..gf.-.%...gf..
0000100: 1540 2500 000f 20c0 6683 c801 0f22 c066 .@%... .f....".f
0000110: ea17 2300 0008 0066 b810 008e d88e c08e ..#....f........
0000120: e08e e88e d08b 0424 a3f0 1f00 00a1 f424 .......$.......$
0000130: 0000 89c4 89c5 a1f0 1f00 0089 0424 31c0 .............$1.
0000140: c30f 0115 4025 0000 89e0 a3f4 2400 008b ....@%......$...
0000150: 0424 a3f0 1f00 00b8 f01f 0000 89c4 89c5 .$..............
0000160: 66b8 2000 8ed8 8ec0 8ee0 8ee8 8ed0 ea75 f. ............u
0000170: 2300 0018 000f 20c0 6683 e0fe 0f22 c066 #..... .f....".f
0000180: ea87 2300 0000 0066 31c0 8ed8 8ec0 8ee0 ..#....f1.......
0000190: 8ee8 8ed0 fb66 c355 89e5 5653 8b45 1066 .....f.U..VS.E.f
00001a0: 89c6 6631 c0c1 e804 6689 c18a 550c 668b ..f1....f...U.f.
00001b0: 5d08 e88a ffff ff89 d88e d9cd 1388 e231 ]..............1
00001c0: c08e d866 e832 ffff ff88 d05b 5e5d c355 ...f.2.....[^].U
00001d0: 89e5 5357 568b 4510 88c5 8a45 18c0 e002 ..SWV.E....E....
00001e0: 66c1 e802 88c1 8a75 148a 550c 668b 5d20 f......u..U.f.]
00001f0: 8a65 088a 451c 6689 c7e8 43ff ffff 8ec3 .e..E.f...C.....
[root@ecy grub]# ls -l | grep e2fs*
-rw-r--r-- 1 root root 11768 06-03 23:57 e2fs_stage1_5
（11768+512）/ 512 = 23.98
由此可以预测25个扇区肯定是一个空的扇区。使用dd命令（skip=24）将这个扇区的内容拷贝出来，用vi的二进制模式打开能看见全是0。事实有点出乎我的意料，事实上stage1_5结束在第21（skip=20）个扇区，查看这个扇区的内容，发现有一下字符串，“GRUB loading, please wait.....”，这便是我们在显示器上能够看到的提示信息。再往后的扇区就都是全0了。
[root@localhost ~]# hexdump -c
00000a0: 6572 6673 000a 0a47 5255 4220 6c6f 6164 erfs...GRUB load
00000b0: 696e 672c 2070 6c65 6173 6520 7761 6974 ing, please wait
00000c0: 2e2e 2e0a 0069 6e74 6572 6e61 6c20 6572 .....internal er
00000d0: 726f 723a 2074 6865 2073 6563 6f6e 6420 ror: the second
00000e0: 7365 6374 6f72 206f 6620 5374 6167 6520 sector of Stage
00000f0: 3220 6973 2075 6e6b 6e6f 776e 2e00 5265 2 is unknown..Re
stage2保存在哪里呢？？
在网上查资料，看到这样一句话：
grub的boot是这样的：
一般来说它由stage1 stage2 组成
stage1存在mbr中，stage2存在于文件系统之中
如果stage2在文件系统中由很连续的块组成的，那么stage1将通过blocklist直接load stage2(不通过文件系统)，否则通过加载stage1.5(被存贮在mbr后的磁盘扇区中)，由stage1.5通过文件系统加载stage2。
这段话说明，stage2被加载有两个方法，一是使用stage1.5加载相关的驱动然后在从文件系统中读取stage2；另外一种是stage1通过blocklist直接加载stage2。
[root@ecy grub]# ls -li stage2
1695760 -rw-r--r-- 1 root root 110532 06-05 23:09 stage2
[root@ecy grub]# /sbin/debugfs /dev/sda1
debugfs 1.40.8 (13-Mar-2008)
debugfs: stat <1695760>
Inode: 1695760 Type: regular Mode: 0644 Flags: 0x0 Generation: 2545743768
User: 0 Group: 0 Size: 110532
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 224
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x484801c7 -- Thu Jun 5 23:09:59 2008
atime: 0x484946c6 -- Fri Jun 6 22:16:38 2008
mtime: 0x484801c7 -- Thu Jun 5 23:09:59 2008
Size of extra inode fields: 4
Extended attributes stored in inode body:
selinux = "system_u:object_r:boot_t:s0\000" (28)
BLOCKS:
(0-11):6791168-6791179, (IND):6791180, (12-26):6791181-6791195
TOTAL: 28
由上面的信息可知stage2放在第6791168块中，我的ext3文件系统block默认大小为4096B，因此一个快组一共有32768个block，，这个6791168排到了第207个块组了（25.9GB），好远的位置啊~
1. 如果使用stage1_5 ->stage 2 的方式， 首先监测是否是合适的fs的驱动，如果是就使用fs逻辑的方式找stage2 , 找不到就用blocklist的方式再找，找到了挂起来，找不到报错。
2. 如果是确认没有stage1_5， stage1 就回试图使用记录的stage2的blocklist找stage2,一样找到了挂起来，找不到报错。
3. 既使用fs逻辑方式，又使用blocklist方式的好处是防止被误删或是改名！
没敢做实验删除stage2，嗯，删除stage2后立即重启，在逻辑上来看系统应该还能被启动的，因为此时stage2所在的块没有被覆盖掉，stage1通过blocklist=仍然能找到这个stage2，如果这个块被别的文件覆盖了的话，那么系统将再也启动不起来了。
似乎默认情况下是通过stage1.5来加载stage2的，那么既然可以使用blocklist，那么为什么还要使用stage1.5呢？有一个细节要注意，按照系统的时候grub是最后安装的，或者按照在MBR，或者安装在一个分区，这个时候stage2的block位置已经确定了。
grub> blocklist (hd0,0)/boot/grub/stage2
blocklist (hd0,0)/boot/grub/stage2
(hd0,0)54329344+154329346+154329348+154329350+154329352+154329354+154329356+154329358+15
4329360+154329362+154329364+154329366+154329368+154329370+154329372+1543……
乍一看，这里stage2的开始块号同使用stat显示的不一样，其实不然，这里的块号是对硬盘的物理扇区的块号，一个块的大小为512B，而上面的块号是文件系统的块号，它的大小为4KB，所以又这样的换算关系：
6791168 X 8 ＝ 54329344 OK， Very Good~
（4K / 512B = 8）
我要分析一下stage1的构成。
