|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 31 楼』:
使用 LLM 解释/回答一下
是这样的，GRLDR 不利用任何 stage 文件，而 setup 命令安装的是那些 stage 文件。如果你的 stage2文件没有经过中文化，那么你用 setup 所得到的就仍然是未经中文化的 GRUB。这种方法所安装的 GRUB，完全不采用 GRLDR文件。另一方面，只要 GRLDR 一个文件就够了，也就是说，GRLDR 也不需要那些 stage 文件的存在。这是两套互补相干的系统。
关于安装 GRLDR 到 MBR的方法，在 http://grub.linuxeden.com/ 上有详细步骤。
Here's how it is: GRLDR doesn't utilize any stage files, while the setup command installs those stage files. If your stage2 file hasn't been Chinese - localized, then what you get with setup is still non - Chinese - localized GRUB. The GRUB installed by this method doesn't use the GRLDR file at all. On the other hand, only the GRLDR file is needed, that is, GRLDR doesn't need the existence of those stage files either. These are two complementary systems.
For the method of installing GRLDR to the MBR, there are detailed steps on http://grub.linuxeden.com/.
|
因为我们亲手创建，这个世界更加美丽。 |
|
 2005-1-16 00:00 |
|
|
pierrexqw
初级用户
积分 121
发帖 10
注册 2004-11-19
状态 离线
|
『第 32 楼』:
使用 LLM 解释/回答一下
将 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必须留在原来的分区下，对吗？
Methods to install GRUB to the hard disk master boot record (MBR and the next few sectors after MBR):
a. Read the first sector (MBR) of the hard disk into memory area 1, and read the first 5 sectors at the beginning of GRLDR into memory area 2.
b. Copy 66 bytes from 0x01be to 0x01ff in memory area 1 to 0x01be to 0x01ff in memory area 2. (This area is the hard disk partition table).
c. Write the changed memory area 2 (which has a length of 5 sectors) to the first 5 sectors at the beginning of the hard disk (that is, on the MBR and the next 4 sectors after it).
Important correction: The above b. should be changed to:
b. Copy 72 bytes from 0x01b8 to 0x01ff in memory area 1 to 0x01b8 to 0x01ff in memory area 2. (This area is the Windows disk signature and the hard disk partition table).
Because of that important correction, the function of wingrub writing to the MBR can't be used, right? Can you specifically say how to operate with dd under Linux? I'm afraid of getting the byte count wrong, after all, it's troublesome if the MBR or partition table is damaged.
Also, after such an operation, must grldr stay in the original partition, right?
|
|
|
2005-1-16 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 33 楼』:
使用 LLM 解释/回答一下
手动操作总有些提心吊胆的。失误总是常常陪伴着我们。所以，要想不受到损失，就得把硬盘分区表备份到另外一块磁盘上，或者备份到 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。
Manual operations are always a bit nerve - wracking. Mistakes always accompany us often. So, to avoid losses, we need to back up the hard disk partition table to another disk, or it's better to back it up to a USB flash drive. Backing up to a floppy disk is also possible, but it's not very reliable because the floppy disks I've experienced all have a short lifespan. Some floppy disks can be written to, but when you try to read them, they fail. Or they can be read today but not tomorrow, making you shed tears.
After backing up your partition table, you may be relatively at ease, but not 100% at ease because the dd command itself is very dangerous.
When using the dd command, if you forget to type the "count=" parameter, in some cases, it will destroy the entire hard disk, and of course, you won't be able to recover it because it erases all the data on the entire hard disk, not just the partition table. Especially when the input file specified by the if= parameter is a device, the danger is the greatest. For example, if=/dev/zero or if=/dev/hdc, etc.
So, I oppose using the dd command. Even if you are careful, I oppose it because this command is extremely simple to use, giving people the impression that it's very good, and this is likely to induce those who are not proficient in LINUX to try to use this command. It's happy if used well, but a disaster if used badly.
Well, assume you have backed up your partition table to the USB flash drive; otherwise, you may not be able to sleep at ease. Now it's time to start the risky operation.
-----------------------------------------------------------------------------------------------------------------------------------------------
First, read the "Microsoft's disk signature" and the "hard disk partition table", that is, the last 72 bytes of the first sector of the first hard disk:
dd if=/dev/hda of=my_heart bs=1 count=72 skip=440
bs=1 means calculating in bytes.
count=72 means copying 72 units of length to the destination.
skip=440 means skipping the first 440 units of the source input file.
Therefore, what is to be copied is the 72 bytes from the 441st to the 512th byte.
After the command is completed, use
hexedit my_heart
to see if the file content is correct.
Second, read the first 440 bytes at the beginning of GRLDR:
dd if=grldr of=new_mbr_code bs=1 count=440
Third, read the 2nd to 5th sectors at the beginning of GRLDR:
dd if=grldr of=sector_2_to_5 bs=512 count=4 skip=1
Fourth, concatenate the above three files into one file:
cat new_mbr_code my_heart sector_2_to_5 > my_dangerous_mbr_5_sectors
Use ls -l to list the length of my_dangerous_mbr_5_sectors and see if it is correctly 2560 bytes, and then use hexedit to check and confirm that the file format is correct.
Fifth, all the above are writing to temporary files, and now it's really dangerous! To write to the MBR, the consequences are at your own risk! Don't say you regret it later (especially don't say it's my fault)!
You need to confirm again that /dev/hda is indeed where your MBR is stored! If you mistakenly write to another disk, then you have committed involuntary manslaughter, innocently destroying other disks!
In some machines, the MBR is on /dev/sda or on other devices, so this must be clarified! If there is any ambiguity, then stop here and don't continue!
dd if=my_dangerous_mbr_5_sectors of=/dev/hda bs=512 count=5
Sixth, you don't know yet if you have killed the disk. While the machine is still alive, you need to confirm what you just did:
dd if=/dev/hda of=mbr_just_written bs=512 count=5
You use hexedit to see if mbr_just_written is normal. If there is an error, you still have a chance to make amends.
Seventh, you need to run the fdisk -l /dev/hda command to see if your partitions are still there. If there is an anomaly, you know it's caused by what you did, so this is not a time for you to sleep. You'd better operate more large software to see if there are problems, and then feel at ease.
Eighth, it's not too important, but to avoid the machine crashing at startup, check if the GRLDR file is located in the root directory of a primary partition, and the primary partition should be a Microsoft - formatted partition, not a Linux - formatted partition (because currently there is no support for Linux - formatted partitions).
Ninth, you've done all the bad things, and life or death depends on this! By the way, see if your USB flash drive is still there. Restart the machine and see if the GRLDR boot is normal.
After the above operations, if you suffer from insomnia,多梦 and other diseases in the future, it's all normal.
In addition to the above - mentioned limitations, GRLDR has no other limitations. Even if you write the MBR first and then put GRLDR in the root directory of a primary partition, it's also okay. The MBR doesn't contain the location information of the GRLDR file. It finds GRLDR by searching all four primary partitions, and the search process is dynamic. After the MBR takes control, it starts to search for GRLDR.
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-1-16 00:00 |
|
|
pierrexqw
初级用户
积分 121
发帖 10
注册 2004-11-19
状态 离线
|
『第 34 楼』:
使用 LLM 解释/回答一下
-__________- BT的不点，弄得一惊一乍的。本来没毛病现在吓出毛病了。
-__________- Don't click BT-related things. It's making a big fuss. Originally there was no problem, now it's scaring out a problem.
|
|
|
2005-1-19 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 35 楼』:
使用 LLM 解释/回答一下
十分抱歉，呵呵。
不过你现在好象才算真的没有毛病了，原来是你BT，现在你属于正常了(我上面说过的)。
I'm really sorry, heh heh.
But you seem to be really fine now , originally it was you who was abnormal, now you're normal (as I said above).
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-1-19 00:00 |
|
|
waffle
中级用户
积分 230
发帖 37
注册 2003-5-24
状态 离线
|
『第 36 楼』:
使用 LLM 解释/回答一下
用1.44M的软盘试了，一切正常。说明grldr对普通软盘读写没有问题，但由于现在是u盘模拟出来的软盘，和真实的软盘还是有差别的（比如FAT的位置和大小），所以出现问题很正常。我估计如果模拟成HDD方式就不会出现问题。如果按照普通软盘的BPB来改写u盘的BPB,使u盘变成1.44M来用，应该也没有问题，只不过没有多大的意义了。
I tried with a 1.44M floppy disk, and everything worked normally. It shows that grldr has no problem reading and writing to ordinary floppy disks. But since the current one is a floppy disk emulated by a USB flash drive, there are differences from the real floppy disk (such as the position and size of FAT), so it's normal to have problems. I estimate that if it's emulated in HDD mode, there won't be problems. If we rewrite the BPB of the USB flash drive according to the BPB of the ordinary floppy disk to make the USB flash drive used as 1.44M, it should also be okay, but it's not very meaningful.
|
|
|
2005-1-22 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 37 楼』:
使用 LLM 解释/回答一下
从这些情况来看，似乎全面证实了我前面的猜测，那就是，你的 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 盘上正常使用了。
From these situations, it seems to fully confirm my previous guess, that is, your USB flash drive in fact can only support a bootable floppy disk of 1.44M.
GRLDR has no limit of 1.44M. Even if you use fd0, GRLDR has no limit of 1.44M. It should be that your BIOS has such a limit.
I once emulated a 1GB floppy disk with GRUB for DOS, that is, 1000MB, and it ran well.
If you format the floppy disk as 128M, and copy two files of 2M size to the floppy disk, (note that it is copying two files, not one). Boot the USB flash drive to DOS, if you can open these two files with edit under DOS, then it means that your BIOS does support bootable floppy disks larger than 1.44M. If it freezes or other abnormal phenomena occur, then it means that your BIOS does not support reading and writing of bootable floppy disks larger than 1.44M.
Previously I had 99% confidence, now because the situations you mentioned are all within my expectations, therefore I have 99.99% confidence that your BIOS does not support bootable floppy disks larger than 1.44M.
However, continuing the test is no longer meaningful, because a bootable floppy disk of 1.44M is sufficient, and there is no need for a larger bootable floppy disk originally.
In addition, whether there is a problem when emulating in HDD mode still depends on your BIOS, not GRUB, because GRUB has no such bugs.
Well, no matter whether the problem is in GRUB or in BIOS, it doesn't matter, because after all, GRUB can be used normally on your 1.44M USB flash drive.
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-1-22 00:00 |
|
|
waffle
中级用户
积分 230
发帖 37
注册 2003-5-24
状态 离线
|
『第 38 楼』:
使用 LLM 解释/回答一下
前面那个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来选择引导了。看来还是不能确定在什么地方有问题啊。
The previous test with the 1.44M floppy disk was with a real floppy disk, not an intentionally formatted USB flash drive. Just to see if the BIOS fully supports GRUB boot from a floppy disk. Later, I intentionally formatted the USB flash drive to 1.44M, with BPB all in accordance with the parameters of an ordinary 1.44M floppy disk. As a result, neither DOS nor GRUB could find the boot file. I estimate it's like this: Since it's in USB-ZIP mode, the BIOS firmly recognizes heads = 64 and sectors/track = 32. So the boot code in the DBR fails to find the boot file because the boot code calculates the CHS value of a certain sector according to the BPB parameters (now heads = 2, sectors/track = 18) and passes it to the BIOS. But the BIOS calculates another sector according to heads = 64 and sectors/track = 32 with this CHS value. Whereas before, directly formatting a USB flash drive in USB-ZIP format to a 120M partition worked because the values of heads and sectors/track in the BPB happened to be the same as the BIOS default, so the boot code could find the boot file. Later, I formatted the USB flash drive to 128M, copied two MP3s of more than 2M each (totaling more than 5M), and could open them smoothly with edit. It seems the BIOS can support boot disks larger than 1.44M. Why copy two here instead of one 2M file or one 4M file? A larger boot disk is better. For example, if there are several 1.44M floppy disk images, GRUB can be used to select the boot. It seems I still can't determine where the problem is.
|
|
|
2005-1-22 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 39 楼』:
使用 LLM 解释/回答一下
这个问题最终属于你的 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，也是情理之中的。
This problem ultimately belongs to your BIOS mechanism. Either you didn't read its manual, or it doesn't have a manual, so you need to keep trying. Remember the thing where your formatting tool once messed up the total number of sectors? It could mess up that, and it's easy to mess up more things. You check some common functions of int13, including the two functions ah=8 and ah=15h, and it must be wrong. (Remember the thing about crashing动不动before? Crashing under such a simple operation is a crash of the int13 instruction. The other parts of GRUB are written in C language and can only show error messages, not crash.)
You said "the BIOS rigidly recognizes head and sectors/track". What's the basis? Could it also rigidly recognize cylinders? If it rigidly recognizes cylinders, then of course there will be problems if you use a cylinders value that doesn't meet the BIOS requirements. At this time, other operations in DOS may be normal, but GRUB has to calculate the total length of the file system at the beginning, so GRUB happens to use the cylinders value, so GRUB will fail. But this is just a guess. Making these specification data rigid is inherently a problem of the BIOS, right? Even if it is publicly stated, it should be considered a problem because it is after all not beneficial to users.
In short, in my opinion, it can still be affirmed that it is a problem with the BIOS. If this is not the fault of the BIOS and it can be proved to be a mistake in GRUB, then it is a big BUG. I think it's extremely unlikely that there is such a BUG in the relevant processing program of GRUB calling int13. Judging from the performance of this BIOS, it can't be regarded as a good BIOS (I personally think it's very rough), so I think focusing on finding the mistake here is the right way. If you want to start from GRUB, I estimate that in the end, when tracking to int13 and then to the BIOS, the discovered mistake will still be in the BIOS.
It's nothing more than GRUB not being able to be used normally, and there's no need to look for mistakes anymore. The benefit of finding mistakes is that once the root cause is really found, we can have a remedy to let GRUB avoid these reefs and run smoothly. But it doesn't seem likely. If you don't test each int13 function call one by one. Searching in Google should be able to find explanations of some common functions of int13, there are many web pages in both Chinese and English.
Traditional BIOS really is also very unlikely to have BUGs, because it is much older than GRUB. However, the BIOS mentioned here specifically refers to the processing part of the USB boot disk, which is a new thing and has not been tested for many years, so it is reasonable to suspect that it has BUGs.
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-1-23 00:00 |
|
|
newdos11
初级用户
积分 186
发帖 32
注册 2004-6-16
状态 离线
|
『第 40 楼』:
使用 LLM 解释/回答一下
以下是引用不点在2005-1-23 15:44:01的发言：
这个问题最终属于你的 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，也是情理之中的。
从我认识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有关。
The following is the statement made by Budian on January 23, 2005 at 15:44:01:
This problem ultimately belongs to your BIOS setup. Either you haven't read its manual, or there is no manual, so you need to keep trying. Remember the incident before where your formatting tool got the total number of sectors wrong? It could get that wrong, and it's easy to get more things wrong. You check some common functions of int13, including the functions ah=8 and ah=15h. It must have errors. (Remember the frequent freezes before? Freezing under such a simple operation is a freeze caused by the int13 instruction. The other parts of GRUB are written in C and can only display error messages, not freeze.)
You said "the BIOS has fixed values for head and sectors/track". What is the basis? Could it also have fixed values for cylinders? If it has fixed values for cylinders, then if you use a cylinders value that doesn't meet the BIOS requirements, it will naturally cause problems. At this time, other operations in DOS may be normal, but GRUB needs to calculate the total length of the file system at the beginning, so GRUB happens to use the cylinders value, so GRUB will fail. But this is just a guess. Making these specifications fixed itself should be considered a flaw in the BIOS? Even if it is publicly stated, it should be considered a flaw because it is not conducive to users.
In conclusion, in my opinion, it can still be affirmed that it is a BIOS problem. If this is not the fault of the BIOS and it can be proven to be a GRUB error, then it is a big BUG. I think the possibility of a BUG in the relevant processing program of GRUB calling int13 is very small. Judging from the performance of this BIOS, it cannot be considered a good BIOS (I personally think it is very rough), so I think focusing on finding faults here is the right way. If you start from GRUB, I estimate that in the end, tracking to int13 and then to the BIOS, the found error will still be in the BIOS.
It's nothing more than GRUB not working properly, and there's no need to look for faults anymore. The benefit of finding faults is that once the root cause is really found, we can have remedies to let GRUB avoid these reefs and run smoothly. But it doesn't seem likely. If you don't test the int13 function calls one by one. Searching in Google, you should be able to find explanations of some common functions of int13, both in Chinese and English, there are many web pages.
Traditional BIOSs indeed rarely have BUGs because they are much older than GRUB. However, the BIOS mentioned here specifically refers to the USB boot disk processing part, which is a new thing and has not been tested for many years, so it is reasonable to suspect that it has BUGs.
Since I got to know the GRUB software, I have been trying to install it on a USB flash drive. But whether using USB-ZIP or USB-HDD methods, the result is the same. GRUB can be installed on my USB flash drive, but it just can't read the content on the USB flash drive. Or as you said, this is related to my BIOS, and I also think it's correct. But a few days ago, I accidentally made my USB flash drive readable by GRUB. At this time, the USB flash drive was in USB-HDD mode. Why could it be recognized now when it couldn't be recognized before? And when it was recognizable and unrecognizable, the USB flash drive was formatted with the XP built-in tool. However, booting the computer with USB-HDD mode is far less good than USB-ZIP. I really hope that some experts can study how to make GRUB recognize the USB-ZIP USB flash drive. I think that GRUB not being able to read the USB flash drive content is not only related to the BIOS.
|
|
|
2005-2-3 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 41 楼』:
使用 LLM 解释/回答一下
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 就行的。熟练的话，几分钟就可以检查完毕。
The fact that the USB - HDD mode can make GRUB run normally while the USB - ZIP mode cannot make GRUB run normally does not explain anything. There may be such a situation: when in the USB - HDD mode, the BIOS has no bugs (that is, the bugs do not show up at this time), and when in the USB - ZIP mode, the BIOS has bugs.
If it can be proved that several common calls of int13 in the USB - ZIP mode are all correct, then we can conclude that the problem lies in GRUB, not in the BIOS.
Proving whether int13 has problems is the simplest. If we look for the problems of GRUB, it is like looking for a needle in a haystack. So, I tend to start with int13, that is, first prove that int13 has no problems, and then do further work.
If int13 has problems, since we know where it has problems, it is easy to patch it, so that we can achieve our purpose of using GRUB normally.
If int13 has no problems, we can conclude that there must be unknown bugs in the code of GRUB, and then we will try to find the bugs in GRUB.
It can be seen that checking int13 is the key. Without this, nothing can be explained, unless you really find bugs in the code of GRUB, and finding this is very difficult because the code of GRUB is not so easy to understand.
-----------------------------
I don't believe that among so many people using USB - ZIP, there is not a single one who checks the BIOS's int13 when the USB - ZIP mode works? It is not difficult to do this, just knowing how to use debug. If you are proficient, you can finish the check in a few minutes.
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-2-4 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 42 楼』:
使用 LLM 解释/回答一下
> 但是前几天，我无意中令到我的U盘能够被GRUB读取其内容，此时U盘用的是USB-HDD方式，为什么
> 本来无法识别的，现在可以识别了呢？而且能识别和不能识别时用的都是XP自带的工具格式化U盘的。
这个现象同样不能表明问题究竟出在何处。有可能是这样的情况：BIOS 的 BUG 在你前一次的格式化中表现出来了，而在你后一次格式化中未表现出来。解决的办法还应当是检查 int13。
我觉得很可能会是这样的：在前一次出现异常情况的时候，如果你去检查 INT13, 则会发现 BIOS 的BUG，而在你后一次没有出现异常情况的时候，你可能无法发现 BIOS 的 BUG。
在 google 中搜索 debug 以及 int13 , 应当可以很快了解 debug 以及 int13 的相关资料。
> But a few days ago, I inadvertently made my USB flash drive readable by GRUB, and at this time the USB flash drive was in USB-HDD mode. Why was it originally unrecognizable, but now it can be recognized? And both times when it was formatted, the USB flash drive was formatted using the XP built-in tool.
This phenomenon also does not indicate where the problem is. It is possible that the BIOS bug manifested in your previous formatting and did not manifest in your subsequent formatting. The solution should still be to check int13.
I think it is very likely that when the abnormal situation occurred the first time, if you checked INT13, you would find the BIOS bug, and when the abnormal situation did not occur the second time, you might not be able to find the BIOS bug.
Searching for debug and int13 in Google should quickly allow you to understand the relevant information about debug and int13.
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-2-4 00:00 |
|
|
newdos11
初级用户
积分 186
发帖 32
注册 2004-6-16
状态 离线
|
『第 43 楼』:
使用 LLM 解释/回答一下
不会用DEBUG，我是先用WINGRUB“Boot From Bs”,然后用“Boot From MBR”对U盘进行处理后，U盘里的文件就能被GRUB识别，同我用什么格式化工具无关的，也就是说只要按先后顺序做上述两步，我的U盘就可以在USB-HDD方式下使用GRUB了，以前试过几乎很多方法都不行。
I don't know how to use DEBUG. I first used WINGRUB "Boot From Bs" and then "Boot From MBR" to process the USB flash drive. Then the files in the USB flash drive can be recognized by GRUB, which has nothing to do with what formatting tool I use. That is to say, as long as I do the above two steps in sequence, my USB flash drive can use GRUB in USB-HDD mode. I tried almost many methods before and none of them worked.
|
|
|
2005-2-4 00:00 |
|
|
不点
银牌会员
不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 44 楼』:
使用 LLM 解释/回答一下
在没有出现异常时，你可能就无法再发现 BUG 了。出现异常情况时，虽然这对你很不好，你很不愿意出现这种情况，但是另一方面，你却有机会去发现BUG。所以，出现异常才是好事呢。像你上面这样试来试去的，基本上不能说明什么问题。在出现异常时，你用这个异常的 GRUB 去启动硬盘上的某个DOS(应当是实模式的DOS，而不是win98的DOS窗口)，然后在 DOS 下操作 debug，就可以发现 BIOS 的 BUG了。你不愿意做(或者不会做)没关系，期待着会有别人去做这个的。如果不做这个检查，再怎么讨论也没有结果的，因为那都是猜测，什么也不能肯定。这正如生病了不就医，而去找个不是医生的人给自己看病那样。
When there are no exceptions, you may no longer be able to find bugs. Although abnormal situations are not good for you and you are very reluctant to have such situations, on the other hand, you have the opportunity to find bugs. So, abnormal situations are actually good things. Testing like you did above basically doesn't explain much. When an exception occurs, use this abnormal GRUB to boot a certain DOS on the hard disk (it should be real-mode DOS, not the DOS window of Win98), and then operate debug under DOS, and you can find BIOS bugs. It doesn't matter if you are unwilling to do it (or can't do it); just look forward to others doing it. If this check is not done, no matter how much discussion there is, there will be no result, because it's all guesswork and nothing can be confirmed. This is just like not going to see a doctor when you are sick but finding someone who is not a doctor to treat yourself.
|
因为我们亲手创建，这个世界更加美丽。 |
|
|
2005-2-4 00:00 |
|
|
newdos11
初级用户
积分 186
发帖 32
注册 2004-6-16
状态 离线
|
『第 45 楼』:
使用 LLM 解释/回答一下
出现异常情况时对我或者真的是好事，我现在不需要再用那个有问题方法来安装GRUB了，而且成功令一台本来用我的U盘开不了机的电脑开机了。谢谢不点的热心解答。
An abnormal situation happened, which was really a good thing for me. I don't need to use that problematic method to install GRUB anymore, and I successfully made a computer that couldn't boot from my USB drive start up. Thanks to Budian's enthusiastic answer.
|
|
|
2005-2-5 00:00 |
|
|
