grub4dos 在 cd (iso) 上的一個問題

hodgestructure

我以前用 2010-01-04 版本的 grub4dos。主要有兩種方式。

第一種是利用 grubmenu.exe 將 menu.lst 的內容寫入 grldr，再將 grldr 寫入 iso 的引導。

這樣的方式在換到 2010-01-22 版本後，一直到 2010-05-03版，在開機後 (用 vmware 做測試)，需要更長的時間 (差不多九秒) 才會顯示 menu.lst的內容。在 2010-01-04 和 2010-01-21 之中所有版本的 grldr，都是差不多一到二秒就會顯示 menu.lst 的內容了。

另一方面，如果我不把我自已編輯的 menu.lst 寫入grldr，而是將我從網路上下載的 grldr 寫入 iso 的引導，在 2010-03-09 版本之後，會出現

Minimal Bash-like line editing is supported. For the first word, TAB lists possible command completions.
Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits.
grub>

，然後就停在這裡了，不會自動去尋找 我放在 iso 檔裡面的 menu.lst。
在 2010-01-04 到 2010-03-01 中間的版本，都會去尋找我的 menu.lst。

我想知道為什麼會這樣，以及如何讓最新的 grldr，能夠自動尋找我放在 iso 裡的 menu.lst，並且不會有第一個問題當中出現的速度減慢。

麻煩大家了，謝謝。

ypy121

map --mem (cd)/*.ISO (0xFF)
map --hook
config /menu.lis
时下 哈

不点

速度减慢，以及出现的其它稀奇古怪的问题，都有可能是制作 iso 的软件的问题。

mkisofs 能够把启动文件安排在光盘的最开头，使得在光盘上查找扇区不费周折，速度也可能加快。

ypy121

原帖由 不点 于 2010-5-7 09:10 发表
速度减慢，以及出现的其它稀奇古怪的问题，都有可能是制作 iso 的软件的问题。

mkisofs 能够把启动文件安排在光盘的最开头，使得在光盘上查找扇区不费周折，速度也可能加快。

哦  那用ui 怎么设置才好？

hodgestructure

我也懷疑過是 ultraiso的問題。但是為什麼早一些版本的 grldr 製作起來，完全沒有問題。而是在 2010-01-22 和 2010-03-01 之後才出現這問題呢。不過有時間我還是會試一下 mkiso的方式。

sratlf

吧这个注册表文件导入进去  把iso文件另存  再试试看行不行

hodgestructure

我後來用了 mkiso 做測試，發現主要的問題所在了。

我的 menu.lst 一開始寫著 :

splashimage /boot/face.gz
timeout 1
default 0

我的 iso 檔根目錄下，有一資料夾 boot，裡面有著 face.gz 和其它檔案。

這樣的情況下 (利用 mkiso來製作 iso檔)，使用 2010-05-03 版本的 grldr ，開機後，至少八秒才能顯示出 menu.lst 的內容。

如果我把 face.gz 刪除掉，一開機，1~2秒內馬上就出現 menu.lst 的內容。

如果是 2010-01-21 之前版本的 grldr，無論是否有放入 grldr，一開機都會很快出現 menu.lst 的內容。

另外一點，如果我是用 grldr 來啟動我的實體機，(也是有放 face.gz)，2010-05-03 版本的 grldr 不會有這個問題。

我查了一下，2010-01-22版本寫著 : applied karyonix's patch

不知道是不是這樣照成的問題。

是否有人也可以測試一下呢?
ps. 我是用下面的指令來制作 iso

mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root

不点

感觉这问题应该与 karyonix 的 PAE 内存仿真代码改造无关。根据你所反映的情况，问题似乎是在 face 图像的加载过程中。我觉得这个问题的根源似乎不在此处，虽然其表现似乎在此处。

考虑 face 文件是否被放在了光盘的末端？什么原因造成 face 文件的读取费时了？这也许会有别的原因。

光盘介质的访问速度本来就很慢。磁盘介质就很快。所以，光盘上文件的物理位置或许很敏感。

试试不用  -boot-load-size 4 ，看看有无变化？

同一张光盘，换一台机器试验，看看是否有变化？

－－－－

karyonix 似乎还改造了 gz 文件的加载代码。所以，你还可以试试不用 gz，直接用未经压缩的 face 文件，看看是否正常了？

[ 本帖最后由 不点 于 2010-5-7 23:48 编辑 ]

hodgestructure

我把 face.xpm 放到 (cd)/boot 裡面，然後把 menu.lst 第一行改成

splashimage /boot/face.xpm

以及將  -boot-load-size 4 去掉。

這兩種都無法解決問題。

另外我是製作成 iso 檔案後，用 vmware workstatation 來做測試的。應該不會有光盤的問題。

希望大家能夠再測試一下，看是不是我自已的問題。還是真的有這樣的問題存在。

不点

对的，请其他朋友在方便时也帮助测试一下，看看 vmware 和其他虚拟机是否都有一样的问题。

如果用未经压缩的 xpm 图片测试，问题依旧，那就说明，这个问题与 gz 文件的处理无关。

將 -boot-load-size 4 去掉，照样存在问题，这又说明，问题不是由加载 grldr 的过程引起的。

karyonix 的 PAE 补丁，也与 splashimage 命令无关。

因此只能怀疑在加载 CD 上的文件时出现了问题（在加载硬盘文件时没有此问题）。

但究竟怎么会出问题，还是未知的。所以问题很奇怪。

现在换一个虚拟机测试，看看是不是虚拟机引起的问题。先前就有不少报告，说 VMware 存在问题。

用 qemu 和 Virtualbox 试验一下。

hodgestructure

多謝。我會找時間試試的。也請各位方便時幫忙一下。

hodgestructure

我用 sun virtualbox 測試了。結果 2010-01-21 版本的 grldr， 在 vmware workstation 不會有速度減慢的問題，在 virtualbox 速度變慢了，快 15 秒才能顯示出 menu.lst 的內容。2010-05-03 版本的 grldr，在 virtualbox 下，速度則是跟 2010-01-21 在 virtualbox 下差不多。


估記是同樣的 iso (同樣的 grldr)，在不同的硬體下，表現出來的效能也不一樣。

leebaker

怎么不用真实机,偏要用虚拟机

hodgestructure

最前面一篇說過了，我的實機測沒問題，但不是用光碟，而是將grldr安裝到mbr上。

不点

这个结果，似乎表明，grub4dos 没问题。谢谢了。

我可否怀疑，操作系统 host 主机在 guest 客机申请磁盘访问的时候，有了延迟？从而导致 guest 客机的时间延迟？尤其是在 guest 客机处于 BIOS 实模式的阶段。说不定操作系统利用这段延迟在为 guest 客机分配（大量）缓冲，以便客机下次访问虚拟光盘的时候能够更快速一些。

如果 grldr 文件和 face 图片位于同一个缓冲地带，则它们可能只需要一次缓冲，所以，碰巧在加载 face 的时候就不需要时间了。而假如 face 与 grldr 以及 menu.lst 在物理扇区位置方面相距较远，那么就可能在读取 face 时需要一次额外的缓冲。这样的话，就消耗了多余的时间。

ypy121

原帖由 不点 于 2010-5-8 23:39 发表
这个结果，似乎表明，grub4dos 没问题。谢谢了。

我可否怀疑，操作系统 host 主机在 guest 客机申请磁盘访问的时候，有了延迟？从而导致 guest 客机的时间延迟？尤其是在 guest 客机处于 BIOS 实模式的阶段。 ...

这都想的到 佩服。哈

xjn147

经过我的反复测试,基本与grub本身无关,最大的问题还是在镜像制作上