标题: WinGrub的问题 [打印本页]
作者: waffle 时间: 2005-1-9 00:00 标题: WinGrub的问题
我把Grub装在了u盘的启动扇区上，grldr放u盘根上，menu.lst放u盘/grub目录下。但是启动的时候老说找不到menu.lst，进grub控制台，root一看u盘被当成了fd0,照理说应该找得到menu.lst。从控制台能进其他系统。后来在(hd0,0)上放了个menu.lst马上找到了。请问是什么原因？
作者: zdq789 时间: 2005-1-9 00:00
我也有同样的问题，我是把u盘格式化为zip模式，用它启动电脑，在dos下运行grub，可以读出硬盘的menu文件，却读不出u盘上的menu！ 而且我还无法把grub装入u盘的mbr，grub能够root出fd（0），但读不出u盘里的stage文件! 但我觉得，你既然能把归入把写入u盘，那grub应该可以读出u盘里的stage，也应该可以读出menu啊！ 我是这样做的，root （fd0） setup （fd0）然后提示找不到stage文件，但文件确实存在！你是怎样把grub写入u盘的呢？请教？
作者: waffle 时间: 2005-1-10 00:00
我的u盘好像只能USB-ZIP启动，FAT16格式，我发现用这种方式启动的时候主板不会理会u盘的扇区0(MBR),而是直接读引导扇区（扇区32），和软盘启动类似。我没有直接在物理机器上装wingrub,而是在虚拟机上的win98装了wingrub,然后把grub装在一个软盘上（实际用的是物理机上的一个软盘镜像），并且把虚拟机里硬盘上的menu.lst删除了，在虚拟机里用软盘启动能从软盘读到menu.lst,一切正常。再把这个软盘的启动扇区（也就是物理机上软盘镜像的第一个扇区）写到u盘的启动扇区（但要保留原本u盘启动扇区的BPB）。
作者: waffle 时间: 2005-1-12 00:00
又发现个问题，如果用别的格式化工具格式化u盘，GRLDR非但不能找到menu.lst,连cat (fd0)/+TAB都会说没有找到文件。如果用win98的format,也不能找到menu.lst,但是cat (fd0)/+TAB会出来乱码，u盘上找不到文件可能和格式化工具有密切关系。出现乱码表示什么，目录被破坏还是怎么了，在windows系统里可是能正常看到文件的。
作者: 不点 时间: 2005-1-12 00:00
可惜我的机器太旧，不支持 USB 启动。猜想原因应该在 BIOS 上。
作者: waffle 时间: 2005-1-12 00:00
感觉好像不是BIOS的问题，因为同样的机器和u盘，做成USB-ZIP启动方式的Dos启动盘就一切正常，就跟真的软驱一样，也是用盘符A:。
作者: 不点 时间: 2005-1-13 00:00
似乎与 GRUB4DOS 无关。
那么，问题可能是 GNU GRUB 的软盘处理部分有 BUG 了。我们大家都可以研究一下 GNU GRUB 的源代码，尤其是 asm.S 中有关软盘的处理。
另外，将 USB 仿真为硬盘(USB-HDD)时，出现不出现问题呢？问题都搜集起来，或许能提示我们 BUG 在哪。
作者: 不点 时间: 2005-1-13 00:00
请研究这条消息，看是否有用：
http://lists.gnu.org/archive/html/bug-grub/2004-11/msg00035.html
作者: 不点 时间: 2005-1-13 00:00
在上述 http://lists.gnu.org/archive/html/bug-grub/2004-11/msg00035.html 的情况下，用
map (fd1) (hd?)
应当就可以了。也就是，把 (fd1) 当作硬盘 (hd?)，其中 ? 是一个你认为空闲的硬盘号码，比如用 0 就行。
作者: 不点 时间: 2005-1-13 00:00
补充：
需要再用一条
map --hook
以便你在 grub 下使用硬盘 (hd?) 中的分区和文件。
该“硬盘” 上的文件应当是类似如下的表示法：
(hd?,0) ------------- 第一主分区
(hd?,1) ------------- 第二主分区
(hd?,2) ------------- 第三主分区
(hd?,3) ------------- 第四主分区
(hd?,5) ------------- 第一扩展分区
......................................
作者: 不点 时间: 2005-1-13 00:00
另外一点提示，或许有用：
如果你能获得 GRUB> 的提示符，在提示符下敲入
root (
也就是 root，一个空格，一个左括号，然后按键盘上的 TAB 制表键，那么，GRUB 将列出 GRUB 所识别到的系统中全部磁盘的号码。
你看看有没有多余的，如果有的话，那么那个多余的磁盘号码，可能就是你的 USB 盘了。如此，你就可以找到 USB 盘上的所有文件了。
作者: waffle 时间: 2005-1-13 00:00
USB-HDD方式没法启动，据说一般的u盘是可以在USB-ZIP和USB-HDD两种方式之间切换的，但这种切换只有用厂商发布的专用软件才能完成，遗憾的是我这个u盘没有厂家的专用软件。我的u盘128M,全部容量只分了个主分区，FAT16格式。现在是以USB-ZIP方式启动的，grldr是能加载的，但是它不认u盘上的其他文件。root (+TAB的结果是Grub列出了fd0,hd0,hd1,这符合情况，我机器上是有2块硬盘和1个u盘，u盘被认做了fd0。关于map命令，我总觉得用fd0去map个硬盘似乎不妥当，因为既然系统把u盘认成了fd0，那么就会按照软盘的规范来操作了，而软盘是没有分区的概念的，硬盘又是有分区概念的。然后我map (fd0) (fd2)map --hook然后root (+TAB看到fd0,hd0,hd1,hd2root (hd2,0)结果报错error 19:selected cylinder exceeds maximum supported by BIOS
作者: 不点 时间: 2005-1-14 00:00
为什么不这样呢：
map (fd0) (hd2)
map --hook
然后root (+TAB看到fd0,hd0,hd1,hd2然后root (hd2,+TAB
(此处显示hd2中的全部分区信息)
作者: 不点 时间: 2005-1-14 00:00
不过你贴出的错误信息很能说明问题。基本可以断定，错误仍然属于 BIOS 的。
情况可能是这样的：BIOS 虽然实现了 USB 的扇区读写(int13/ah=02和03)，但还有某些功能没有实现，比如 int13/ah=08h，或者 int13/ah=15h，或者这些功能实现得不正确，有错误。这些将直接导致 GRUB 不能承认该实现。
但是，缺少这些实现，又可以使得 DOS 能够正常启动，这就给人一个假象，使得我们误认为 GRUB 有 BUG。
那些写这段 BIOS 程序的人，他们只测试 DOS 能够启动就完事了，其实这里面潜藏着问题的。GRUB 不能正常识别它，这就是一个表现。如果你足够多地测试其它 DOS 软件，你还会发现还有别的程序无法运行，或者得到莫名其妙的结果。
作者: waffle 时间: 2005-1-14 00:00
map (fd0) (hd2)
map --hook
root (hd2,+TAB然后出来3个错，分区0，error 19:selected cylinder exceeds maximum supported by BIOS;分区1,error 19:selected cylinder exceeds maximum supported by BIOS分区3，error 19:selected cylinder exceeds maximum supported by BIOS不知道为什么没有分区2。grub把软盘map成硬盘的根据是什么，软盘没有分区这个概念，grub从哪里搞个分区表出来呢？有什么dos软件可以用到你说的那些bios功能？
作者: 不点 时间: 2005-1-14 00:00
你的软盘没有分区表吗？那你上面为什么提到 MBR？如果软盘上没有分区表，它的第一扇区不应叫做 MBR，而是叫做 DBR。
至于说什么软件需要 int13 的全部功能，我也没有研究过，在你的这个 bios 上究竟哪个功能实现得有问题，也不清楚，你自己可以研究一下 int13 规范，检察一下你的这个 BIOS 在哪一部分出现了错误。不过这个检查比较繁琐，一般来说需要用到汇编语言。
如果你的 BIOS 的 int13 没有毛病的话，你无法解释 grub 不能正常识别 (fd0) 这个问题。grub 识别磁盘号码，只与int 13 有关，与其它的都无关。grub 不可能在此处存在BUG(如果有的话，10年前就会被人发现和解决的，因为这里都太基本了，都是基本的 int13 调用，严格按照规范来的)。
作者: waffle 时间: 2005-1-14 00:00
只要进入OS后u盘就会被模拟成某一存储设备，比如在win2000下整个u盘看起来象是个硬盘，可以分区、格式化，在linux下会模拟成个SCSI设备sda,操作起来也和硬盘一样，在这两种OS中u盘的扇区0上的分区表会被系统识别。于是我在win2000下把u盘分一个区。现在由于我是用USB-ZIP模式启动，主板BIOS只会从扇区32（DBR）开始读，而不去理会扇区0(MBR)里的分区表！我曾经做了个dos启动盘，并把u盘的扇区0里的分区表都清零，此时在win2000下会认为这个u盘没有分区、格式化，但用它以USB-ZIP方式启动系统是成功的，盘里的数据还都能正常存取。也就是说主板BIOS把这个128M的u盘完全当个大容量软盘来操作了，而不会去理会u盘扇区0的分区表。我想不通的是：对一个普通的1.44m软盘来说，它根本没有分区表这个概念，如果map (fd0) (hd?)，那hd?上面的分区表又从何而来呢？现在的情况是在grub提示符下root (+TAB,出来了fd0,应该说grub也把u盘当成了软盘，而dos启动盘启动最后也是出来a:,说明两者对u盘的识别是一致的（是否也说明int 13中对u盘的识别功能是正确的？如果grub没有正确识别出u盘，root (+TAB会出现fd0吗？能否设定让grldr把执行期间的信息都显示在屏幕上或保存在文件里？）。接下来就是对u盘上文件的存取，dos是正常的。而DBR中的GRUB引导代码能在u盘上找到grldr并加载，似乎也说明读写扇区的功能是正常的。另外我的BIOS是AWARD 6.0PG,很多主板用这个BIOS的，而且出来的时间也满长了，如果int 13出现问题的话应该也早就发现了。我觉得一个可能的地方是grldr对fd0的理解，如果当 grldr调用int 13发现u盘是fd0,它可能采用两种方法来定位FAT、根目录和数据区的位置，一种是比较通用的，从DBR的BPB中获得参数并计算，还有一种grldr认为fd0就是纯粹的软盘，FAT、根目录、数据区的位置是固定的，就直接在代码里按照固定的位置去找。另外请教不点DX,一般在DBR中的代码是如何去找它想要的文件的，比如grub引导代码是如何找到grldr,dos引导代码又是如何找到那3个启动文件的？
作者: 不点 时间: 2005-1-14 00:00
> 我想不通的是：对一个普通的1.44m软盘来说，它根本没有分区表这个概念，如果map (fd0) (hd?)，那hd?上面的分区表又从何而来呢？
这个问题你已经提到多次了，我不一定能答复好，但尽最大努力吧:-)
软盘没有分区，硬盘有分区，这其实是一个历史遗留的问题。历史上，由于软盘小，所以，就弄成一个文件系统，以免 MBR占用多余的空间。(那时候，空间是很节约的，甚至FAT都只用12位的，也就是“一个半”的字节，可见空间是多么紧张了。)而硬盘由于容量大，就被分成不同的文件系统区域了，这叫做分区。分区究竟是微软创造的呢？还是在微软之前就有了标准，这个我不太清楚。但是有一点很明确，那就是，这已经形成了事实工业标准：软盘无分区，硬盘有分区，并且分区的格式是大家都了解的，完全没有秘密的。
另一方面，在逻辑上讲，软盘和硬盘都是 BIOS 的磁盘号码，都有统一的 BIOS 接口。BIOS并不了解硬盘上还有分区这个东西，它处理硬盘和软盘的方式是完全一样的，分区是由操作系统认定和解释的，BIOS不知道这些。因此，逻辑上，软盘确实可以有分区，关键是，只要操作系统能够承认它就行。
然而你的这个 BIOS 却跳过 U盘的第一扇区，直接用 DBR 来引导，这是违反从前的事实工业标准的。(我不知道是否还有另外的标准，允许 BIOS 从 DBR 引导，如果我说错了，请知道的人不吝赐教。)
不管怎么说，你的 BIOS 能够引导 U盘，也是一个优点。它试图在旧的标准和新的实际应用之间找到平衡。旧的标准是说，软盘不能有分区；新的应用是指，它又想把含有分区表的 U盘当作软盘来用。这是矛盾的。因此，它选择了跳过分区表，直接引导 DBR。是的，DBR 之后和软盘是一样的格式，都是DBR+FAT+ROOT_DIR+DATA_AREA。因此，它这种方法有它可行的一面。但问题是，有些东西它并没有完全照顾到，或者说没有考虑到，或者说是忽视了。在我的机器上，CDROM的软盘仿真就出现了类似的错误。CDROM也是用一个连续的扇区序列来仿真软盘的启动，这一点和你的 U盘完全相同。我的机器 也是 AWARD 的代码，估计写这个程序的人在 U 盘上也犯了同样的错误，那就是int13实现得不完整，残缺不全。我的机器上是 int13/ah=8 没有实现，导致 grub 认不出 cdrom 上的软盘。
作者: 不点 时间: 2005-1-14 00:00
grub 能 root (+TAB 出 fd0，并不表明 fd0 已经完全无问题。它能看到 fd0盘符，这是肯定的了(比如测试int13/ah=0的返回结果)，但是，当 GRUB 进一步试图去确定 fd0的磁道数/扇区数/面数/总扇区数等等这些规格参数(int13/ah=8以及ah=15h)的时候，失败了。这样，GRUB就拒绝承认该磁盘上的数据。也就是说，这个盘存在，但不可用，恰如你的软驱存在，但里面没有软盘，或者软盘彻底坏掉了那样。
至于说 DBR 的代码能够找到 IO.SYS 以及GRLDR，那是因为这些程序可能没有用到那些调用(例如int13/ah=8以及15h)。然而 GRUB在接管控制之后却需要这些调用，确保磁盘的各项规格数据都是准确的，这样做是必须的，也是安全的，它对于不合乎规范的磁盘不给予承认，这样，你就不至于毁坏该磁盘设备上的扇区，不管是有意还是无意的。注意 GRUB 的 setup命令会写入磁盘，这对于那些没有确切规格的磁盘(或者规格数据不完整的磁盘)来说，将是灾难性的。因此 GRUB 对 BIOS的严格要求是合理的，不能满足 GRUB 的要求，那是 BIOS 的 BUG，这毫无疑问。(以上说的这些都是 GNU GRUB 的功能，不是GRLDR 特有的。)
就你的这个问题而言，如果和我上述猜想是一致的话，那还是有办法解救的。你可以试试 以下这些命令之一：
map (fd0)+262144 (fd0)
map (fd0)+262144 (fd1)
map (fd0)+262144 (hd2)
然后用 map --hook ，之后再看看U盘文件系统是否正常了(分别是：fd0,fd1,hd2)。
上面的 262144 其实表示 128M 的意思，你觉得太大了，可以减小一些，因为如果太大了，读尾部的扇区时要出错。你应当填入你的 fd0 的总扇区数，也就是从 BPB 表所确定的总扇区数。
不出意外的话，应当成功。
作者: 不点 时间: 2005-1-15 00:00
又仔细考虑了一下，觉得你可以试试以下简单的办法：
map (fd0)+1 (fd0)
map --hook
如此就可以访问你的 (fd0) 中的文件了。万一不行，你再试试下面这个：
map (fd0)+1 (fd1)
map --hook
这样你应当可以访问 (fd1) 中的文件了。
作者: waffle 时间: 2005-1-15 00:00
map (fd0)+262144 (hd2)
系统不认这个参数，help map也没看到有这样的参数。“stage1 encodes the location of Stage 2 (or Stage 1.5) in a block list format”这句话是什么意思？
作者: 不点 时间: 2005-1-15 00:00
你没有贴出出错信息。
(fd0)+1 以及 (fd0)+262144 都是表示一个文件(A_FILE)。我说过，用 262144 是不合适的，你需要用一个合适的值。如果你懒得计算的话，试试用 1 应当也可以，幸运的话。
map A_FILE (fd0)
这种用法并不特殊，这没有任何参数。在 map 和 A_FILE 之间，以及 A_FILE 和 (fd0) 之间，各有一个空格。如果你的 GRLDR 版本不太旧，应当完全支持这个用法。你也可以自己找一个最新的拷贝到软盘根目录，没问题的。
注意 (fd0)+1 表示一个文件，它中间不可以插入空格或者别的字符。中间的加号是有的，不能把 + 号漏掉。
作者: 不点 时间: 2005-1-15 00:00
GRLDR 完全不采用 stage1 以及 stage1.5, 也不采用 stage2 文件。所以，不必理会那句话的意思。
那句话是
说，stage1 这个启动扇区中含有 定位 stage1.5 或者 stage2 文件的信息。信息用“块列表”的格式在stage1
的扇区中存放。所谓的“块列表”，就是指扇区位置列表。所以，一旦 stage1.5 或者
stage2的物理扇区位置发生了变化，比如说经过了磁盘碎块整理之后，那么 stage2 将无法被引导，导致系统在引导时死机。
GRLDR
不存在这个问题，完全脱离了那些复杂的 stage 's ，直接用微软的方式寻找 GRLDR
文件，这是万无一失的。我们知道微软的引导扇区代码查找 IO.SYS 就是这样的，不管怎么整理碎块，只要 IO.SYS
这个文件存在，总能引导成功，从来不会失败的。
[此贴子已经被作者于2005-1-15 11:13:26编辑过]
作者: waffle 时间: 2005-1-15 00:00
试了一下，map (fd0)+1 (hd2)显示:FAT16 BPB found with starting 0xEB(jmp) confirmationProbed C/H/S=117/64/32,probed total sectors=240943（这个和BPB里的信息一致）然后map --hook但是root (hd2)的时候死机(fd0)+1这里的+1和chainloader里的+1是一样的意思，表示fd0的第一个扇区吗？如果改成+240943会报Attempt to access black out side partitionhd2换fd1也是一样死机。还发现个问题，刚启动到grub提示符下的时候，root，显示fd0是ntfs,而不象前几天那样显示fat，于是我root (+回车，这时候又显示fd0是fat了。
作者: 不点 时间: 2005-1-15 00:00
有两个问题你没有说清楚：
1. 用 map (fd0)+1 (fd0) 以及 map --hook 之后，你是否可以访问 (fd0) 中的文件了。这很重要，如果失败了，再说其它的就没有意义了，我们估计没有很好的办法了。
2. 你的 BPB 显然有矛盾，我计算了一下， 117 × 64 × 32 = 239616，这才是总扇区数，而你的 BPB 中竟然有 240943 这个数，显然是不对的。
要么你修改 BPB 中的 240943 为 239616，要么你用：
map (fd0)+239616 (fd0)
map --hook
差不多可以肯定，这样应当成功了。
=============
另外，用 (hd2) 是错误的，因为你的 (fd0) 含有分区表，也就是说，你的 (fd0) 的第一扇区是 DBR，不是 MBR。你的 U盘最开头的 32 个扇区是不可访问的，BIOS 已经阻止了你的访问权。
你也不可以用 (fd1)，因为根据上面所说的事实工业标准，可以用做启动盘的，只有 (fd0) 和 (hd0)，其它的诸如 (fd1) (hd1) (hd2) 等等这些，都不可以作为启动盘。
===============
你的 (fd0) 是 fat16 格式的，正如 map 命令的探测报告所说的那样，肯定不是 NTFS 的。
===================
map (fd0)+1 (fd0)
此处的 (fd0)+1 不是指 (fd0) 的第一扇区，而是指 (fd0) 上的全部扇区，也就是 (fd0)+240943
因此，当你把 240943 纠正为正确的 239616 之后，你就可以用简单的 (fd0)+1 来处理这一情况了。
(fd0)+1 代表 (fd0) 上的全部扇区，这一点是特殊的，只在 map 的磁盘仿真命令中有效，在 GNU GRUB 的其它场合无效，也就是说，这是 GRUB for DOS 对此所做的特殊解释。
在 map 命令行之外的场合，(fd0)+1 仍然只表示 (fd0) 上的第一扇区。
作者: waffle 时间: 2005-1-15 00:00
把BPB中的扇区数改了又试了下map (fd0)+X (fd?)。当X=1,map命令显示FAT16 BPB found with starting 0xEB(jmp) confirmation，Probed C/H/S=117/64/32,probed total sectors=239616，然后map --hook,但接着root成fd?必定死机。当1<X<=2880能使命令成功,成功显示Auto detect number-of-heads failed,Use default value 2.Auto detect sectors-per-track failed,Use default value 18.然后root成fd?,还是死机。当X>2880,显示error 15,Attempt to access block outside partition.
作者: 不点 时间: 2005-1-15 00:00
从 X > 2880 出错可见，你的 BIOS 可能仅仅支持 1.44M 的启动软盘罢了。超过 1.44M 去读取的话，它就可能死机。
你这里出现了很多的“死机”，动不动就死了。死机的原因，不在 GRUB，而在于 BIOS。这类操作，GRUB 都是利用 int13 调用，最终调用的是 ROM 里的 BIOS 程序。正是 ROM BIOS 编制得粗糙，才造成动不动就死机。
你把 BPB 改成 1.44M 的软盘映象(当然需要重新格式化它)，再试试这个操作方法，看看能否躲过 BIOS 的 BUG。
我估计这可能是你的主板 BIOS 的限制，可能人家要求是 1.44M 的，你可能忘了看看主板的说明书。
作者: waffle 时间: 2005-1-15 00:00
感觉BIOS对启动盘应该没有1.44M的限制，我给u盘格式化后，先拷进去一些数据，然后把dos系统文件拷进去，确信那3个启动文件都在1.44M以外。去启动系统，一切正常，随便新建个文件也是在1.44M以后的扇区。前面说到的map (fd0)+2880 (fd0)的时候Auto detect number-of-heads failed,Use default value 2，那么grub是如何实现自动检测磁头数和每磁道扇区数的呢？另外grub是如何知道某个设备是HD还是FD?是调用BIOS中断？在DBR引导代码中，要找grldr,这个引导代码需要知道这个设备是HD还是FD吗？
作者: 不点 时间: 2005-1-15 00:00
GRUB for DOS 的 map 命令从 BPB 或者 MBR 中探测 C/H/S 的值。根据你指定的，fd 就是软盘，hd 就是硬盘，这不是 GRUB 主观判断的，而是用户指定的。
GRLDR在DBR中的代码，无需知道是软盘还是硬盘，不过，是软盘就得是 (fd0)，是硬盘就得是 (hd0)。违反了这两个，我不能肯定一定会失败，但有可能失败。
DBR 中的 GRLDR 引导代码无需知道是从 FD 还是 HD 引导的。但是，BIOS 会把引导时的磁盘号码放在 DL 寄存器中，因此，GRLDR 也知道它究竟是经由 FD 还是 HD 引导的。
GRUB 这里没有 BUG，有 BUG 的是 BIOS。我觉得你不妨用 1.44M 的软盘实验一下，就用 win98 的启动软盘再加上 grub.exe 就可以了，一点也不麻烦。如果这时还有毛病的话，那我们也能够判定究竟是谁的错。
作者: pierrexqw 时间: 2005-1-16 00:00
发现一个问题。我用的是Gandalf的中文版，但是我想问题应该出在这边。
本来我是使用grldr，利用XP自带的引导器引导grub。现在我想把grub装到mbr上，于是在grub命令行中输入
root (hd0,0)
setup (hd0)
这时会提示grub正在安装，实际上grub也安装到mbr了。但是装的是gnu的grub，不是经过改进的grub for dos。这一点从标头文字以及不支持中文字体就可以很明显的看出来。
是我缺少了什么参数，还是这算一个Bug?
[此贴子已经被作者于2005-1-16 1:33:23编辑过]
作者: 不点 时间: 2005-1-16 00:00
是这样的，GRLDR 不利用任何 stage 文件，而 setup 命令安装的是那些 stage 文件。如果你的 stage2文件没有经过中文化，那么你用 setup 所得到的就仍然是未经中文化的 GRUB。这种方法所安装的 GRUB，完全不采用 GRLDR文件。另一方面，只要 GRLDR 一个文件就够了，也就是说，GRLDR 也不需要那些 stage 文件的存在。这是两套互补相干的系统。
关于安装 GRLDR 到 MBR的方法，在 http://grub.linuxeden.com/ 上有详细步骤。
作者: pierrexqw 时间: 2005-1-16 00:00
将 GRUB 安装到硬盘主引导磁道（MBR 以及紧接 MBR 之后的几个扇区）的方法：
a. 将硬盘第一扇区（MBR）读入内存区域1，将 GRLDR 开头 5 个扇区读入内存区域2。
b. 将 内存区域1 的 0x01be 至 0x01ff 这 66 个字节复制到 内存区域2 的 0x01be 至 0x01ff。（这个区域是硬盘分区表）。
c. 将更改后的 内存区域2（其长度是 5 个扇区）写入硬盘开头的 5 个扇区上（也就是 MBR 以及紧接着它后面的 4 个扇区上）。
重要更正：上述 b. 应当更改为：
b. 将 内存区域1 的 0x01b8 至 0x01ff 这 72 个字节复制到 内存区域2 的 0x01b8 至 0x01ff。（这个区域是Windows 的 disk signature 以及硬盘分区表）。
因为有那个重要更正，wingrub写入mbr的功能不能用了对吗？不点可以具体说下一在linux下面用dd该怎么操作吗？我怕那些字节数错，毕竟MBR或者分区表弄坏了挺麻烦的。
另外，这样的操作完成之后grldr必须留在原来的分区下，对吗？
[此贴子已经被作者于2005-1-16 14:58:27编辑过]
作者: 不点 时间: 2005-1-16 00:00
手动操作总有些提心吊胆的。失误总是常常陪伴着我们。所以，要想不受到损失，就得把硬盘分区表备份到另外一块磁盘上，或者备份到 U盘更好。备份到软盘也可以，但很不保险，因为我经历过的软盘，寿命都很短。有的软盘，可以写入，但当你去读时，失败了。或者今天可以读出，明天就读不出了，只好让你流泪。
在备份了你的分区表之后，你大概也就比较放心了，但也不是 100% 的放心，因为 dd 命令本身很危险。
用 dd 命令，如果忘了敲入 “count=”参数，在某些情况下，会将整个硬盘毁掉，你当然无法恢复了，因为它抹掉了整个硬盘上的数据，而不仅仅是分区表。尤其是当 if=参数指定的输入文件是一个设备时，危险最大。比如，if=/dev/zero 或者 if=/dev/hdc 等等。
所以，我反对使用 dd 命令，即使你小心，我也反对，因为这个命令用起来特别简单，给人一个印象就是它很优秀，这样，很容易诱导让那些不熟练 LINUX 的人也尝试去使用这条命令。用好了高兴，用坏了就是灾难。
好了，假定你已经备份了你的分区表到 U 盘，否则，你可能无法放心地去睡觉。下面就开始动刀子了。
-----------------------------------------------------------------------------------------------------------------------------------------------
首先读取“微软的 disk signature ” 和 “硬盘分区表”，也就是第一块硬盘的第一扇区的末尾的 72 个字节：
dd if=/dev/hda of=my_heart bs=1 count=72 skip=440
bs=1 是按照字节为单位来计算
count=72 表示复制 72 个单位的长度到目的地
skip=440 表示跳过源输入文件的开头 440 个单位。
因此要复制的就是从第 441 到第 512 字节这 72 个字节。
命令完成后，用
hexedit my_heart
看看文件内容是否正确。
第二步，读取 GRLDR 开头的 440 个字节：
dd if=grldr of=new_mbr_code bs=1 count=440
第三步，读取 GRLDR 开头的第 2 至第 5 扇区：
dd if=grldr of=sector_2_to_5 bs=512 count=4 skip=1
第四步，将上述三个文件拼接成一个文件：
cat new_mbr_code my_heart sector_2_to_5 > my_dangerous_mbr_5_sectors
用 ls -l 列出 my_dangerous_mbr_5_sectors 的长度，看看是不是正确的 2560 字节，再用 hexedit 检查确认文件格式是没错的。
第五步，以上都是写入临时文件，这次真的危险喽！要写入 MBR，后果自负啊，别说后悔的话哟(尤其不要说是我害了你耶)！
你需要再次确认 /dev/hda 确实是你的 MBR 存放地！！如果你误写入另外一块磁盘上，那你岂不是犯了过失杀人罪，无辜毁掉其它磁盘！！
有的机器，其 MBR 是在 /dev/sda 上，或者是在其它设备上，这可要弄准了！如果有含糊，那么就此罢休，别再继续了！！
dd if=my_dangerous_mbr_5_sectors of=/dev/hda bs=512 count=5
第六步，你现在还不知道你是否已经杀了人，趁机器现在还没死，你需要再把刚才干的事情确认一下：
dd if=/dev/hda of=mbr_just_written bs=512 count=5
你再用 hexedit 看看 mbr_just_written 是否正常，如果有误，你还有机会赎罪。
第七步，你需要运行 fdisk -l /dev/hda 命令，看看你的分区都还在不在，如果有异常，你就知道是你干的坏事造成的，因此这不是你可以睡觉的时候。你最好再操作更多一些大型软件，看看是否出问题，然后才放心。
第八步，不是太重要，但是为避免启动时死机，检查一下 GRLDR 文件是否位于某个主分区的根目录，并且该 primary 分区应当是微软格式的分区，而不应当是 linux 格式的分区(因为目前还没有支持linux格式的分区)。
第九步，该造的孽都造过了，生死就在此一举！顺便看看你手中的 U 盘还在不在。重启动机器，看看 GRLDR 的引导是否正常。
经过上述操作之后，如果你今后患有失眠、多梦等疾病，那都属于正常现象。
GRLDR 除了上述所说的限制之外，没有其它限制，即使你先写入 MBR，后将 GRLDR 放入某个主分区的根目录也可。MBR不含有GRLDR文件的位置信息，它是通过查找全部四个主分区，从而找到 GRLDR 的，查找过程是动态的，在 MBR 接管控制后它就开始查找GRLDR。
作者: pierrexqw 时间: 2005-1-19 00:00
-__________- BT的不点，弄得一惊一乍的。本来没毛病现在吓出毛病了。
作者: 不点 时间: 2005-1-19 00:00
十分抱歉，呵呵。
不过你现在好象才算真的没有毛病了[em07]，原来是你BT，现在你属于正常了(我上面说过的)。
作者: waffle 时间: 2005-1-22 00:00
用1.44M的软盘试了，一切正常。说明grldr对普通软盘读写没有问题，但由于现在是u盘模拟出来的软盘，和真实的软盘还是有差别的（比如FAT的位置和大小），所以出现问题很正常。我估计如果模拟成HDD方式就不会出现问题。如果按照普通软盘的BPB来改写u盘的BPB,使u盘变成1.44M来用，应该也没有问题，只不过没有多大的意义了。
作者: 不点 时间: 2005-1-22 00:00
从这些情况来看，似乎全面证实了我前面的猜测，那就是，你的 U 盘事实上只能支持 1.44M 的启动软盘。
GRLDR 不存在 1.44M 的限制，即使你使用 fd0，GRLDR 也不存在 1.44M 的限制，应当是你的 BIOS 存在这样的限制。
我用 GRUB for DOS 曾经仿真 1GB 的软盘，也就是 1000MB，运行良好。
你如果将软盘格式化为 128M的，再拷贝两个 2M 大小的文件到软盘，(注意是拷贝两个文件，不是一个)。用 U 盘启动到 DOS，如果你在DOS 下可以用 edit 打开这两个文件，那就说明你的 BIOS 确实支持超过 1.44M的启动软盘。如果死机了，或者出现其它不正常现象，那就说明你的 BIOS 不支持 1.44M 以上的启动软盘的读写。
先前我有 99% 的把握，现在由于你所说的情况都在我的意料之中，因此我有 99.99% 的把握，肯定你的 BIOS 不支持大于 1.44M 的启动软盘。
不过，继续试验已经没有意义了，因为 1.44M 的启动软盘也就够用了，本来就不需要更大的启动软盘。
另外，模拟成 HDD 方式出不出问题，仍然取决于你的 BIOS，而不是 GRUB，因为 GRUB 没有这类 BUG 的。
好了，不管究竟问题是在 GRUB 还是 在 BIOS，都不重要了，因为毕竟 GRUB 可以在你的 1.44M 的 U 盘上正常使用了。
作者: waffle 时间: 2005-1-22 00:00
前面那个1.44M的软盘测试是真实的软盘，不是把u盘故意格成的，只是看看BIOS对grldr软盘启动能完全支持。后来我故意把u盘格成1.44M,BPB都是按照普通1.44M软盘来的，结果无论是DOS还是GRUB,都找不到启动文件。我估计是这样的：由于是USB-ZIP模式，BIOS把head和sectors/track都认死了，heads=64,sectors/track=32。所以DBR中的引导代码在寻找启动文件的时候会失败，因为引导代码根据BPB参数（现在是heads=2,sectors/track=18）计算出某扇区的CHS值传给BIOS后，BIOS按照这个CHS值根据heads=64,sectors/track=32算出的却是别的扇区了。而以前直接用USB-ZIP格式化成一个120M的分区因为BPB里的head和sectors/track数值和BIOS默认的正好是一样的，所以引导代码能找到启动文件。后来把u盘格成128M，copy了2个2M多（总共5M多）的mp3上去，都能用edit顺利打开，看来BIOS能支持1.44M以上的启动盘。这里为什么要copy两个，而不是一个2M文件过去,或者copy一个4M文件呢？启动盘还是大点的好，比如有好几个1.44M的软盘镜像，就可以用grldr来选择引导了。看来还是不能确定在什么地方有问题啊。
作者: 不点 时间: 2005-1-23 00:00
这个问题最终属于你的 BIOS机关，要么它的说明书你没看，要么它没有说明书，因此需要你去不断去尝试。还记得前面你的格式化工具曾经把总扇区数搞错的事情吧？它能把这都弄错，也很容易把更多的地方弄错。你检查 int13的一些常用的功能，其中包括ah=8和ah=15h这两个功能，它肯定有错误。(记得上面动不动死机的事吧，在这样很简明的操作下死机，是int13指令的死机，GRUB的其它地方是用C语言写的，只能出现错误信息，不会有死机的。)
你说“BIOS把head和sectors/track都认死了”，有什么根据呢？它会不会把 cylinders 也认死了呢？如果把cylinders 也认死了，那你用一个不合乎 BIOS 要求的 cylinders 值，当然会出问题了。这时 DOS中的其它操作都可能正常，但是 GRUB 一开始就要计算文件系统的总长度，所以，GRUB 就碰巧要用到 cylinders 这个值，所以GRUB 会失败。不过这只是猜测。将这些规格数据搞成死定的，这本身应当算是 BIOS的毛病吧？即使它公开说明了，也应当算是毛病，因为这毕竟不利于用户。
总之，依我看，还是能够肯定是 BIOS 的问题。如果这不是 BIOS 的错，而能证明是 GRUB 的错误的话，那可是一个大大的 BUG了。在 GRUB 调用 int13 的相关处理程序中出现这样的 BUG，我觉得太大了，因此出现 BUG的可能性是微乎其微的。从这个 BIOS 的表现来看，它不能算是一个好的BIOS(我个人觉得它很粗糙)，因此我认为，着重从它这里找错，是对路的。如果你想从 GRUB 那里着手，我估计到最后跟踪到 int13，跟踪到BIOS，最终发现的错误，仍然是 BIOS 的。
无非就是 GRUB 不能正常使用，也用不着再去找错了。找错的好处是，一旦真正找到病根，我们可以有补救办法，让 GRUB躲过这些暗礁，顺利运转起来。不过看来不太可能了，如果你不去逐个测试 int13 功能调用的话。在 google 中搜索，应当可以找到int13 的一些常用功能的解释，无论中文还是英文，都有很多网页的。
传统的 BIOS，确实也很难存在 BUG，因为这比 GRUB 的历史还要悠久很多。然而这里所说的 BIOS，是特指 USB 启动盘的处理部分，这是一个新的事物，并未经过多年的长期测试，因此，怀疑它有 BUG，也是情理之中的。
作者: newdos11 时间: 2005-2-3 00:00
| Quote: | |
|
从我认识GRUB这个软件开始，我就尝试把它安装到U盘上，但无论是用USB-ZIP，USB-HDD方式结果都是一样，GRUB能装到我的U盘上，就是无法读取U盘上的内容。或者正如你所说的，这和我的BIOS有关，我也认为这是对的。但是前几天，我无意中令到我的U盘能够被GRUB读取其内容，此时U盘用的是USB-HDD方式，为什么本来无法识别的，现在可以识别了呢？而且能识别和不能识别时用的都是XP自带的工具格式化U盘的。可是用USB-HDD方式启动电脑，远远比不上USB-ZIP，真的希望有高手能研究一下怎样才能令GRUB识别USB-ZIP的U盘，我认为GRUB读不了U盘内容不单和BIOS有关。
作者: 不点 时间: 2005-2-4 00:00
USB-HDD模式能使GRUB正常运行，而USB-ZIP模式不能使GRUB正常运行，这一事实，不能说明任何问题。可能出现这样的情况：当处于USB-HDD模式时，BIOS没有BUG(也就是说，BUG在此时表现不出来)，而当处于USB-ZIP模式时，BIOS有BUG。
如果能证明在 USB-ZIP模式时 int13 的几个常用的调用都是正确的，那么我们就可以断定问题是出在 GRUB 上，而不是 BIOS 的毛病。
证明 int13 有没有毛病，是最简单的，如果去找 GRUB 的毛病，则是大海捞针。所以，我倾向于先从 int13 入手，也就是说，先证明 int13 没有毛病，然后再去做进一步的工作。
如果 int13 有毛病，由于我们知道它在哪里出了毛病，所以很容易给它打个补丁，这样就可达到我们正常使用GRUB的目的。
如果 int13 没有毛病，我们就可以断定 GRUB 的代码肯定含有未知的 BUG，这样我们再去努力寻找 GRUB 的BUG。
由此可见，检查 int13 是关键。没有这个，什么问题也说明不了，除非你确实在 GRUB 的代码中发现了BUG，而发现这个，是很难的，因为GRUB的代码并不那么容易看懂的。
-----------------------------
我不相信这么多使用 USB-ZIP 的人里面，竟然没有一个人在 USB-ZIP 模式起作用时去检查 BIOS 的 int13 ？做这个一点也不难，只需会用 debug 就行的。熟练的话，几分钟就可以检查完毕。
作者: 不点 时间: 2005-2-4 00:00
> 但是前几天，我无意中令到我的U盘能够被GRUB读取其内容，此时U盘用的是USB-HDD方式，为什么
> 本来无法识别的，现在可以识别了呢？而且能识别和不能识别时用的都是XP自带的工具格式化U盘的。
这个现象同样不能表明问题究竟出在何处。有可能是这样的情况：BIOS 的 BUG 在你前一次的格式化中表现出来了，而在你后一次格式化中未表现出来。解决的办法还应当是检查 int13。
我觉得很可能会是这样的：在前一次出现异常情况的时候，如果你去检查 INT13, 则会发现 BIOS 的BUG，而在你后一次没有出现异常情况的时候，你可能无法发现 BIOS 的 BUG。
在 google 中搜索 debug 以及 int13 , 应当可以很快了解 debug 以及 int13 的相关资料。
作者: newdos11 时间: 2005-2-4 00:00
不会用DEBUG，我是先用WINGRUB“Boot From Bs”,然后用“Boot From MBR”对U盘进行处理后，U盘里的文件就能被GRUB识别，同我用什么格式化工具无关的，也就是说只要按先后顺序做上述两步，我的U盘就可以在USB-HDD方式下使用GRUB了，以前试过几乎很多方法都不行。
作者: 不点 时间: 2005-2-4 00:00
在没有出现异常时，你可能就无法再发现 BUG 了。出现异常情况时，虽然这对你很不好，你很不愿意出现这种情况，但是另一方面，你却有机会去发现BUG。所以，出现异常才是好事呢。像你上面这样试来试去的，基本上不能说明什么问题。在出现异常时，你用这个异常的 GRUB 去启动硬盘上的某个DOS(应当是实模式的DOS，而不是win98的DOS窗口)，然后在 DOS 下操作 debug，就可以发现 BIOS 的 BUG了。你不愿意做(或者不会做)没关系，期待着会有别人去做这个的。如果不做这个检查，再怎么讨论也没有结果的，因为那都是猜测，什么也不能肯定。这正如生病了不就医，而去找个不是医生的人给自己看病那样。
作者: newdos11 时间: 2005-2-5 00:00
出现异常情况时对我或者真的是好事，我现在不需要再用那个有问题方法来安装GRUB了，而且成功令一台本来用我的U盘开不了机的电脑开机了。谢谢不点的热心解答。