无忧启动论坛
标题: 为什么U盘引导ubuntu live ISO 出错？ [打印本页]
作者: wlsk888 时间: 2022-11-10 16:02
标题: 为什么U盘引导ubuntu live ISO 出错？
菜单为：
root （hd0,0）
kernel /vmlinuz boot=casper iso-scan/filename=/ubuntu.iso locale=zh_CN.UTF-8
initrd /initrd
启动最后，显示错误：
Unable to find a medium containing a live file system
希望大佬们帮忙？
作者: caocaofff 时间: 2022-11-10 16:13
提示没找到ISO文件，路径不对？
作者: liuzhaoyzz 时间: 2022-11-10 17:12
本帖最后由 liuzhaoyzz 于 2022-11-10 17:15 编辑
#grub4dos
title /linux/ubuntu/ubuntu-20.10-desktop-amd64.iso
find --ignore-floppies --ignore-cd --set-root /linux/ubuntu/ubuntu-20.10-desktop-amd64.iso
map /linux/ubuntu/ubuntu-20.10-desktop-amd64.iso (hd32)
map --hook
kernel (hd32)/casper/vmlinuz boot=casper iso-scan/filename=/linux/ubuntu/ubuntu-20.10-desktop-amd64.iso noprompt noeject
initrd (hd32)/casper/initrd
#grub2
menuentry "/linux/ubuntu/ubuntu-20.10-desktop-amd64.iso-loopback.cfg" "/linux/ubuntu/ubuntu-20.10-desktop-amd64.iso" {
search --no-floppy --set --file $2
export iso_path=$2
loopback -d loop;loopback loop $2
set root=loop
configfile (loop)/boot/grub/loopback.cfg
}
menuentry "/linux/ubuntu/ubuntu-20.10-desktop-amd64.iso" "/linux/ubuntu/ubuntu-20.10-desktop-amd64.iso" {
set gfxpayload=keep
search --no-floppy --set --file $2
loopback loop $2
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/linux/ubuntu/ubuntu-20.10-desktop-amd64.iso noprompt noeject
initrd (loop)/casper/initrd
}
作者: wlsk888 时间: 2022-11-10 18:34
grub.cfg是在(hd0,1)的/EFI/GRUB/目录下的
而ubuntu.iso是放在(hd0,0)的/PE/目录下的
这个应该怎么改？
你的我改成
find --ignore-floppies --ignore-cd --set-root /pe/ubuntu.iso
map /pe/ubuntu.iso (hd32)
map --hook
kernel (hd32)/casper/vmlinuz boot=casper iso-scan/filename=/pe/ubuntu.iso noprompt noeject
initrd (hd32)/casper/initrd
运行最后提示，找不到/pe/ubuntu.iso
could not find the iso /pe/ubuntu.iso
作者: liuzhaoyzz 时间: 2022-11-11 07:56
本帖最后由 liuzhaoyzz 于 2022-11-11 08:12 编辑
/pe/ubuntu.iso所在的分区是什么分区？
比如ntfs,ext4?
你用的grub4dos版本是多少的？启动的时候在屏幕的顶端可以看到，建议用最新版本。
grub.cfg是在(hd0,1)的/EFI/GRUB/目录下的
grub.cfg是grub2的引导菜单，你的菜单是grub4dos的，grub4dos的引导菜单是/menu.lst.
grub4dos_UEFI的引导菜单是/EFI/grub/menu.lst
你倒底是BIOS，还是UEFI启动？BIOS/UEFI启动，vmlinuz应该改成vmlinuz.efi,看下你的ubuntu.iso里面的名字。
作者: wlsk888 时间: 2022-11-11 16:05
我打错了，确实是menu.lst，ubuntu.iso所在分区是exFat，采用UEFI启动，ISO里面是vmlinuz和initrd
如果我用grub2的Partnew方式启动过这个U盘里的ubuntu.iso
上面的出错GRUB4菜单命令就会正常启动这个UBUNTU了，原因未知。。。
作者: liuzhaoyzz 时间: 2022-11-11 16:10
本帖最后由 liuzhaoyzz 于 2022-11-11 16:11 编辑
按说grub4dos是支持FAT32/NTFS/EXFAT/UDF/ISO9600/EXT2/EXT3/EXT4分区的呀，为啥会找不到/pe/ubuntu.iso？？？奇怪。
另外ubuntu-livecd是否支持exfat，还有待验证，我测试了放在NTFS分区是没问题的。
对于ubuntu这种发行版，启动脚本init/systemd过程中能够完美支持挂载ubuntu.iso，iso-scan/filename=/pe/ubuntu.iso就是干这事儿的，不建议采用partnew方式启动！
你还没有回答我的问题，你用的grub4dos版本是多少的？开机启动的时候屏幕顶端可以看到的。
作者: wlsk888 时间: 2022-11-11 17:19
grub4dos for_uefi 2022-01-18
作者: liuzhaoyzz 时间: 2022-11-11 17:32
1、换用最新版本的grub4dos for_uefi .
2、UEFI启动，vmlinuz应该改成vmlinuz.efi,看下你的ubuntu.iso里面的名字。
作者: wlsk888 时间: 2022-11-11 17:54
已换用最新2022-9-15的uefi
并且iso分区已经格成ntfs
ubuntu是18版本。ISO里面的casper/目录下没有vmlinuz.efi啊
启动最后，还是显示错误：
Unable to find a medium containing a live file system
作者: 飞黄腾达9 时间: 2022-11-11 17:59
ISO 出错？
作者: wlsk888 时间: 2022-11-11 18:02
我换官网下载的ubuntu 20版本也是一样
作者: liuzhaoyzz 时间: 2022-11-12 11:07
把ubuntu.iso放在本地硬盘，试试看，是不是iso下载过程中出错了？或者优盘读写有问题？iso的md5校验值对吗？
作者: 不点 时间: 2022-11-12 14:00
本帖最后由 不点 于 2022-11-12 14:03 编辑
liu 版主，假如 ubuntu 不再支持 isoscan/filename=..... 这个参数呢？
找不到 iso 文件的信息，是 ubuntu 的启动代码发出的，不是 grub4dos 发出的。
grub4dos 能把控制权递交给 ubuntu，任务就完成了。后续的事，与 grub4dos 无关。
grub4dos 的鞭子再长，也不能伸到 ubuntu 的里面去操纵 ubuntu 的启动过程。
作者: liuzhaoyzz 时间: 2022-11-12 14:23
本帖最后由 liuzhaoyzz 于 2022-11-12 14:42 编辑
不点 发表于 2022-11-12 14:00
liu 版主，假如 ubuntu 不再支持 isoscan/filename=..... 这个参数呢？
找不到 iso 文件的信息，是 ubun ...
最近的几个ubuntu发行版，15-20都是支持isoscan/filename=启动参数的，我测试过几个版本都支持。以后估计ubunbtu应该也不会放弃。
could not find the iso /pe/ubuntu.iso这样的提示应该是grub4dos抛出的，我分析要么是楼主的路径或者文件名写的不对，要么是优盘有问题。
Unable to find a medium containing a live file system这样的提示应该是ubuntu抛出的。到这里的话可能就是ubuntu的问题，比如文件分区格式不支持extFS/NTFS，可能放在FAT32/EXT分区就可以。debian_livecd就是这样子，不支持extfs/NTFS，抛出类似的错误。
也可能是启动参数变化，启动参数变化楼主可以看看ubuntu.iso里面的grub.cfg启动菜单，或者是isolinux菜单，照葫芦画瓢即可解决问题。
看下是不是initrd名字写的不对，看下iso里面是不是叫做initrd.lz？
作者: 不点 时间: 2022-11-12 14:40
我刚刚注意到，他在使用 UEFI。
UEFI 下的 光盘仿真命令，与 bios 下一样吗？
我看他的写法，完全是 bios 下的写法。
liu 版主，您熟悉 UEFI 下的 grub4dos，那么，究竟与 bios 下的写法一样不一样呢？
作者: liuzhaoyzz 时间: 2022-11-12 14:50
本帖最后由 liuzhaoyzz 于 2022-11-12 14:57 编辑
不点 发表于 2022-11-12 14:40
我刚刚注意到，他在使用 UEFI。
UEFI 下的 光盘仿真命令，与 bios 下一样吗？
BIOS/UEFI版本的grub4dos，命令方面从最终用户来说感觉不到有太大的区别，这与yaya的努力有关。比如常用的graphicsmode,find,map,kernel,initrd,chainloader这样子的命令。其他的命令ls,geometry,cat,displaymem,uuid等等感觉没啥变化。
略有区别的可能是内部变量地址变了，这块我基本没有涉及到，我只是用前面的几个常用命令。
g4d用户可以无缝切换到g4e，区别就是在作为第一引导的情况下，g4d是基于MBR扇区引导，默认菜单是/menu.lst,/boot/menu.lst,/boot/grub/menu.lst，g4e是基于文件引导，默认菜单是/EFI/grub/menu.lst。
另外g4d支持pxe，间接支持ipxe。g4e似乎不支持pxe/ipxe，这块我不确定，我没有测试过。
作者: 不点 时间: 2022-11-12 15:27
平时基本不用 g4e，偶尔用过。貌似 g4e 的 map 用法，变化很大耶。我印象中，是 yaya 的样本菜单里面的 map 命令，就与 bios 的不一样。详细情况，可能 liu 版主了解。我只是提醒：不要因为用法差别而导致楼主的问题出现。
作者: liuzhaoyzz 时间: 2022-11-12 15:38
不点 发表于 2022-11-12 15:27
平时基本不用 g4e，偶尔用过。貌似 g4e 的 map 用法，变化很大耶。我印象中，是 yaya 的样本菜单里面的 m ...
我发在3楼的菜单，是我实测可以启动的菜单，适用于g4d/g4e，从最终用户来讲没有感觉到有什么区别。
作者: 不点 时间: 2022-11-12 16:08
不如您自己下载 ubuntu 试试，看究竟成功不成功，以便推断楼主问题的症结在哪里。现在光是问和答，看似省力，其实费劲。
作者: 2011whp 时间: 2022-11-12 16:36
刚从 itellyou下载测试，可以启动
title ubuntu20
root (hd0,0)
kernel /vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity iso-scan/filename=/ubuntu20.iso quiet splash ---
initrd /initrd
楼主 ，可以 先试 把两个文件 复制出来，（这个情况：即 上面的实践）
然后再试，map （0xff）后 提取。
作者: liuzhaoyzz 时间: 2022-11-12 18:45
本帖最后由 liuzhaoyzz 于 2022-11-13 17:02 编辑
Index of /ubuntu-releases/18.04.6/ | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/18.04.6/
文件名称: ubuntu-18.04.6-desktop-amd64.iso
文件大小: 2.34 GB (2,514,124,800 字节)
修改时间: 2022年11月12日，16:56:04
MD5: 98307E18A0B46583A26C34D4B1738D8A
SHA256: F730BE589AA1BA923EBE6ECA573FA66D09BA14C4C104DA2C329DF652D42AFF11
下载了上面这个 ubuntu-18.04.6-desktop-amd64.iso。
I:\EFI\grub\menu.lst
graphicsmode -1 800
find --set-root /EFI/grub/unifont.hex.gz
font /EFI/grub/unifont.hex.gz
color normal=0x07 highlight=0xE1 helptext=0x07 heading=0x02
timeout 3
default 1
title /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
debug 3
find --ignore-floppies --ignore-cd --set-root /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (hd32)
map --hook
kernel (hd32)/casper/vmlinuz boot=casper iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso noprompt noeject
initrd (hd32)/casper/initrd
pause
测试了成堆的grub4dos-for_UEFI，
grub4dos-for_UEFI-2021-10-21可以启动ubuntu-18.04.6-desktop-amd64.iso，√
2021-10-21 changelog：2021-10-21 grub4dos-for_UEFI-2021-10-21.7z更新信息(update log): 2021-10-21 7eceae9@chenall Update release.yml 编译 环境 修改为 ubuntu-18.04 对应源码(sources):
grub4dos-for_UEFI-2021-11-05启动失败×，看了下changelog，
2021-11-05 grub4dos-for_UEFI-2021-11-05.7z
更新信息(update log): 2021-11-05 43d22e2@yaya . 修复管道符‘|’后面紧接call(或者goto)标签时，必须补空格。issues #341 . 迁就有bug的ISO光盘镜像。
“迁就有bug的ISO光盘镜像。”好像有问题。
后面的版本我又试了，很多无法启动ubuntu-18.04.6-desktop-amd64.iso。
@2011yaya2007777，请看下。
而且后面的版本，debug 3好像不管用？
-
GPT-TEST-2022-11-12-18-02-16.png
(5.52 KB, 下载次数: 172)
-
-
grub4dos-for_UEFI-2021-10-21.7z
987.53 KB, 下载次数: 1, 下载积分: 无忧币 -2
作者: 不点 时间: 2022-11-12 18:57
赞！赞！赞！还是版主厉害！找到 bug 了。
作者: 2011yaya2007777 时间: 2022-11-12 21:01
我觉得使用 kernel 和 initrd 函数启动 linux，与 2021-11-05 补丁没有关系，而是与 2021-10-21 补丁有关（尽管 2021-10-21 版本可以启动），因为编译 环境 修改为 ubuntu-18.04 之后，出现过很多次奇奇怪怪的问题。使用我上传的版本正常，而官网编译发布的版本就有点问题。我试图找原因，但最终没有解决。比如有一个版本，我在代码中插入延时几微妙，使用 ubuntu-18.04 编译的版本就正常。我记得起码有 3 次版本有人反馈。可是后来又莫名其妙的没事了。
我每天测试一下看看。
作者: liuzhaoyzz 时间: 2022-11-12 21:27
静候佳音！
作者: 不点 时间: 2022-11-12 22:02
多年以来，一直被 gcc 编译器困扰，是相当难受的事情。
如果有可能的话，转换编译器。比如转换到 clang。
作者: 2011yaya2007777 时间: 2022-11-12 22:13
由于使用了 map 函数，所以有可能与补丁有关系。不过我已经测试了我编译的最新版本，已经测试成功了。现在正在测试从官网下载的最新版本。
作者: 2011yaya2007777 时间: 2022-11-12 22:15
官网的2022-10-27版本测试正常！
作者: 2011yaya2007777 时间: 2022-11-12 22:18
菜单就是liuzhaoyzz的，只不过是iso的存放路径不同。
作者: 不点 时间: 2022-11-12 23:19
yaya 测试正常，但 liu 版主测试出问题，楼主也遇到失败。
这个现象，说明不稳定。
不稳定的原因，除了 gcc 编译出的 cpu 指令含有错误以外，另一种可能性，就是代码体积变大以后，覆盖了原先存放变量的数据空间。还有一种常见的可能性是，堆栈空间给的太小，有些主板的 int 中断调用需要较多的堆栈空间，从而发生了堆栈溢出，造成失败，或死机。
出问题的时候，要看失败的现象：是不是死机了。没死机，与死机，是不一样的，有着不一样的原因。这能帮助判断出问题的大致方向。
作者: 不点 时间: 2022-11-13 06:09
这个图片：blksize=800，也就是 2KB，也就是光盘的 blksize。既然是光盘，为何还要检查其分区表是否合法？应该跳过检查才对啊？
作者: 2011yaya2007777 时间: 2022-11-13 08:04
原来在DOS下编译16位代码，有设置堆栈的问题。后来在32位保护模式，好像只设置代码段和数据段。现在在gcc下编译，找不到在哪里设置堆栈。在GRUB2看到一段有关堆栈的代码，但是没有看明白。
作者: 2011yaya2007777 时间: 2022-11-13 08:14
今天使用 2021-10-21 版本测试，成功启动。与 liuzhaoyzz 超级版主的结果一致。
今天使用 2021-11-05 版本测试，成功启动。与 liuzhaoyzz 超级版主的结果不一致。可能如不点大师所言，不稳定？
2022-10-27版本好难下载。一个链接封了，404找不到。一个链接点击没有反映，架梯子后勉强断断续续费时费力地摘下来。现在上传到这里备用。
-
-
BOOTX64.rar
140.95 KB, 下载次数: 3, 下载积分: 无忧币 -2
作者: liuzhaoyzz 时间: 2022-11-13 08:28
本帖最后由 liuzhaoyzz 于 2022-11-13 08:58 编辑
我之前都是在vmware虚拟机中测试的，因为需要频繁重启电脑，有时候会死机比较伤硬盘，chkdsk /f c:有时候修复不了磁盘错误。
grub4dos-for_UEFI-2021-11-05 版本，实体机测试，显示不了菜单，直接黑屏了，没法进一步测试。
虚拟机测试一直卡在这里，debug 3好像没显示出东西。
===============================================================================
grub4dos-for_UEFI-2022-10-27版本，实体机出现错误提示，等待了一会儿，居然启动了ubuntu-18.04.6-desktop-amd64.iso。
但是虚拟机测试，一直卡在这里：
实体机和虚拟机表现不同，但是很多情况下需要在虚拟机进行测试，不然频繁强制重启比较伤硬盘。
作者: liuzhaoyzz 时间: 2022-11-13 08:30
http://dl.grub4dos.chenall.net/grub4dos-for_UEFI-2022-10-27.7z
2022-10-27版本下载地址，直接把旧版本的日期改下就可以直接下载了，不要梯子。就是changelog看不到。
作者: 2011yaya2007777 时间: 2022-11-13 08:44
本帖最后由 2011yaya2007777 于 2022-11-13 09:18 编辑
尝试解决一下楼主启动失败的问题。
首先要统一测试环境：
1. 使用 liuzhaoyzz 超级版主提供的地址下载 ubuntu-18.04.6-desktop-amd64.iso。
2. 使用 liuzhaoyzz 超级版主提供的菜单启动。
title /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
find --ignore-floppies --ignore-cd --set-root /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (hd32)
map --hook
kernel (hd32)/casper/vmlinuz boot=casper iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso noprompt noeject
initrd (hd32)/casper/initrd
boot
注意加粗的地方，是你存放 ubuntu-18.04.6-desktop-amd64.iso 的路径，要修改一致。比如你放到 /PE/ 下，就改成
/PE/ubuntu-18.04.6-desktop-amd64.iso 注意大小写一致。
3. 使用楼上我提供的 BOOTX64.EFI 测试。
如果启动失败，截图看看失败后的文字提示。
失败的原因大致有：
1.原始启动 ISO 镜像有问题。
2.启动菜单有问题。一是路径有误，二是传递的参数有误。好像不同版本参数不禁相同，不知从哪里获得正确参数，大部分是模仿别人的。这样就容易产生错误。比如少了参数，参数错误，或者默认参数与你的环境不一致，必需显式确定参数（不是隐含），等等。
3.启动工具的问题。
4. 内存问题。我估计启动 ubuntu-18.04.6-desktop-amd64.iso 时，他建立了一个虚拟内存，尺寸一定不小。内存是否有一个可以容纳他的连续片段？
期待楼主的成功！
作者: liuzhaoyzz 时间: 2022-11-13 09:04
我看了下你的这个截图，你的字体跟yaya推荐的/EFI/grub/unifont.hex.gz字体不一致。
BIOS下面的grub4dos与UEFI下面的grub4dos所使用的字体似乎不同，而且可能会影响启动成功率，我以前因为这个问题困扰了很久。
我把/EFI/grub/unifont.hex.gz上传上来。yaya那个帖子也有的。
-
-
unifont.hex.gz
589.24 KB, 下载次数: 10, 下载积分: 无忧币 -2
作者: 2011yaya2007777 时间: 2022-11-13 09:16
grub4dos-for_UEFI-2022-10-27版本，实体机出现错误提示，等待了一会儿，居然启动了ubuntu-18.04.6-desktop-amd64.iso。
我是在实体机测试的，内存小，虚拟机无法测试。
在你说的等待处，我也等待了将近7，8秒，由于菜单里有暂停，必需按一次键！可能是光盘镜像建立虚拟机，并往里面复制文件。
作者: liuzhaoyzz 时间: 2022-11-13 09:37
2011yaya2007777 发表于 2022-11-13 09:16
我是在实体机测试的，内存小，虚拟机无法测试。
在你说的等待处，我也等待了将近7，8秒，由于菜单里有暂 ...
回车键我按了的，虚拟机等待了很久也不行，相比于2021-10-21版本，明显进去较慢。
作者: liuzhaoyzz 时间: 2022-11-13 10:06
本帖最后由 liuzhaoyzz 于 2022-11-13 11:17 编辑
2011whp 发表于 2022-11-12 16:36
刚从 itellyou下载测试，可以启动
title ubuntu20
你看他在6楼的截图，就是提取出来启动测试的，不知道他是从哪里获取vmlinuz,initrd的，如果不匹配肯定是不行的，不建议提取出来，没有必要，如果不匹配可能会带来额外的问题。
ubuntu-18.04.6-desktop-amd64.iso里面：
vmlinuz，9.01MB，楼主的是8.7MB。
initrd，43.6MB，楼主的是42.0MB。
不知道楼主所说的ubuntu18用的是哪个版本？
作者: 不点 时间: 2022-11-13 10:56
本帖最后由 不点 于 2022-11-13 11:13 编辑
肯定有堆栈的。只要是 x86 intel amd 的 cpu，肯定有堆栈。32 位和 64 位，都离不开堆栈。尤其是 32 位、64位，此时消耗的堆栈，反而更多，c 语言函数里面的数组声明，就占用堆栈。比如 char buf [ 512 ]; 就占用 512 字节的堆栈。所以，最好不要在函数体里面声明很大的数组，而应该在函数体外面用 static char buf [ 512 ]; 的形式来声明一个大数组。
如果实在找不到设置堆栈的地方，那么，堆栈就是在实模式下设置好了。只需要确认，堆栈设置的位置是否合理便可。grub4dos for bios 里面的堆栈设置，应该是合理的，不用担心 bios 的 int 调用会发生堆栈溢出问题。但需要注意：刚才说的保护模式的 C 语言函数，不可占用过多堆栈。把那些不安全的地方，修改成安全的（就是函数外部的 static 数组）。
忽然想到，你现在是 EFI 模式。它有没有实模式，我也不知道。我是说，它开机进入实模式还是保护模式，我不知道。但无论如何，它是有堆栈的。你可以用一个程序片段，把主板 EFI 的堆栈探测出来。如果你觉得它设置的地方不对，你可以调整到一个你认为更安全的地方。如果它设置得没问题，你只需要像刚才所说，把 c 语言函数体里面的大数组声明，提取出来，放到函数体之外，并用 static 来声明即可，目的是尽量不占用堆栈。
作者: 2011yaya2007777 时间: 2022-11-13 11:11
这个是遇到过。刚开始调试uefi时，函数出错误，把函数体内部的数组移动到外部，就通过了。
作者: liuzhaoyzz 时间: 2022-11-13 11:30
本帖最后由 liuzhaoyzz 于 2022-11-13 11:33 编辑
UEFI下g4e/grub2作为OSloader，一直工作在保护模式下。886楼：
http://wuyou.net/forum.php?mod=r ... 1424&fromuid=298214
实模式下g4d map --mem占用的内存也不会被释放，我那个回答有点错误。
作者: 不点 时间: 2022-11-13 11:32
本帖最后由 不点 于 2022-11-13 11:44 编辑
你能否把 grub2 for efi 的堆栈相关代码贴出来，我看看。岁数大了，没有体力能查看庞大的 grub2 代码了。
它有可能设置得不合理。因为 ventoy 的图形模式，就很不稳定。我觉得，堆栈设置，是个可变因素，是个疑点。当然，grub2 里面的 bug，决不会只有少数几处。它在 legacy 时代，就有许多 bug，扔在那里没人管。所以，我认为 grub2 很难达到实用的程度，如果后来仍旧没人严肃处理其中的 bug 的话。yaya 你是开发者，我只跟你这么说，让你心中有数。其他人看到了的话，只当做没看到好了。
补充：我不了解 EFI 的内存布局。我只熟悉传统 bios 的内存布局。请 yaya 顺便把 efi 的内存布局简要介绍一下。
作者: 不点 时间: 2022-11-13 11:48
好的，工作在保护模式，也行。现在关心的是堆栈空间太小，引起堆栈溢出。我不知道，grub4dos for efi 是否基于 grub2。如果不是的，那么，堆栈又是如何设置的？如果根本没设置，那就是继承 EFI 默认设置。然而，yaya 说了，grub2 efi 里面，有对堆栈进行设置的代码。也就是说，堆栈确实应该重新设置到一个更安全的位置。
作者: 不点 时间: 2022-11-13 12:05
关于堆栈设置，可以以后再慢慢处理。现在我们还不知道堆栈应该怎么设置，那就是，采用 EFI 默认的设置。
目前我们应该立即行动的，就是前面说的，不让 c 语言函数体里面含有大数组。
另外一个值得提及的事情是：grub legacy 里面，有函数体里面套着另一个函数体（内嵌函数）的现象。这是极其糟糕的。在 grub4dos for bios 中我已经把这类毛病全部修正了。内嵌函数，也是占用堆栈。
所以，yaya 要注意，把函数体里面的大数组以及内嵌函数（如果存在的话），全都提取出来，放到函数体外面。这会大大提高稳定性。至少不会让稳定性变差。
作者: 不点 时间: 2022-11-13 12:17
那就好。另外，如果你借用了 grub2 的部分代码，要注意，其中有可能存在着内嵌函数的情况。内嵌函数就是添乱，不要让函数体里面套着另一个函数体。
如果这些问题都没有，但仍然失败，那就要看，是不是代码体积太大，覆盖了数据空间？或者堆栈太小，不够（各种主板下的） EFI 函数调用的使用。
作者: 不点 时间: 2022-11-13 12:29
这个貌似很容易解决。加个判断：如果是光盘（blksize=0x800），就不检查分区表。当然了，如果不是死在此处，那就不好说了。也许是检查时没死机，以后某一时刻才死机。
作者: 2011yaya2007777 时间: 2022-11-13 14:43
你能否把 grub2 for efi 的堆栈相关代码贴出来
这是2，3年之前的事了，现在换了电脑，找不到标注了“堆栈”的代码文本了。刚才又在GRUB2搜索了一下，没有搜到。不过，GRUB2安装自己的驱动程序，他应当设置堆栈。G4D仅使用固件（无论是BIOS还是UEFI）提供的函数，估计问题不大。
实模式下，内存通常分为常规内存，上位内存，扩展内存。
保护模式下，内存通常是平面的，即0-最大。只不过用户只能使用留给他们的内存。
UEFI是在保护模式下，基本没什么大的区别。用户可用内存，一般是在0-9ffff（但是有的电脑占用0-7fff，有的占用50000前后的几Kb），1Mb之后的区域。
如果你借用了 grub2 的部分代码，要注意，其中有可能存在着内嵌函数的情况
是的，借用了部分函数。存在着内嵌函数的情况。以后抽时间整理一下。
作者: wintoflash 时间: 2022-11-13 16:19
本帖最后由 wintoflash 于 2022-11-13 16:21 编辑
这是2，3年之前的事了，现在换了电脑，找不到标注了“堆栈”的代码文本了。刚才又在GRUB2搜索了一下，没有搜到。不过，GRUB2安装自己的驱动程序，他应当设置堆栈。G4D仅使用固件（无论是BIOS还是UEFI）提供的函数，估计问题不大。
GRUB 2 UEFI 下不会设置堆栈。它只是可以设置堆栈保护 (stack guard)，而且这个功能是可选的。
UEFI 下加载 PE 可执行文件的时候固件会帮你设置好堆栈，当然你想自己设置堆栈也是可以的，要满足如下需求：
(Windows Boot Manager 好像不太喜欢你自己设堆栈)
是的，借用了部分函数。存在着内嵌函数的情况。以后抽时间整理一下。
GRUB2 大概在两三年前优化代码，去掉了所有的内嵌函数。
作者: 不点 时间: 2022-11-13 16:43
既然无需设置堆栈，那就不设置它了。内嵌函数去掉了，那很好。yaya 再确认下，看看以前获取的 grub2 函数，有没有必要更新到最新版。
如果堆栈没问题，code 和 data 也永远不发生交叉冲突，那么，剩下的故障，就只能怀疑 gcc 编译器了。
我知道转换编译器不容易。但是，你很难找到一个 “满意” 的 gcc 版本。
作者: 2011whp 时间: 2022-11-13 18:18
从光盘里 复制 出来的，（参考光盘内 boot 下的 grub.cfg 和 lookback.cfg）
六楼 那个 不稳定， 也提示 找不到光盘，但 等 一会（不按回车），启动的。
作者: 2011whp 时间: 2022-11-13 19:14
用到的 三个文件都 复制出来了，全部在 fat32分区，启动了三次 这个很稳。
（g4e 2022-7-29，ubuntu20 是 itellou下载的）
title ubuntu20
kernel /vmlinuz file=/ubuntu.seed maybe-ubiquity iso-scan/filename=/ubuntu20.iso quiet splash ---
initrd /initrd
作者: kingscl 时间: 2022-11-14 15:39
看了大佬们的研究，留个眼，一会试一下。
作者: laonat 时间: 2022-11-20 03:11
过来看看，学习一下
作者: liuzhaoyzz 时间: 2023-3-26 09:56
http://wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=432789&pid=4721165&fromuid=298214
我用22楼的办法，测试grub4dos-for_UEFI-2023-03-19，启动不了ubuntu18，虚拟机截图如下：
同一个ubuntu.iso，用grub4dos-for_UEFI-2021-10-21测试，可以启动ubuntu18.04。
感觉还是哪里有问题。ubuntu是很大的发行版了，希望跟进下问题。感觉不太像是gcc编译环境的问题。
@2011yaya2007777
@wintoflash
作者: wintoflash 时间: 2023-3-26 10:33
本帖最后由 wintoflash 于 2023-3-26 10:50 编辑
你先排除一下是map造成的崩溃还是启动linux导致的崩溃。
我下载了 Ubuntu 22.04 LTS。
map 直接死机
- title Ubuntu 22.04 LTS
- find --set-root /ubuntu-22.04.2.iso
- map /ubuntu-22.04.2.iso (0xff)
- chainloader (0xff)
作者: liuzhaoyzz 时间: 2023-3-26 10:57
本帖最后由 liuzhaoyzz 于 2023-3-26 10:58 编辑
我测试grub4dos-for_UEFI-2023-03-19，也是map没有完成就挂了。
我比较害怕输命令，还是上pause说明吧：
菜单如下：
title /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
debug 3
find --ignore-floppies --ignore-cd --set-root /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (hd32)
pause map
map --hook
kernel (hd32)/casper/vmlinuz boot=casper iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso noprompt noeject
initrd (hd32)/casper/initrd
pause kernel
截图如下：
但是用上面的菜单，BOOTX642021-10-21.EFI，就可以正常显示pause那两个提示，直接截图吧，回车后就可以启动。
证明还是map有问题。
作者: wintoflash 时间: 2023-3-26 11:03
yaya 整的那一套 map ，我不太能看懂里面的机制。20230311 及之后的版本我没动 map。
作者: liuzhaoyzz 时间: 2023-3-26 11:08
你看我在22楼的回复，
grub4dos-for_UEFI-2021-10-21可以启动ubuntu-18.04.6-desktop-amd64.iso，√
grub4dos-for_UEFI-2021-11-05启动失败×，看了下changelog，
2021-11-05 grub4dos-for_UEFI-2021-11-05.7z
更新信息(update log): 2021-11-05 43d22e2@yaya . 修复管道符‘|’后面紧接call(或者goto)标签时，必须补空格。issues #341 . 迁就有bug的ISO光盘镜像。
“迁就有bug的ISO光盘镜像。”好像有问题。
后面的版本我又试了，很多无法启动ubuntu-18.04.6-desktop-amd64.iso。
我的感觉是grub4dos-for_UEFI-2021-10-21之后的版本引入了问题，问题是yaya那边又没有办法重现问题，很奇怪。
我用的虚拟机是vmware12.5.5，64位的WIN10系统。
作者: 2011whp 时间: 2023-3-26 11:16
本帖最后由 2011whp 于 2023-3-26 11:21 编辑
在win下 看 Ubuntu 20.04 LTS.iso 的 文件系统是: cdfs
1. 把用到的 启动文件 vmlinux initrd 复制出来
让 ubuntu内核 自己 找那个 iso ，自个解析
作者: 2011yaya2007777 时间: 2023-3-26 11:30
yaya 整的那一套 map ，我不太能看懂里面的机制。20230311 及之后的版本我没动 map。
我最近排查了一个错误，不知是不是这个错误引起的，待我验证一下。
帮我看一看，怎么不能从官网下载源码了。虽然有其他下载方法，但是都不能上传补丁。
dev@grub4dos_dev:/mnt/.31/home/dev$ git clone git@github.com:chenall/grub4dos.gi
t
cofuse: unsuppored request 6
Initialized empty Git repository in /mnt/.31/home/dev/grub4dos/.git/
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d5:2c:63:d9:bc:75:9d:de:b1:4e:36:28:9f:7a:9c:39.
Please contact your system administrator.
Add correct host key in /home/dev/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/dev/.ssh/known_hosts:1
RSA host key for github.com has changed and you have requested strict checking.
Host key verification failed.
fatal: The remote end hung up unexpectedly
dev@grub4dos_dev:/mnt/.31/home/dev$
作者: wintoflash 时间: 2023-3-26 11:36
GitHub 因为私钥泄露更新了它的 ssh key。
更新一下就好了。
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/
At approximately 05:00 UTC on March 24, out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com. We did this to protect our users from any chance of an adversary impersonating GitHub or eavesdropping on their Git operations over SSH. This key does not grant access to GitHub’s infrastructure or customer data. This change only impacts Git operations over SSH using RSA. Web traffic to GitHub.com and HTTPS Git operations are not affected.
Only GitHub.com’s RSA SSH key was replaced. No change is required for ECDSA or Ed25519 users. Our keys are documented here.
What happened and what actions have we taken?
This week, we discovered that GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository. We immediately acted to contain the exposure and began investigating to understand the root cause and impact. We have now completed the key replacement, and users will see the change propagate over the next thirty minutes. Some users may have noticed that the new key was briefly present beginning around 02:30 UTC during preparations for this change.
Please note that this issue was not the result of a compromise of any GitHub systems or customer information. Instead, the exposure was the result of what we believe to be an inadvertent publishing of private information. We have no reason to believe that the exposed key was abused and took this action out of an abundance of caution.
What you can do
If you are using our ECDSA or Ed25519 keys, you will not notice any change and no action is needed.
If you see the following message when connecting to GitHub.com via SSH, then read onward.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Host key for github.com has changed and you have requested strict checking.
Host key verification failed.
If you see the above message, you’ll need to remove the old key by running this command:
$ ssh-keygen -R github.com
Or manually updating your ~/.ssh/known_hosts file to remove the old entry.
Then, you can manually add the following line to add the new RSA SSH public key entry to your ~/.ssh/known_hosts file:
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
Or automatically update GitHub.com’s RSA SSH key in your ~/.ssh/known_hosts, by running the following in your terminal:
$ ssh-keygen -R github.com
$ curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts
You can verify that your hosts are connecting via our new RSA SSH key by confirming that you see the following fingerprint:
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s
GitHub Actions users may see failed workflow runs if they are using actions/checkout with the ssh-key option. We are updating the actions/checkout action in all our supported tags, including @v2, @v3, and @main. If you pin the action to a commit SHA and use the ssh-key option, you’ll need to update your workflow. You can read more about this process in our official documentation for Actions security hardening.
For more information, please visit our official documentation on GitHub’s SSH public key fingerprints.
作者: 2011yaya2007777 时间: 2023-3-26 11:59
试一试这个，没有打最近的补丁。
-
-
BOOTX64.rar
140.95 KB, 下载次数: 17, 下载积分: 无忧币 -2
作者: 2011yaya2007777 时间: 2023-3-26 12:44
GitHub 因为私钥泄露更新了它的 ssh key。
妥了，谢谢wintoflash!
作者: liuzhaoyzz 时间: 2023-3-26 16:31
不行啊，这个版本，虚拟机测试，根本就进不去菜单啊？
你测试过了吗？
-
QQ拼音截图20230326162812.png
(11.74 KB, 下载次数: 165)
作者: 2011whp 时间: 2023-3-26 16:34
2023-3-14的g4e,
把 vmlinuz initrd ubuntu20.iso 放到 fat32分区，启动不了（以前的能）
title 重启ubu20
kernel /vmlinuz maybe-ubiquity iso-scan/filename=/ubuntu20.iso quiet splash ---
initrd /initrd
作者: 2011yaya2007777 时间: 2023-3-26 18:22
不行啊，这个版本，虚拟机测试，根本就进不去菜单啊？
你测试过了吗？
我在QEMU虚拟机测试的。
title ubuntu-18.04.6-desktop-amd64.iso
find /boot/imgs/ubuntu-18.04.6-desktop-amd64.iso
map --mem /boot/imgs/ubuntu-18.04.6-desktop-amd64.iso (0xff)
chainloader (0xff)
作者: liuzhaoyzz 时间: 2023-3-26 20:06
本帖最后由 liuzhaoyzz 于 2023-3-26 21:23 编辑
刚才用2023-3-19bootx64.efi+58楼的菜单，实体机测试，可以出菜单，map过了，但是后面死机了。
http://wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=432789&pid=4859318&fromuid=298214
直接上图
为啥虚拟机完全无法测试呢？？？好奇怪。以前的版本BOOTX642021-10-21.EFI就可以呀？
作者: 2011yaya2007777 时间: 2023-3-26 20:25
本帖最后由 2011yaya2007777 于 2023-3-26 20:32 编辑
刚才用64楼的bootx64.efi+58楼的菜单，实体机测试，可以出菜单，map过了，但是后面死机了。
怎么多了一项 venmedia ?
是不是 (hd32) 惹的祸？死机是在 map 之后，是
kernel (hd32)/casper/vmlinuz boot=casper iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso noprompt noeject
initrd (hd32)/casper/initrd
引起的。你使用
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (0xff)
chainloader (0xff)
试一试
作者: liuzhaoyzz 时间: 2023-3-26 21:12
本帖最后由 liuzhaoyzz 于 2023-3-26 21:23 编辑
不好意思，版本太多，我搞混淆了，69楼用的版本是2023-3-19，帖子我改了下。
你在上面发的2023-3-23版本，map过不了直接挂了。截图如下，菜单改成了0xff，实体机测试。
title /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
debug 3
find --ignore-floppies --ignore-cd --set-root /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (0xff)
pause map
map --hook
kernel (0xff)/casper/vmlinuz boot=casper iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso noprompt noeject
initrd (0xff)/casper/initrd
pause kernel
我特别希望能够在虚拟机里面测试，2023-3-23版本，不能虚拟机测试，每次实体机测试要死机，比较麻烦。
-
IMG_20230326_211046.jpg
(45.87 KB, 下载次数: 136)
作者: liuzhaoyzz 时间: 2023-3-26 21:25
关于(hd32)与(0xff)，之前测试过很多，(hd32)启动linux是没问题的。
作者: 2011yaya2007777 时间: 2023-3-27 09:12
关于(hd32)与(0xff)，之前测试过很多，(hd32)启动linux是没问题的。
这是最新版本，包含之前的补丁。
我这里测试，使用chainloader，进入菜单。
使用kernel，显示一些信息，停在那里了。
好奇，你怎么不能使用虚拟机？
-
-
BOOTX64.rar
141.75 KB, 下载次数: 8, 下载积分: 无忧币 -2
作者: liuzhaoyzz 时间: 2023-3-27 10:12
本帖最后由 liuzhaoyzz 于 2023-3-27 10:50 编辑
chainloader (0xff)这样的语句，启动windows或者PE还可以，启动linux，绝大部分是不行的，除非像是slitaz这种改造过initrd的。
我也不知道为啥虚拟机不能测试g4e，以前版本都是可以的，很奇怪。
我估计是下载文件出错。我换了台电脑，虚拟机可以测试启动g4e2023-3-23,g4e2023-3-27.
确实有点奇怪，如果说是文件下载出错，为啥实体机可以出菜单，虚拟机就不行？
晚点回去测试下。
作者: 2011yaya2007777 时间: 2023-3-27 11:36
chainloader (0xff)这样的语句，启动windows或者PE还可以，启动linux，绝大部分是不行的，除非像是slitaz这种改造过initrd的。
我觉得只要他是个iso镜像光盘，并且可以在UEFI环境直接启动，链式加载器就可以启动成功。
作者: liuzhaoyzz 时间: 2023-3-27 11:45
本帖最后由 liuzhaoyzz 于 2023-3-27 11:57 编辑
不是这样子的。
map iso之后，这个(0xff)设备只在g4e环境下有效，一旦退出了OSLoader环境，切入linux kernel，linux kernel会找不到这个iso设备，就无法继续启动了，因此kernel后面的iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso这样子的参数，可以传递到linux kernel，告诉Linux kernel从哪里可以挂载iso文件，然后linux kernel就挂载这个iso文件，iso里面有必须的那个squashfs文件，以便让linux启动流程继续下去。以前是通过init脚本传递，里面可以看到相关的iso挂接参数处理，现在都是systemd，不是明文的，很难查看其启动参数，有的linux发行版，启动过程中就没有挂载iso，就难以通过g4e/grub2启动，那就要采取parntew这样的办法，把iso文件“挂载”到某个空白的分区，然后继续启动，ventoy启动过程似乎是把linux.iso挂载起来，让启动继续。
而chainloader (0xff)这个设备生存期只有OSloader环境才行，不用那些参数是不行的。
对于PE，map iso之后，退出OSLoader环境之后，bootmgfw.efi接管了启动流程，会把那个pe.iso里面的pe.wim挂载到内存盘，比如X:盘，然后可以继续启动，大概是这样子。
squashfs文件有点类似于pe.wim文件。
作者: liuzhaoyzz 时间: 2023-3-27 12:24
我用这个2023-03-27版本，下面的菜单，在vmware虚拟机中测试：
title /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
debug 3
find --ignore-floppies --ignore-cd --set-root /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (0xff)
pause map
map --hook
kernel (0xff)/casper/vmlinuz boot=casper iso-scan/filename=/linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso noprompt noeject
initrd (0xff)/casper/initrd
pause kernel
vmware可以启动g4e了，过了map，显示kernel之后挂了。
作者: liuzhaoyzz 时间: 2023-3-27 12:39
本帖最后由 liuzhaoyzz 于 2023-3-27 12:46 编辑
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (0xff)
chainloader (0xff)
chainloader (0xff)这样是不能完全启动ubuntu的。
完整启动后可以见到桌面，如图。
作者: 2011whp 时间: 2023-3-27 12:39
应该是，启动后 ，过几个阶段 ，找不见光盘了
g4e 2023-3-14 QEMU ubuntu20 转shell下启动
能到这步 是什么 意思
作者: liuzhaoyzz 时间: 2023-3-27 12:49
这个是linux.iso没有挂载起来，参数没有传递给linux kernel.
作者: 2011yaya2007777 时间: 2023-3-27 12:50
谢谢liuzhaoyzz详细解释，似乎明白了。
作者: 2011whp 时间: 2023-3-27 12:58
本帖最后由 2011whp 于 2023-3-28 18:02 编辑
实机：g4e 2023-3-14 ubuntu20 转shell下启动
1. map /ubuntu.iso (0xff)
2. 转shellx64：chainloader /shellx64.efi && boot
3. shell下：map -b 找见 venhw开头的光盘efisysy
fs1：
\efi\grub\bootx64.efi
4. 来到光盘内的 grub.cfg菜单
按e键 编辑 添加 iso-scan/filename=/ubuntu.iso
按 F10 启动
5. 可以启动 到 试用 的桌面（linux 不太懂，没有直观的光盘，）
作者: 2011whp 时间: 2023-3-28 18:08
上一楼 ，已改
yaya说的 只要map合适，即可启动，是可行的（我这下载的 光盘默认是 cdfs，不是udf）
可能 liu版主 所说的 处理特殊udf的 efisys 开始出现的bug
关键的 光盘内有 lookback式菜单（实际光盘内没有，是自己 按e键 改的，加iso-scan/filename=）
作者: liuzhaoyzz 时间: 2023-3-29 12:36
本帖最后由 liuzhaoyzz 于 2023-3-29 17:45 编辑
2011whp 发表于 2023-3-28 18:08
上一楼 ，已改
yaya说的 只要map合适，即可启动，是可行的（我这下载的 光盘默认是 cdfs，不是udf）
Linux启动流程（BIOS下）
POST–>Boot Sequence–>MBR–>Grub–>Kernel(initramfs)–>rootfs–chroot(根切换)–>/sbin/init–>RunLevel–>rc.sysinit—>rc 3(rc.local)–>启动终端
map /linux1/ubuntu/ubuntu-18.04.6-desktop-amd64.iso (0xff)
chainloader (0xff)
这样的语句在linux中，对于没有改动的initrd，大部分只能启动到initramfs，这应该算是linux的核心部分，有一个小的shell，只能执行非常有限的几个命令，大的那个squashfs文件还没有挂载起来，不能进行chroot(根切换)，后面的启动流程都无法继续，无法启动完整的linux。
Kernel(initramfs)
运行中的内核挂载initramfs文件系统(精简内核将部分文件系统驱动做到此微系统中)，使得内核能挂载硬盘真的根文件系统。
一套linux体系，只有内核本身是不能工作的，必须要rootfs（上的etc目录下的配置文件、/bin /sbin等目录下的shell命令，还有/lib目录下的库文件等···）相配合才能工作。
前面已经解释过了啊。你想说的是什么？
作者: wuwuzz 时间: 2023-4-3 19:05
本帖最后由 wuwuzz 于 2023-4-4 16:04 编辑
遇到类似问题。
多次只能启动到busybox/initramfs状态，提示找不到ISO文件之类。
只不过，我的是G4d 046A/BIOS环境，Ubuntu 0910--1410多个版本ISO。
我感觉不是找不到ISO，与G4D关系也不大。
更像是Ubuntu USB驱动与机器硬件不兼容。因为啥也不用动，换台机器就可以正常进Ubuntu桌面。
上述版本G4D/Ubuntu组合在USB2(少量USB3台式机)机成功率高，但在USB3笔记本上失败率非常高。
====================================================================
不要迷信LTS、不要迷信高版本Ubuntu，有时候反而是这些版本失败，其他非LTS版本、低版本成功。
合适的就是最好的。
====================================================================
为什么不用更高版本的Ubuntu ISO测试，因为我的应用软件只能在这些版本上运行。
作者: liuzhaoyzz 时间: 2023-4-4 15:00
本帖最后由 liuzhaoyzz 于 2023-4-4 15:02 编辑
g4d应该没问题吧？可能是你的启动菜单有问题。我们说的有问题的是g4e+kernel启动ubuntu。
啥也不用动，换台机器就可以正常进Ubuntu桌面。
这就有点费解了。如果说是USB读写兼容性问题，这个不应该是g4d/g4e这类的OSloader的问题。
作者: wuwuzz 时间: 2023-4-4 15:39
本帖最后由 wuwuzz 于 2023-4-4 15:52 编辑
G4D没问题、跟menu.lst没关系。啥都不用动(同样的U盘、G4D、menu.lst)，换台机器它就能正常进桌面。
主贴是讲g4e+kernel启动ubuntu，我举的例子是g4d+kernel启动ubuntu，所以说是“类似”。
从Ubuntu启动信息看，基本上能看出问题多半出在USB驱动、casper-rw处理环节，
我讲这些例子，是想开阔大家的思路，不拘泥于G4D/G4E。
作者: ygao2004 时间: 2023-5-1 16:54
本帖最后由 ygao2004 于 2023-5-3 16:49 编辑
最近刚好在研究这个问题，如果你传入scan/filename=iso文件，你无需map，在initramfs中它会在支持的分区中（exfat不支持），遍历块设备，寻找这个iso文件，如果找不到，它就会报错，在ubuntu20.04是这样的。当然你虚拟一个光驱（map），它就会在光驱找filesystem.squashfs，找不到它就会报Unable to find a medium containing a live file system。
有一个live-media=参数，你可以直接指定这个块设备。
作者: wuwuzz 时间: 2023-5-3 16:18
最近一直在测试ubuntu live usb(G4D 046A，不MAP),各种initram，
20以后的版本经常panic死机。
就像之前说的，原因更像是
linux本身的问题。
最后，基本放弃用原版ubuntu，
改用衍生版，尤其是基于18之前
各衍生版，情况好些。
另，楼上说live-media参数，
不知怎样用？是类似
live-media=/dev/sdb1这样
的格式么？（sdb1是优盘第
一分区）
作者: wuwuzz 时间: 2023-5-5 08:01
谢谢ygao2004的说明。
我试了live-media=参数，在我的USB3笔记本CSM（BIOS）、ubuntu环境下无效。
原因：ubuntu USB驱动未识别U盘。
解决办法：如上面所说，原版ubuntu问题太多，换其他基于ubuntu的衍生版。
作者: liuzhaoyzz 时间: 2023-5-6 07:26
本帖最后由 liuzhaoyzz 于 2023-5-6 08:57 编辑
哪有你们说的那样邪乎？说有问题，grub4dos版本也不发一个，菜单也不发一个，ubuntu具体版本也不发个。
说实话，BIOS下的g4d，除了有一阵子ext4下的驱动有点问题（现已修正），启动linux我还真没发现有什么大问题。
我试了下grub4dos-0.4.6a-2023-03-29+ubuntu-20.10-desktop-amd64.iso,好像是以前在清华大学镜像站下载的，BIOS下用7z解开启动没问题啊？
https://mirrors.tuna.tsinghua.ed ... ge/ubuntu/releases/
文件名称: ubuntu-20.10-desktop-amd64.iso
文件大小: 2.74 GB (2,942,003,200 字节)
修改时间: 2021年02月01日，20:39:13
MD5: AA8D6EC4703372CA748BF3C8EA12F87F
title /linux/ubuntu/ubuntu-20.10-desktop-amd64/casper/vmlinuz
find --ignore-floppies --ignore-cd --set-root /linux/ubuntu/ubuntu-20.10-desktop-amd64/casper/vmlinuz
kernel /linux/ubuntu/ubuntu-20.10-desktop-amd64/casper/vmlinuz live-media-path=/linux/ubuntu/ubuntu-20.10-desktop-amd64/casper boot=casper ro ignore_uuid
initrd /linux/ubuntu/ubuntu-20.10-desktop-amd64/casper/initrd
顺便说下，ubuntu.iso接近3GB，本身完美支持map iso直接起动，为啥要多一道道解开启动？
这么大的livecd，为啥不放在速度更快的硬盘启动，要放在USB设备启动？又不是那种体积很小的便携式linux发型版。
作者: wuwuzz 时间: 2023-5-6 12:51
本帖最后由 wuwuzz 于 2023-5-6 13:04 编辑
85#、89#等楼层主要信息已经提了，menu.lst内容与前面大同小异，未重复列示。
更深层次原因，是因为我认为问题不在g4d和menu.lst，所以不想多说。如果需要
更多细节，这里补充：
零、为什么要live-USB
1.不想安装Linux，要在几十种ubuntu发行版(含衍生版)中筛出自带GTK、canvas的版本。
如果不自带GTK、canvas，则最好无线网能智能一些，自动列出wifi表，不要再手工设。
2.参试主力是高速大容量U盘，像2246、3350等固态U盘，以及以稳定著称的3267AE主控
盘，容量128G--500G，做Linux to go没问题。
一、参试PC
Haier凌越S4笔记本，AMI UEFI/CSM；
同方超锐T43笔记本，AMI UEFI/CSM
HP星14笔记本， Insyde UEFI/CSM
其他多种USB2.0笔记本、台式机(Phoenix、Award BIOS)
二、g4d是046a，具体版本2022-12-22，bootice直接写入。
三、menu.lst
title test Ubuntu xxx version persistent
find --set-root /usbhdd.flg
kernel /xxxver/xxxver_vmlinuz boot=casper iso-scan/filename=/xxxver/xxxver.iso locale=zh_CN.UTF-8 noprompt persistent persistent-path=/xxxver/ acpi=off
initrd /xxxver/xxxver_initrd
boot
live USB文件均放在FAT32分区。persistent是2G的casper-rw。ISO只解压出vmlinuz、initrd，
其文件名，根据ubuntu版本不同，对应修改。不加acpi=off，HP笔记本panic更快。
四、ubuntu的问题
1、0910、1010、1210、1310、1404等版本initram、或USB鼠标死、或Xwindow故障等。
2、20及以后的版本大都是panic；
3、16-19间的版本因缺GTK、canvas或是不自动wifi，弃用。
4、使用nvidia显卡的HP笔记本尤其容易panic，版本不局限于Ubuntu 2X。
五、同样的U盘/g4d/menu.lst不动，最后弃用ubuntu，换用了linuxmint、linuxlite，
乱七八糟的问题大大减少(未全部解决，但基本适应大多数情况，基本满足了我的需要)。
作者: liuzhaoyzz 时间: 2023-5-6 13:37
wuwuzz 发表于 2023-5-6 12:51
85#、89#等楼层主要信息已经提了，menu.lst内容与前面大同小异，未重复列示。
更深层次原因，是因为我认 ...
你的启动菜单似乎不太对。ubuntu.iso不解开有不解开启动的参数，解开启动有解开启动的参数，是不同的。从你的启动菜单来看，感觉你混淆了两种启动方式。而且你解开启动的参数似乎也不对。
不同版本的vmlinuz/initrd内嵌了不同的启动脚本init/systemd，一般是不通用的。不知道你这样子局部解开vmlinuz/initrd有没有不同版本导致的混乱，比如解开的vmlinuz/initrd与iso内部的vmlinuz/initrd不同。
ubuntu启动支持是最强的，包括整体启动自动挂载iso，loopback脚本启动，解开启动等等，debian还有NTFS分区的限制。
作者: wuwuzz 时间: 2023-5-6 15:15
重复了，编辑掉
作者: wuwuzz 时间: 2023-5-6 15:16
本帖最后由 wuwuzz 于 2023-5-6 15:18 编辑
一、"不知道你这样子局部解开vmlinuz/initrd有没有不同版本导致的混乱，比如解开的vmlinuz/initrd
与iso内部的vmlinuz/initrd不同。"
不存在这种情况，vmlinuz/initrd就是从对应的ISO版本中解出的。vmlinuz/initrd与ISO一一对应。
每个不同版本均单独一个目录、单独一个menu.lst菜单项。
二、事实上，3#那种完全不解开、MAP ISO菜单项做法，我也试过，问题依旧。
作者: liuzhaoyzz 时间: 2023-5-6 16:30
那样的话，应该就是ubuntu对于USB3总线支持不佳吧。
作者: wuwuzz 时间: 2023-5-6 19:04
从目前我掌握的测试结果看
(以下例子，除非特别说明，U盘/G4D/menu.lst/BIOS/ubuntu信息都是前述环境不变，不再重复赘述)
一.USB驱动故障是首屈一指的诱因。例如live usb-ubuntu 10.10、12.10.....等版本，在USB2主板笔记本上
(甚至少数USB3主板联想/BIOS台式机上)可以顺利启动到桌面。但换到USB3主板笔记本上，ubuntu启动
信息大概率卡在U盘识别或者进入initramfs状态。
二.显卡驱动故障。
1.神舟A/K470笔记本-Phoenix BIOS/usb2主板。基于ubuntu的mint 19.X，启动过程中有切换分辨率
动作，但就在这个动作19.X X86版会白屏死机，换对应同一版号19.X X64版就正常过关。
2.HP星14笔记本频繁panic，网上查到的信息是与linux N卡驱动有关，由于机子不是我的，没法再做
进一步验证。
作者: liuzhaoyzz 时间: 2023-5-6 19:41
wuwuzz 发表于 2023-5-6 19:04
从目前我掌握的测试结果看
(以下例子，除非特别说明，U盘/G4D/menu.lst/BIOS/ubuntu信息都是前述环境不 ...
内核太过于古老的版本没啥意思，用于测试还行。
linux下面显卡驱动是linuxer心中永远的痛，非官方驱动还是差点意思。
作者: wuwuzz 时间: 2023-5-6 20:16
本帖最后由 wuwuzz 于 2023-5-7 10:24 编辑
我花费大量时间、精力做ubuntu测试筛选，内核新旧不是
考虑因素，我需要gtk/canvas做昂贵专用软件的支持环境,
能有这个环境的ubuntu（或其变种）版本就是合适的。
最后结果就是mint、lite胜出（附带的，它们的内核
版本还不低，也支持USB3)，这就可以了。
作者: nowayer 时间: 2023-11-30 19:29
提示: 作者被禁止或删除 内容自动屏蔽
| 欢迎光临 无忧启动论坛 (http://bbs.c3.wuyou.net/) |
Powered by Discuz! X3.3 |
