支持含有碎片的文件仿真

mdyblog

chenall 发表于 2015-2-18 10:30
@mdyblog,@sratlf

是我的疏忽

>>忘了更新了,早期的版本0是批处理本身后面发现这个没有什么用处
也就是 说 原来是从1开始的。
其实， 没必要改成从0开始。
改成从0开始 也看不出有什么好处。
这一改，反倒造成 不必要的不兼容。
和历史上的文档， 方法，记忆都不兼容的。

追求感觉上的完美，是要付出代价的。
-------------------------------
祝C大、丫丫、不点、sratlf  新年快乐！{:soso_e177:}

不点

mdyblog 发表于 2015-2-18 16:56
>>忘了更新了,早期的版本0是批处理本身后面发现这个没有什么用处
也就是 说 原来是从1开始的。
其实 ...

谢谢您，谢谢所有的朋友们。借此顺祝各位喜气洋洋，洋洋洒洒，阳光灿烂，扬眉吐气。

淡出之后，看到你们继续前进，由衷高兴。

希望开发者们注意身体，不要熬夜，稳步前进，不急不躁。

2011yaya2007777

供 DavidBrenner3 测试：

mdyblog

请问下面的情况， 怎么保留(ud)还能访问？

UD启动 （ud)/grldr

（ud)/grldr 将一块磁盘 map为(hd0)

1. map (hd0)0x4096+0x4096000 (hd0)
   
2. map (hd0) (hd1)
   
3. map --rehook

复制代码

然后到(hd0,0),并启动 (hd0,0)/grldr
------------------
问题是：

1. root (hd0,0)
   
2. chainloader /grldr

复制代码

后， (ud)不能访问了.

请问怎么才能启动新的 (hd0,0)/grldr 后还能访问(ud)?

不点

从 ud 盘启动时，ud 可以访问。如果转而启动另一个 grldr，则已经不是从 ud 盘启动了，而是相当于从 bios 直接启动了某个引导扇区，不是从 ud 启动，也不是从光盘启动，此时 ud 是不能访问的。

解决办法：不要在 grub 环境又启动一个新的 grub 环境，丧失原来的 ud 访问能力。

mdyblog

不点 发表于 2015-2-25 20:40
从 ud 盘启动时，ud 可以访问。如果转而启动另一个 grldr，则已经不是从 ud 盘启动了，而是相当于从 bios  ...

1） 我要的不是原因，也不是原理，也不是“理念”。 而是适用的解决方案。

2） 解决办法：不要在 grub 环境又启动一个新的 grub 环境，丧失原来的 ud 访问能力。
这个是无法保证的。
MBROSTool格式化的 UD盘，启动UD中的实现准备好的grldr。
加载用户区。
转而启动用户区。

用户区 是用户格式化的，那个grldr 是用户的。不能代替用户的grldr.

用户还想访问(ud)中的配置信息。

理论上是可以保留(ud)-----只要突破“理念”的束缚。
或者 加个开关：
chainloader --ud  /grldr
总之给个 可行的手段就行，什么方式都行。

不点

我说的是现状，你说的是要改变现状，不是一个概念。很抱歉，我帮不了了，我退出这个话题。

下面是想说给开发者的。

一个软件在功能上尽量可以去完善。但有时候，功能的完善与硬件兼容性发生冲突，迫使你放弃一部分功能，而保证兼容性。一切都是权衡，并无什么绝对的正确性在里面。看问题的角度不同，正确性的概念也不同。也并非所有的用户所提的要求，你都能满足。有可能你满足了一部分用户的要求，却带来了另外的问题。软件不是万能的，它能解决大部分问题，就是基本成功的。如果要以极限挑战的眼光去看问题，那就是企图让功能性达到丰满，这有可能以某种方式损坏兼容性。本问题所提到的 ud 被屏蔽，是我做的。因为grldr启动的时候，要检查是否从ud启动。如果是的，则把 ud 区当作当前 root 区，跳过其他启动步骤。把 ud 区当作当前默认 root 的好处是，ud 区靠前，能够最大限度地适应各种恶劣的 bios 环境。因为优先检查 ud，所以，当后续不是 ud 启动时（比如启动某个软盘映像时，或者启动硬盘的 Windows 时），就不能继续再把 ud 区当作当前 root 了。为了避免 ud 标志被后续的 boot 命令检测到，我在第一次检测 ud 之后，就抹掉了 ud 标志。此时 ud 已经被承认，但后续的启动，如果不是直接模拟 bios 而加载 ud 的第一扇区的话，则无法检测到 ud 标志了，因为这是故意屏蔽掉了。我这说的仍然是现状。至于说这样做是否合理，那我可不敢保证。那将由现在的开发者去权衡和决定。假如能够把这个问题做好，达到两全其美，那也是好事。假如不想动脑筋，不想太费劲去思考这些逻辑问题，那可以保持现状。一句话，看开发者的裁决而定。

在我维护 grub4dos 的时候，对于用户所提的问题，如果我能去解决，我尽量自己去做，这样自己就放心，那是因为自己精力充沛，同时也担心别人做的不符合自己的想法。所以都是尽量由自己来完成。假如我自己完成不了，那我就坦率承认自己做不了，放弃。放弃之后，有可能别人能够做这个工作，那么，这就涉及到这个工作如何融入 grub4dos 的问题。肯定不是无条件都可以随便融入的，一定要经过检验。新的工作往往会带来新的问题。有时候，问题很快都会暴露。但有时候，问题潜藏很深，需要很多年才能暴露。举例来说，原来的 gnu grub legacy 里面的 ntfs 代码有问题，我没有能力写 ntfs 代码，甚至也没有能力看懂 linux 当中的 ntfs 代码，所以，无法解决 ntfs 的有关问题。后来 bean 加入了团队，bean 能够做这个工作，目前的代码就是 bean 的。bean 做这个工作的同时，也把旧的代码保留了下来，好像取名为 fsys_ntfs.old，那意思是，万一不行，还可以恢复原始代码。经过多年的检验之后，确实没问题，所以，旧的代码好像已经删除了。新的代码其实也不是完全没问题，多年以后，chenall 和 yaya 都发现了一些问题，并解决了。还有一个例子是，yaya 对于 grub4dos 的改进和增强。我们看到了，有些问题，例如 mbr 和 pbr 代码中的问题，是最近才发现和解决的。可见，有些问题会潜藏很久。我们为什么长期以来都维护了两个版本，一个是 0.4.5c, 一个是 0.4.6a，那就是因为，对新的功能需要有一个锤炼的过程，新功能有可能影响启动的成功率，也有可能带来兼容性等其他问题。假如这些问题都能得到解决，那么大家就可以放心地使用新版本了。旧版本作为一个参照物，永远保留着它的价值。不同的用户根据自己的需要，选用不同的版本。gandalf 提供的 scdrom 代码，好像存在内存冲突，不稳定，后来由我移植 smart boot manager 的 cdrom 代码，替换了 gandalf 的代码。同样是 gandalf，他所做的基于 vga 图形模式的中文化代码则非常稳定，我们一直保留了下来，直到我们彻底转向 vbe 之前。cdrom 驱动支持是 gandalf 首先引进的，他有首创之功，不可抹杀。我所说的重点在于，代码的稳定性以及后续的表现，是需要锤炼的。这决不等于否认初始工作的价值。类似地，bean 所做的 gfxmenu 图形菜单，也是填补了当时的空缺。只是因为 gfxmenu 天然的独立性，它不同于 grub4dos 的内置代码，它是调用外部的 message 里面的代码，所以，不容易与 grub4dos 无缝对接。所以，我们后来推荐采用新的 vbe 图形菜单模式。karyonix 提供的好几个补丁，都直接采纳了，经过后续若干年的检验，证明是没问题的。大家熟悉的 winvblock 软件的作者是 shao miller，他同时也是 syslinux 的开发团队成员。他所提供的一个与 eltorito cdrom 有关的补丁，刚一开始时，我觉得可以采纳。但后来我仔细想想，还是严格要求吧，是技术就得讲技术，在较好和最好之间就有那么一点点差别，既然能够做到最好或更好，就不能退而求其次。我以 "应该避免占用宝贵的 int13 代码空间" 为理由，在得到 chenall 的同意之后，撤销了 shao miller 的补丁。同时我对 eltorito.sys 这个软件打了补丁，并且纳入到 grub4dos 内部一起维护。这属于 "两种做法都能达到目的，但究竟哪种最好？" 的问题。我主张修改 eltorito.sys 这个软件，而 shao miller 主张修改 grub4dos 的 int13 处理程序。这就是分歧所在。假如是仅凭感情和照顾面子，那确实应该采纳 shao miller 的补丁。但我反复思考，觉得不采纳他的补丁，是对 shao miller 最大的尊重。因为我觉得，那是对他提出了更高的要求，他不属于那种需要照顾面子的人，因此我其实是承认并尊重了他的水平。如果要照顾某个人的面子，实际上则是否认了这个人的高水平，因此适得其反，反而照顾不了他的面子。在我看来，指出一个人的工作中的瑕疵，就是对他的一种极大的尊重。同样地，假如有人指出我的缺陷，我也认为是对我的尊重，是瞧得起我。补充：从后来的实践以及今后长远发展的眼光来看，保持 int13 不被更改的这个做法，其合理性似乎越来越明显了。dos 越来越不适应恶劣的bios环境了，现在 dos 基本上都是作为第二启动，即，首先启动 grub4dos 或 syslinux，然后才能启动 dos。尤其是 dos 作为 eltorito 光盘的主角，已经很不常见了。grub4dos 的用户群，主要是 windows 的。因此，假如仅仅为了很狭窄的、越来越边缘化的领域而修改 int13，那么这种修改，其使用率极低，绝大多数情况下都用不上。而它占用 10 多个字节的宝贵的 int13 代码空间，就越发显得不合理了。所以任何事情都是权衡。也许某件事乍一看是合理的，但经过某种仔细权衡和分析以后，其不合理性就暴露出来了。

过去了的事情，都是历史。历史是可以借鉴的，历史也是可以评判的。没有绝对的正确与错误，只有自己的权衡和倾向。这世界很大，自由度也很大。尤其是对于开源软件来说，自由度是相当大的。自己不满意的事情，可以有很多种处理办法，包括另起炉灶。当初我给 gnu grub 开发团队提交补丁，未被采纳，所以我就被迫另起炉灶。这是完全可以复制的，"另起炉灶" 永远是一个选项。任何人，只要他愿意，他都可以另起炉灶。

现在我离开开发者的行列了，我不再做决定和权衡了。我以往所做过的事情，完全可以被借鉴。当然那些不妥的，也应该予以纠正。这由现在的维护者来负责。

我有我的优点和缺点。从最近几年与各位维护者、开发者和坛内外朋友们的交往来看，我体会到了高手如云。记得以前有人说过，胡荣华并非象棋第一人，民间有很多不曾露面的高手可以完胜胡荣华。我个人目前的特长和优势不在电脑技术方面。举例来说，chenall 和 yaya 非常棒。我在疗养期间，亲眼目睹 chenall 和 yaya 的配合，他们的电脑技术水平都在我之上，因此我也真的感到高兴，因而也彻底放心了。尽管我的英文也是下三烂的水平，我愿意在有机会的时候，能够替开发者们做一些力所能及的工作，因为我发现，目前活跃的这两位开发者，似乎都不太擅长英文。

想到了 jaclaz 这个意大利人，就多说几句。他后来改名为 wonko the sane。这个人真是信守诺言。很多年前，那时候英文论坛是 boot-land.net，现在是 reboot.pro. 当时我请求他替 grub4dos 做推广。他答应了。没想到，这么多年他都坚持回答 grub4dos 的问题，从不间断，从不松懈，令人肃然起敬。

chenall

mdyblog 发表于 2015-2-24 14:01
请问下面的情况， 怎么保留(ud)还能访问？

UD启动 （ud)/grldr

你直接访问(hd1)/不就行了.

实际上早期的版本经过以上hook之后ud的就已经失效了的(无法正常访问).后面经过不点的修改可以了.

ud就是从ud上启动才会有的,就像pd一样,只有从pxe启动才会有pd

若是按你所说的修改的话,我也不确定能不能行,即便能行也是得不偿失.
首先,就是带来兼容性问题.
其次,假如多个磁盘上都有使用fb格式,那ud是要指哪一个呢????
比如你上面的经过map之后,系统到底要从哪个设备查找ud呢???

我觉得有些工作还是自己修改一下菜单修改下就行了,没有必要让软件来代劳,因为得不偿失.

你可以自己写一个外部软件来实现你想要的功能,在菜单中运行你的软件就产生ud设备.

ud设备关键信息在fb_status中

外部程序的作用就是自动查找ud并设置fb_status的值,这样就有ud了.

mdyblog

chenall 发表于 2015-2-26 15:03
你直接访问(hd1)/不就行了.

实际上早期的版本经过以上hook之后ud的就已经失效了的(无法正常访问).后面 ...

1:  你直接访问(hd1)/不就行了.
谢谢， 原来还可以这样 用啊！
非常感谢！


2： 首先,就是带来兼容性问题.
----------
可以提供一个开关。比如 --ud。 用户负责自付。

另外 没有这个功能，才带来兼容性问题。
原来的版本反倒有这个功能。

我相信这个功能还是很有用的。
前面就有人 因为新版本取消了这个功能（而不是完善这个功能）而放弃新版。


3: 其次,假如多个磁盘上都有使用fb格式,那ud是要指哪一个呢????
---------------
原来的UD。
和2一起说吧。

chainloader   --ud    /grldr
这样就保留了原来的 (ud)



4：我觉得有些工作还是自己修改一下菜单修改下就行了,没有必要让软件来代劳,因为得不偿失.
你可以自己写一个外部软件来实现你想要的功能,在菜单中运行你的软件就产生ud设备.
ud设备关键信息在fb_status中
外部程序的作用就是自动查找ud并设置fb_status的值,这样就有ud了.
--------------
这个 新启动的grldr 是用户提供的，我这根本无法控制它。

1) 你说的“设置fb_status的值”，请问具体怎么设置。


2)
你说的“设置fb_status的值”， 那也是在新启动的 grldr中或者后面的菜单中做吧。
那都是用户的，我这根本无法控制这些。
如果
chainloader   --ud    /grldr
能就不同了。他只是提供一个初始环境——保留原来的(ud)。

mdyblog

不点 发表于 2015-2-26 03:47
我说的是现状，你说的是要改变现状，不是一个概念。很抱歉，我帮不了了，我退出这个话题。

下面是想说 ...

>>假如能够把这个问题做好，达到两全其美，那也是好事。
-------------------
我分析了下。 应该可以的。
1(ud)本身的问题。
由于(ud) 绑定的 是物理磁盘。
这样，没有map 动态调整的 麻烦。
因为 map 动态调整，不会调整 物理磁盘 号。

多个硬盘也没问题。
从硬盘启动时，总是0x80.  也不受map影响。


2grldr启动的时候，要检查是否从ud启动。如果是的，则把 ud 区当作当前 root 区
-------------------
这个也根本不是问题。这个是有规范的。
启动磁盘，本来就和(ud)没有一点关系。
启动磁盘 依据规范，是通过dl传递的。 传递的多少，就是多少。
启动分区，本来就和(ud)没有一点关系。
启动磁盘 依据规范，也传递过来的。 传递的多少，就是多少。不是有(ud)决定的。

只有从MBR启动时，或者类似情况。此时 分区号为255,表示没有分区，而从“整个磁盘”启动。
此时 才会 “检查是否从ud启动，如果是的，则把 ud 区当作当前 root 区”.

比如：
1) 从 (hd0,0)  chainloader  /grldr
此时指定了 分区号， 根分区和 (ud)无关。 根分区为(hd0,0)
此时，会继承原来的 (ud).  注意是继承的，而不是分析(hd0,0) 的这个hd0而得来的。


2) 从(ud)   chainloader  /grldr
此时，会继承原来的 (ud).  并用继承的(ud)作为root。
注意是继承的，而不是分析得来的。


3) 从(hd0)   chainloader  /grldr
（1）此时，会自动继承原来的 (ud).
         注意是继承的，而不是分析(hd0,0) 的这个hd0而得来的。

（2）如果没有开关禁止，
         如果逻辑磁盘(hd0) 对应一个物理磁盘或其头部，分析物理磁盘对应区域, 如果是完的(ud), "则把 ud 区当作当前 root 区"。 同时更新(ud)
         否则直接把(hd0)  "当作当前 root 区"。 （(ud).还是原来的（ud)）

（3）如果有开关禁止， 不分析逻辑磁盘(hd0), 直接把(hd0)  "当作当前 root 区" （(ud).还是原来的（ud)）

不点

mdyblog 发表于 2015-2-27 07:28
>>假如能够把这个问题做好，达到两全其美，那也是好事。
-------------------
我分析了下。 应该可以 ...

随便说说一点看法，供参考。

你可以自己打补丁，提交给 chenall。chenall 接到补丁后，可以先测试一段时间，如果放心，就会正式采纳。chenall 甚至也有可能为你单独开辟一个系列，就像以前为 yaya 单独开辟一个系列那样，进行长期的测试和评估。一旦成熟，大家自然会全面采用你的版本。

如果你自己不愿意做或者没时间做，可以等待别人去做。可以说服开发团队成员去按照你的思路完成任务。如果开发团队成员由于种种原因做不了，那你可以在团队之外寻求高手支持，完成开发任务。

mdyblog

请问  rawread（） 最后的 那个 魔术数 怎么填？
我的代码从 udm搬到UD后。 读  0扇区（就恰好一个扇区）就卡死了。

目前 我用的的是 0xedde0d90

rawread(0x80, 0,0,0x200, 0x200*0x200,  0xedde0d90);
这样就卡住了。 （经调试，boot设备是0x80)

chenall

mdyblog 发表于 2015-2-28 10:03
请问  rawread（） 最后的 那个 魔术数 怎么填？
我的代码从 udm搬到UD后。 读  0扇区（就恰好一个扇区） ...

rawread原型,
看原型应该很容易理解的,drive设备号,sector扇区号,byte_offset偏移,byte_len要读写的字节数,buf缓存区,write读写标志.

这个偏移比如你想读第一个扇区的0x1b8处的16个字节到内存0x40000处可以这样

rawread(0x80,0,0x1b8,16,0x40000,GRUB_READ)

1. int
   
2. rawread (unsigned long drive, unsigned long long sector, unsigned long byte_offset, unsigned long long byte_len, unsigned long long buf, unsigned long write)
   

复制代码

这个buf是一个内存地址,你0x200*0x200是什么意思?
write是读写标志.
用grub4dos.h的话可以使用GRUB_READ或GRUB_WRITE

最新版的grub4dos.h在这里
https://raw.githubusercontent.co ... /include/grub4dos.h

mdyblog

反应个现象，不知算不算BUG。
如果对U盘启动的ud 执行 geometry --lba1sector
后面读盘就死翘翘了。
先确认hd启动，不是fd。

1. geometry --lba1sector (128)
   
2. dd  if=(128)0+1  of=(md)0x200+1

复制代码

就死翘翘了。


没有geometry --lba1sector

1. dd  if=(128)0+1  of=(md)0x200+1

复制代码

就没问题。


Ver: grub4dos-0.4.6a-2015-01-18.7z

实例fba： 2015-0118.fba.zip (165.92 KB, 下载次数: 15)

2015-2-28 13:41 上传

点击文件名下载附件

qemu  模拟器中没问题。
实际U盘，在我的新旧2台机器上都是  死翘翘 。--------------急

mdyblog

chenall 发表于 2015-2-28 10:17
rawread原型,
看原型应该很容易理解的,drive设备号,sector扇区号,byte_offset偏移,byte_len要读写的字 ...

这么重要的东东，还是放在首页吧（链接）。

mdyblog

着急：
UD上 geometry --lba1sector 的问题。
914#

不点

mdyblog 发表于 2015-2-28 15:38
着急：
UD上 geometry --lba1sector 的问题。
914#

貌似着急也没用。你的主板 bios 不允许按单扇区读盘，你又有了新发现。祝贺。同时你分享给大家，大家也都能增加这样的知识。

当你发现更多类似的现象时，你的视野也就更开阔了，理解力也就进一步加强了。世上大概没有不可能的东西，只有尚未被发现的东西。

顺便说，会不会仅仅是 0.4.6 的 bug 呢？你能否确认 0.4.5 也有这个问题？

如果 0.4.5 没问题，赶紧请 yaya 修复 bug。

mdyblog

不点 发表于 2015-2-28 16:51
貌似着急也没用。你的主板 bios 不允许按单扇区读盘，你又有了新发现。祝贺。同时你分享给大家，大家也都 ...

不是主板 不支持。支持的。
只是用了UD后才出了妖蛾子。

以前一直用UDm， 不是UD， --lba1sector (128)一直用的好好的。
否则早就发现了。

最近做UD版， 同样的代码，才发现这个幺蛾子。


反复实验， 发现只有一种方式可以的。

1. calc *0x82A0=128
   
2. geometry --lba1sector
   
3. dd  if=(128)0+1  of=(md)0x200+1

复制代码

要的
1） 要用calc *0x82A0=128
root (128)不行的。

2）geometry --lba1sector  不能带dev
不能是  geometry --lba1sector  (128)

-----------------
这么奇怪，像是软件问题啊。否则 "root (128)不可以，calc *0x82A0=128“  "geometry --lba1sector 不带dev才可以"都说不过去的。
好像是UD混乱了。

不点

从 ud 启动后，直接进入 grldr，此时会混乱吗？

有多少个机器会出现混乱？

是不是由于你的部署方式太奇特了（这一点你自己最清楚），因而造成混乱？

0.4.5 有问题吗？（前面问过的，没有得到答复）

以上这几个问题，是想帮你定位问题的根源，不是让你回答的。你自己有测试环境，因此你可以找毛病。最好是死活都找不出原因，那样你就有更多的机会去折腾了，折腾的结果会让你的电脑技术得到大大加强。

2011yaya2007777

请 chenall 看看，今天打了一个补丁，上传到我的分支，不知为何没有进入你的主干。

mdyblog

不点 发表于 2015-2-28 18:24
从 ud 启动后，直接进入 grldr，此时会混乱吗？

有多少个机器会出现混乱？

1：从 ud 启动后，直接进入 grldr，此时会混乱吗
---------------
就是 ud 直接进入 grldr,
见 示例fba。  （fba不支持我的UDM扩展UD。我用的是标准UD测试的）

再在命令行 输入上面的命令。



2：有多少个机器会出现混乱？
我这就2台机器能USB启动， 都出这种 UD 幺蛾子。



3：是不是由于你的部署方式太奇特了（这一点你自己最清楚），因而造成混乱？
----------------
我是用的部署方法发现问题的。
为了方便交流。 上面的测试都是用标准UD。就是用J大的FBT。
为了说明是标准UD，我上面还附上了测试的FBA文件。


4：0.4.5 有问题吗？（前面问过的，没有得到答复）
----------------
我等会儿再补上。（干嘛要测这么多版本，挺烦的，难道不能就做好一个版本，并维护好.大家始终向都一个版本看齐。节省劳动，提高效率）

补上了。 grub4dos-0.4.5c-2015-02-09.7z
效果和0.46a一样。


5：以上这几个问题，是想帮你定位问题的根源，不是让你回答的。你自己有测试环境，因此你可以找毛病。最好是死活都找不出原因，那样你就有更多的机会去折腾了，折腾的结果会让你的电脑技术得到大大加强。
-----------------------
我却相反。
我只是希望尽快解决问题。至于提高“电脑技术”，已经不再是我的关注了。（每个人有自己的关注点，否则一事无成）
如果有人能解决，我就不折腾了。

不点

4：0.4.5 有问题吗？（前面问过的，没有得到答复）
----------------
我等会儿再补上。（干嘛要测这么多版本，挺烦的，难道不能就做好一个版本，并维护好.大家始终向都一个版本看齐。节省劳动，提高效率）

惹你烦了，实在抱歉。不过，我不代表开发者。我只是凭我的理解力来回复的。没有任何强迫的意思，这一点请了解。如果帮不到你，请忽略我说的话。至于说为什么维护多个版本，我的理解是，存在皆合理，它一定有理由，你不妨猜测一下它的理由是啥。我觉得你不难猜到。或者你也可以直接问问开发者，让开发者给你详细解释解释。

5：以上这几个问题，是想帮你定位问题的根源，不是让你回答的。你自己有测试环境，因此你可以找毛病。最好是死活都找不出原因，那样你就有更多的机会去折腾了，折腾的结果会让你的电脑技术得到大大加强。
-----------------------
我却相反。
我只是希望尽快解决问题。至于提高“电脑技术”，已经不再是我的关注了。（每个人有自己的关注点，否则一事无成）
如果有人能解决，我就不折腾了。

如果能够不折腾就把问题解决了，那是最理想的了。不过，事情往往不那么顺利。世上没有完美的东西，软件的 bug 会有很多。功能越多，产生 bug 的概率就越大。bug 就是人所犯的错误。错误是很难避免的。出现 bug，总得有人去折腾。有的 bug 能持续好几年才得到解决。

mdyblog

请教 --lba1的问题

1：
（hd0)或者 (fd0),设置了 --lba1。
在部分map (非ram)成的新盘， 还需要在单独--lba1吗？
感觉不需要， 因为新的设备只是一个服务入口而已，最终还是回到实际的BIOS盘。


2：FBT格式化的界面上的速度，和这个有关吗？界面上设为1，这里会有 --lba1的效果吗？
感觉不需要，因为界面上的选择这么多，g4d只有2个选择，对不上。

3: 如果 用 dd 或 rawread()， 其参数恰好是一个整扇区， 这样， 即使没有 设定--lba1。 也不会有多扇区访问的问题 ,是吗？
实际测试的感觉不是这样。--lba1后慢非常多。不只是 一次对几个扇区的问题，还有很多东西被禁止了。
其实，现在的磁盘，即使一个扇区一个扇区地读，本身不慢多少,一般的程序看不出多大差别， 因为磁盘本身有缓冲机制。
本身就会读取合并。

望赐教！

不点

1. 单扇区读盘的参数，是我设计的。它应该能够处理未经 map 的盘。至于说 map 之后，情况复杂，那涉及到修改 int13 handler，让其能够发现宿主母盘的单扇区读的特性，并采取单扇区读。这部分工作没有做，因为 int13 的代码空间已经达到 12K 的极限，没法再插入有关单扇区读的代码了。这就是说，在那些有问题的电脑上，用户只能凑合着使用 grub4dos，而不能获得全方位的支持。意思是说，在那些只能进行单扇区读盘的 bios 之下，用户使用不带 --mem 的 map 命令创建虚拟盘，则虚拟盘可能不是单扇区读的，这意味着，访问虚拟盘有可能造成死机。因此，在这种情况下，用户不可以使用不带 --mem 的 map 命令。很抱歉，这一点没有写在文档里面。不过，已经发现的 bug 机器很少，所以，一般情况下，可以忽略这个问题。chenall 设计了一个方法，用户在启动时快速按 S 键可以进入单扇区读模式。所以，第三方开发者和应用者们没必要关心单扇区读的问题了。用户在首次启动发生死机时，他会想到，需要调试。那么在调试选项里面，就有 S 键进入单扇区读盘模式。在启动之初一旦检测到用户按了 S 键，grub4dos 就自动设定启动盘为单扇区读盘模式。特别指出，当机器是从 ud 启动时，当前 root 分区是 ud，而此时执行 geometry --lba1sector ，将把 ud 的宿主盘设定为单扇区读盘模式。ud 盘和pd盘类似，都没有通常的扇区的概念。具有扇区概念的盘，那是 ud 的宿主盘，不是 ud 盘本身。ud 和 pd 都不是 bios 盘。

不点

2. fbinsttool 是否支持单扇区读盘参数设定。这个我不知道。我个人认为，通过 fbinsttool 设定单扇区读盘，固然会避免死机，但影响正常机器的启动速度。仅仅就这个话题而论，我认为采用我所开发的 multimbr，是目前最好的选择。multimbr 在第一阶段读取 grldr 的过程中，全部采用单扇区读盘。微软的 bios 启动代码也是单扇区读盘。与微软的做法保持一致，这样能够提高启动的成功率，能够尽量避免进入某个封杀陷阱。当grldr接管控制后，由用户负责设定单扇区读盘模式。当用户发现死机，那么下次启动时，就可以通过快速按 S 键来设定启动盘为单扇区读盘模式。所以，在 multimbr 的情形，开发者和应用者根本没必要管这个事了，这就简化了制作启动盘的逻辑，做到了既无参数设定，又能通吃所有的情况（当然了，新的 bios 攻击除外，人家掌握话语权，非要封杀，那没办法）。

不点

3. grub4dos 所提供的读盘函数，似乎都是 c 语言的。你只有直接调用汇编语言，才能实现你自己的单扇区读盘。

grub4dos 的 c 语言读盘，是采用缓冲区的。每次要读一个磁道。在 lba 的情形，每次读 127 个扇区。

所以，即使你只是要读一个扇区，grub4dos 实际上也要读 127 个扇区。只不过在单扇区读盘的情况，是分为 127 个 int13 调用，这当然很慢了。而在多扇区读盘的模式下，127 个扇区仅需一个 int13 调用，当然就很快了。

不点

2011yaya2007777 发表于 2015-2-28 18:25
请 chenall 看看，今天打了一个补丁，上传到我的分支，不知为何没有进入你的主干。

你这个帖子被后面的大量帖子淹没了。你最好开个新帖，提醒 chenall。

jianliulin

fbinsttool单扇区读盘只是影响fb本身，对grldr或者buldr没有影响

mdyblog

jianliulin 发表于 2015-3-1 07:57
fbinsttool单扇区读盘只是影响fb本身，对grldr或者buldr没有影响

1：
谢谢！！！
非常感谢。


2：
另外， 你知道 “UD 启动的 grldr, 开启 --lba1sector 模式，读盘就卡死了” 的原因吗？

mdyblog

不点 发表于 2015-3-1 06:43
3. grub4dos 所提供的读盘函数，似乎都是 c 语言的。你只有直接调用汇编语言，才能实现你自己的单扇区读盘 ...

1： 原来是这个原因。也就是读一个扇区，实际读127个！慢了127倍。

2：能提供其它函数， 或在提供一个开关，就让他不要一次连着读127个扇区。

3：
你只有直接调用汇编语言，才能实现你自己的单扇区读盘
试试。