grub4dos不支持固态硬盘吗,还是我的操作有误,机械硬盘也是只识别一个分区

不点

你有两个问题：

1、你自己的问题：你在使用 7 年前老掉牙的 grub4dos。
2、你的主板 BIOS 有缺陷，不支持访问大的扇区号，说得通俗一点，你的主板 BIOS 不支持访问盘的靠后部分，只能访问开头的一小部分。甚至你的主板 BIOS 完全不支持访问某个盘（比如固态硬盘）。在目前 grub4dos 的框架下，不可能解决此问题，因为 grub4dos 完全依赖主板 BIOS。

建议 1：修改你的菜单，不让它访问靠后的分区，这样还可以凑合着继续使用 grub4dos。
建议 2：也可考虑改用 UEFI 的启动方案（grub2），放弃 grub4dos。

不点

报错：太多的碎片

注意，如果 VHD 是压缩文件格式，则可能会出现这个问题。

你的 map 是不带 --mem 的，就是说，你是“直接”映射为虚拟盘。在这种情况下，vhd 文件不可以是压缩格式，也就是说，不可以是 gz 、zip、lzma 之类的格式，而只能是整个磁盘（按照扇区顺序）的精确拷贝（或者叫做克隆），不可以在克隆以后，又对 vhd 文件实施任何种类的压缩操作（务必注意！）。


另外，你可以用


blocklist   /vhdxp/winxp.vhd


来列出这个文件的碎片。如果这条命令无法成功执行，那很可能就表明，你这个文件不是“平坦的、普通的”，而是“压缩的”。如果能够成功执行，它会列出碎片的详情。

不点

楼主报告问题很详细，很有耐心。（如果是我，我可不会有这么详细。）

因此，我乐意帮忙。

你报告 RAM 镜像超过 2G 会有 7b 蓝屏。我大致能猜到原因了。

我猜，当镜像超过 2G 时，鉴于你把镜像加载在 4G 以下的内存空间，由于它超过了 2G，而在你特定的这个有毛病的主板之下，正好与你的某个 BIOS 内存发生了冲突，导致 07b 蓝屏。

解决方法是：把镜像加载在 4G 以上的高位内存，避免与 4G 以下的内存发生冲突。

在你的 map 命令中，添加 --top 参数，可以达到上述目的：

map   --mem   --top   /vhdxp/winxp.vhd   (hd0)

或者用下面这句（互换两个选项的位置）也是一样的效果：

map   --top   --mem   /vhdxp/winxp.vhd   (hd0)

不点

嘿！咱就不怕它失败！咱怕的是它不失败！它失败了，咱好折腾啊。

吹牛归吹牛，问题能否解决，咱还真没把握 :-(

就把这个论坛当成是聊天室吧。咱随便聊。

既然随便聊，咱就随便说，不要太认真。

2G 克隆到 3G，用 --top 不行。这似乎暗示，--top 本来就不行。

先验证这个结论是否成立，用 2G 的映像，带有 --top 加载在高位内存，试试是否成功。


按照刚才的猜想，它同样会失败。

执行完 map 命令之后，可以执行一下

map   --status

命令，这会显示出，映像究竟加载到哪个内存地址处了。

再说明一点，--top 和 --mem 的顺序无关紧要，只需试验一种情况（比如 --mem  --top）即可，没必要两种情况( “--mem  --top” 和 “--top  --mem”)都去试验。

关于 blocklist 的输出，显示的结果 x+y 表示映像起始于扇区 x，占用 y 个扇区。这说明只有一个碎块，也就是说，是连续的，没有碎块（只有一个碎块就等于说是没有碎块）。

如果有碎块的话，会显示成这样：

x1+y1,x2+y2,x3+y3

这表示有三个碎块。多个碎块，依此类推。


补充一点


既然初步确定这是个与内存冲突有关的问题，那就用

displaymem

命令显示一下 BIOS 的内存块分布情况，这很要紧。

这条命令可以在 map 之前执行，也可以在任何其他时候执行，显示结果都是一样的。

-----------------------------------------------

假如结果和我猜的一样，即 2G 用 --top 发生了失败，那么接下来试试


map   --mem=-6291456   --top   /vhdxp/winxp.vhd   (hd0)


注意“--mem=-6291456”是连成一串的，中间不含空格；而且等号后面是个负数。


如果仍然失败，再试试 “--mem=-8388608”，仍然是负数，不过绝对值增大了。


如果这样试验侥幸能成功的话，你可以针对你的 3G 映像来做同样的试验了（3G 映像只需测试“--mem=-8388608”这一种情况）。

不点

从 displaymem 的显示，看到 4G 以下有

Usable RAM：Base：100000，Length：96D3F000 ----- 这就是 2471164K，也就是 2.47G。

这说明，在 4G 以下的空间，你最大可以放置的 img 的大小就是 2.47G。

在 4G 以上的空间，是连成一片的：

Usable RAM：Base：100000000，Length：35FE00000 ----- 长度大约是 13G 多。

这个 BIOS 的内存块分布，很正常。

比如说，在 4G 以下，它的全部 Usable RAM 都集中在 2.47G 这一块上了，而不是像某些恶意 BIOS 制造商，把它破分成若干个 512M 的小块。而在 4G 以上，也全部都是 Usable RAM，没有 Reserved，这都没有表现出“作恶”的迹象。

当然了，作恶的地方，可以有很多；此处不作恶，而在别处作恶的可能性当然也是存在的。

为什么把 img 放在 4G 以上的那个巨大空间里面会失败？

有两种可能：

1、4G 以上的内存，在物理上不可靠（或者说，内存条有问题）。

2、软件问题，譬如说，进入 Windows 之后，某个 Windows 驱动程序有问题，毁掉了我们的 img 数据，导致该虚拟盘无法访问，从而出现 07B 蓝屏。这种可能性有无限多，很难猜测具体是哪个驱动程序导致的。甚至一个普通的流氓软件，也可能毁掉我们放置在高位内存上的 img 数据。所以，从软件的角度，没法猜测具体问题出在哪里。（特别提醒，有这样的可能性：你的固态硬盘驱动程序以某种方式破坏了 4G 以上的高端内存，使得我们的 img 虚拟盘数据损坏或不可用，从而出现 07b 蓝屏；如果是这种情况，那就无解了）。

最后，你再试试这两个：

map   --mem=-28307456   --top   /vhdxp/winxp.vhd   (hd0)

以及

map   --mem=-27258880   --top   /vhdxp/winxp.vhd   (hd0)

意思是，假定内存条的顶部损坏了，只使用低端部分，看看效果怎样。只需对 2G 的 img 进行测试即可。

不点

那就基本能够说明，4G 以上的高位内存不可使用。

剩下的事，也就是如上所说，检查内存条硬件是否有问题；确定固态硬盘是否是问题的根源，等等。

内存条很容易检查，你可以更换内存条。

而软件冲突，不容易检查。

不过，如果你用本地硬盘（不使用固态硬盘）没问题的话，那就可以证明内存条硬件没问题，而是固态硬盘带来的不兼容问题。这些太复杂，需要你自己再探索一下，本人能力所限，也就帮不上忙了。

不点

对不起，突然想到另一个问题。

winvblock 不支持 4G 以上高位内存。

你是不是在用 winvblock？

你应该用 firadisk 才行。

不点

chenandjun 发表于 2020-9-10 13:52
是winvblock,是看坛子上的贴子跟着弄的，winvblock不支持吗，那我晚上回去再弄，到时再汇报

太好了，这就找到原因了。我们走了很多弯路，就是因为这个细节。细节决定成败，做事情必须认真。


firadisk 和 SVBus 都支持 4G 以上高位内存。


只有 WinVblock 不支持。我对这些驱动程序的原理不太了解。好像有人说过，它也并非完全不支持，而是依赖于操作系统是否支持 4G 以上高位内存。如果你的 Windows 操作系统是 64 位的，那 winvblock 也支持 64 位内存。如果操作系统是 32 位的，那么 winvblock 也只支持 32 位内存。


就是说，winvblock 不是“铁定”支持 64 位的内存。



而 firadisk 以及 SVBus 都是“内建”支持 64 位内存，与操作系统是否为 64 位是没关系的。换句话说，只要 CPU 支持  64 位内存即可。


firadisk 较旧，SVBus 较新。


我建议你先试试 SVBus，如果不能搞定，再试试 firadisk。

不点

chenandjun 发表于 2020-9-10 16:15
好，svbus也像winvblock一样，装个驱动就可以吗

实在抱歉，本人全都不曾用过。

firadisk、winvblock、svbus

三个软件，本人从未自己操练过。

没法提供经验。

你需要查找相应的资料。

svbus 出现较晚，据说是结合了 firadisk 与 winvblock 的优点，是集大成者。

但究竟怎么个使用方法，你得花时间搜索、学习、试验、研究了。

不点

map /vhd/winxp.vhd (hd0)  是把 vhd 映射为虚拟盘 hd0

map (hd0) (hd1) 是把真实盘 hd0 映射为虚拟盘 hd1，这是因为，前一句执行后，虚拟盘 hd0 还没开始起作用（要等到 map --hook 以后才会起作用），所以，此时，hd0 仍然是你内置的真实硬盘 hd0。

如果没有 map (hd0) (hd1) 这句，那么，当你执行 map --hook 之后，你在 grub4dos 环境下就无法访问你的真实硬盘 hd0 了，这是因为，每当你想访问 hd0 的时候，grub4dos 都会给你提供虚拟盘 hd0 的数据，也就是 vhd 的数据，因此，你的真实硬盘，就被隐藏了，无法访问了。

有了 map (hd0) (hd1) 这句，那么，当你执行 map --hook 之后，你就可以通过访问虚拟的 hd1 硬盘来访问原始的真实硬盘 hd0 了。

不点

map --status 是希望看到 map --mem --top 加载的内存位置。

可是，你给的图，都不带 --top，所以，看不到想要的结果。

displaymem 里面，reserved 是 BIOS 系统保留内存，任何用户程序都不可以随便碰它。只有 usable RAM 才是可供各类应用软件随便使用的。

不点

嗯，理解了就好。如果你事先有 map  (hd0)  (hd1) 的话，在 map --hook 执行以后，你就可以用 “ ls  (hd1,0)/ ” 来列出 360SANDBOX 以及 Users 等目录了，它们是在你的真实盘上。你的虚拟盘上有 svbus 目录以及 ntldr，而真实盘上没有这些。稍稍留意，是可以看出差别的。

map --status 显示的 Start Sector （起始扇区号）为

0x1EFEFF8 （单位是 512 字节的扇区）= 0x1EFEFF8 × 0x200（单位是字节） = 0x3DFDFF000（字节）=16640897024（字节）

也就是说，它起始于大约 16G 处。

显示的 Sector Count （占用的扇区数）为

0x400008（单位是 512 字节的扇区）= 0x400008 × 0x200（单位是字节） = 0x80001000（字节）=2147487744（字节） 也就是说，长度大约 2G。

映像的尾部，位于

0x1EFEFF8 + 0x400008 = 0x22FF000（扇区）=0x22FF000 × 0x200 （字节）=0x45FE00000（字节）

这与你 displaymem 显示的最后一行的终止位置相同。

这跟预想中的一样，很正常。

不点

你的报告，同时也证明了（至少在 WinXP 的情况下） winvblock 不支持 4G 以上内存，而 svbus 是支持的。这会给其他人提供有益的线索，让他们少走弯路。

如果你想让这个问题有个更加完整的答案，你也可以试试 Win7 （64 位），目的是验证 winvblock 是否在 64 位的操作系统之下能够支持 4G 以上的高位内存。无论支持还是不支持，结论都有用，都有价值。

不点

关于 winvblock 的 map 不带 --mem 的情况，你只试验了 --e820cycles=-1，没有试验 0, 1, ...
这还不能断定 winvblock 不支持直接 map（即，不带 --mem）。

不过，从你的测试中，--mem 已经支持，而 --mem --top 却失败，这应该基本算是证明了 winvblock 不支持 64 位内存（也就是不支持 4G 以上的高位内存）。为什么说只是“基本”证明呢？因为你这是精简版的，假如 winvblock 严重依赖操作系统的完整性，那么，当操作系统不完整时，它就可能无法支持高位内存。所以，上述证明也只是初步证明，并非完整证明。

算了，初步证明也就够了，不需要完整证明。这是因为，在同等条件下，svbus 能够成功，而 winvblock 却不能成功，这最起码说明了，svbus 的内存处理函数比 winvblock 更稳健。我猜测，winvblock 的高位内存访问是依赖于操作系统的相关函数。如果操作系统不是完整的，它就可能无法工作。而 svbus 的高位内存处理，可能是内建的，不依赖于操作系统。

不点

补充提醒一个小的细节。--top 参数只能与 --mem 配合使用，才有意义。如果没有 --mem 而只有 --top，那么这个 --top 就不起作用，就跟不存在 --top 是一样的。

另外，看到你的 svbus 在 win7 中不需要使用 e820cycles 参数了。这似乎验证了 “win7 的显卡驱动比 xp 的显卡驱动更稳健”这个说法。

我感觉，似乎全部的测试都完成了。

辛苦了，可以歇歇了。

不点

你在前面曾经提到一个问题，即，如何建立一个内存盘。

这里简单说说，确实可以建立一个空的内存盘。以下是举例：

map   --mem    (md)+8   (fd0)   把物理内存开头的 8 个扇区复制到 4G 以下的某个可用内存块（Usable RAM）中，虚拟为第一个软盘 fd0。这 8 个扇区的数据是无用的，但 map 命令需要至少 8 个扇区。由此建立的虚拟软盘也只有 8 个扇区的大小。

map   --mem   --top    (md)+8   (fd0)   把物理内存开头的 8 个扇区复制到 4G 以上高位内存的某个可用内存块（Usable RAM）中，虚拟为第一个软盘 fd0。其他解释同上。

可以用 --mem=-XXX 的方式，为内存盘分配足够的内存。举例如下：

map   --mem=-2880    (md)+8   (fd0)   把物理内存开头的 8 个扇区复制到 4G 以下的某个可用内存块（Usable RAM）中，虚拟为第一个软盘 fd0。这个操作会保证内存盘至少有 2880 个扇区，也就是，至少有 1440 KB 的大小。复制的动作，会把物理内存开头的 8 个扇区复制到 2880 个扇区中的开头的 8 个扇区上，复制完就结束，其后的部分不会碰，也就是说，不会把 00 之类的字节写入其后的 （2880 - 8）个扇区上。

map   --mem=-2880   --top   (md)+8   (fd0) 与前一个例子类似，只不过是在高位内存块中创建虚拟内存盘。

当然，也可以创建内存硬盘，例如(hd0), (hd1)，以及内存光盘，例如 (hd32), (0xFF)。

像上述例子那样创建了内存盘后，可以进入操作系统，再对该盘进行格式化。windows 需要 svbus 之类的驱动，才能操作这些内存盘。

在上述例子中，你不需要了解你的内存盘究竟被安排在内存中的何处了。你只需要提供一个扇区数即可。

不点

关于 --top 再澄清一些细节。

如果 map 命令行中只有 --mem 而没有 --top，则肯定只把该映像加载在 4G 以内的内存块上（注意，旧版 grub4dos 仍然有可能加载在 4G 以上；请不要使用旧版）。新版不可能加载在 4G 以上。因此，如果你在使用 winvblock，那么你正好就不该使用 --top 选项，而只能使用 --mem 加载在 4G 以内的低位内存上。

如果 map 命令行中有 --mem --top 选项，则映像会首先尝试加载在 4G 以上的空间。如果 4G 以上没有足够的空间（或者 4G 以上根本就不存在内存空间），那么会尝试加载在 4G 以内的空间。

这就是说，无论你的电脑是否有内存块位于 4G 以上，你都可以使用 --mem --top 选项。

总结一下：

1。不含 --top 时，肯定加载在低端内存。

2。含有 --top 时，有可能加载在高端，也有可能加载在低端（当然先尝试高端，后尝试低端）。

不点

好的，终于令人伤心地证明了，winvblock 不支持高位内存，也不支持不带 --mem 的普通 map。

提醒一下，在测试完

map    /.../.../file   (...)

之后，不需要再测试

map    --top    /.../.../file   (...)

了，上述两行是等价的，没有差别。因为如果没有 --mem 的配合，单独的 --top 就不起作用。就是说，如果没有 --mem，那就不要使用 --top，即使你使用了，也跟不存在 --top 是一样的。

不点

chenandjun 发表于 2020-9-17 14:14
好的，知道了，老大能不能给我一个grub4dos像你讲的这样详细的教程

置顶的教程就不错。

grub4dos 自带的 readme 文件。

也有一些英文教程会更细致一些。以下有些网页比较陈旧，请选择阅读。

不过，需要严重提醒的是：电脑制造商正在淘汰（其实是封杀）旧的 BIOS，推行新的 EFI 启动规范。因此，即使学了 grub4dos，很可能发现越来越没用了。因此建议不要学了，只有当你非学不可的时候再去学。可以留意 grub2 以及 grub4EFI，这两者能够支持 EFI。

https://www.rmprepusb.com/tutorials/grub4dos

https://www.easy2boot.com/faq-/grub4dos/

http://xpt.sourceforge.net/techdocs/nix/disk/boot/boot07-GrubForDosInfo/ar01s03.html

http://microsaint.narod.ru/_Info_Grub4Dos/Grub4dos_tutorial.html

http://www.owl.homeip.net/manuals/systems/dos/grub4dos/Grub4dos.htm

不点

liuzhaoyzz 发表于 2020-10-28 08:00
哦，我的说法不对。
winvblock、firadisk和SVBus都可以把grub4dos在实模式下创建的仿真内存盘带入Window ...

大家知道著名的 imdisk 虚拟盘软件。这个软件，也能在 Windows 下创建虚拟盘，而且，也能在 Windows 下创建用内存虚拟出来的盘。岁数大了，记不清楚 imdisk 是不是开源的了。

不点

高位内存启动，winvblock是不支持的，这些都是已知的，为什么还要反复测试？

我想说明几点：

1、首先是我的错，我要求楼主进行测试。也许是我印象模糊了，印象中，在英文网站 reboot.pro 上似乎有人说过，winvblock 支持 4G 以上的高位内存。因此，我也就顺理成章地让楼主进行了测试。其实，到目前为止的这些测试，也并不能 100% 肯定 winvblock 不支持 4G 以上的高位内存。只能说，在测试的范围之内，没能支持。就是说，不支持的概率较高，比如说，达到 95% 以上吧。

2、由于对问题的判断不准确，我已经让楼主走了一些弯路。这一点，前面也曾经提到了。

3、在 grub4dos 0.4.6 中修改 --top 的含义，原先 --top 是 “从高向低搜索内存块” 的意思，修改后变成 “允许使用 4G 以上的高位内存块” 的意思。这个变动，在根本上就是为 winvblock 服务的，这一点，我给忘却了。证明是我岁数大了，痴呆的表现。当时正是由于发现了 winvblock 不支持 4G 以上高位内存，才用这种办法来屏蔽高位内存块的。就是说，在 0.4.6 新版中，在不带 --top 的情况下，就一定不会使用高位内存块，而只使用低位内存块，这样就照顾了 winvblock。如果不是为了照顾 winvblock，那是根本就不会费劲去更改 --top 的含义的。一般来说，更改的动作可能会造成应用层面的不兼容。为了让不良影响降到最低，当时进行了大量的讨论。以上确实是我老年痴呆的问题，竟然都忘却掉了。但后来，我模模糊糊地有印象，似乎有人提到 winvblock 支持 4G 以上高位内存，是说在操作系统为 64 位的情况下支持高位内存。

4、关于 e820cycles 参数，liuzhaoyzz 说得对。其实，我并不知道对不对，因为我个人没有使用经验，我也不知道 win7 底下的应用情况。我在 Windows 下从不使用 map 出来的虚拟盘，因此，我完全没有经验。但感觉 liuzhaoyzz 说的对。e820cycles 当初就是为了解决 XP 的显卡驱动在 map 之后蓝屏的问题。印象中，确实有人指出，Win7 底下的显卡驱动已经没有这种蓝屏问题了。但是，e820cycles 参数，并非只能用于解决显卡的蓝屏，它是有可能用来解决其他种类的蓝屏的，比如说，网卡或声卡，或其他有 bug 的硬件驱动。当然了，真正有 bug 的硬件驱动，或许碰巧只有 XP 的某种型号的显卡而已。