Closed scp-r closed 1 year ago
Debian/Ubuntu 无论哪个版本,哪种主板固件,实际 grub 文件统一在 /boot/grub/grub.cfg,而红帽(Redhat/CentOS/AlmaLinux/RockyLinux/OracleLinux)系列 7/8 版本会因主板是 UEFI 或 BIOS 固件的不同,分别在 /boot/efi/EFI/"当前系统名称"/grub.cfg 或 /boot/grub2/grub.cfg 中,到了红帽 9(包括 Fedora 36+),grub 文件又统一回到了 /boot/grub2/grub.cfg 中,所以判断应该从哪个 grub.cfg 中读取 menuentry 是一个比较繁琐的工作,仅靠查找名为“grub.cfg”的办法是行不通的,因为你也通过实验,发现 Ubuntu 20.04 里有两个 grub.cfg,其中只有一个是有效的。
我的脚本已经实现了智能识别不同系统、不同主板固件(UEFI / BIOS)实际 grub.cfg 的位置,并且能正常读取到并写入到新的 grub.cfg ,在很多系统和平台上测试都获得了不错的兼容性,欢迎尝试一下:
Github主页: https://github.com/leitbogioro/Tools 论坛主贴,中文文档: https://hostloc.com/thread-1159839-1-1.html https://www.nodeseek.com/post-9383-1
你可以用我的脚本在甲骨文的 Ubuntu 20.04 上运行并安装 Debian 9+,IPv6 重装后能自动配好,能成的话给个star,不能成的话给我提 issue
@MoeClub 整合一下楼上大佬对bug修复的部分吧
不用了,你直接用我的得了,我修复的部分不计其数,代码数从他原来 800 多行扩充到 3000 多行,相当于重写了,他怎么改?
在甲骨文amd机器上使用InstallNET.sh报错,执行的命令是:
系统是通过Oracle Cloud安装的Ubuntu 20.04
错误输出:
TL;DR
InstallNET.sh的第257行getGrub函数内的:
这条命令的前半部分命令在部分系统上可能会有这样的输出:
最后取
head -n1
得到的是/boot/efi/boot/grub
而非/boot/grub
,在部分镜像(比如甲骨文的Ubuntu 20.04)上这个文件只是起到转发的作用,实际的grub.cfg在/boot/grub
目录下。分析过程
不是很熟悉bash,大概分析了一下,从输出看报错是第527行,也就是
/tmp/grub.new
没找到写入
/tmp/grub.new
的逻辑从506行开始,在这之前打印了LoadNum,发现是0;再往上找/tmp/grub.read
这个文件内容为空,非常奇怪。打印$GRUBDIR/$GRUBFILE
的值是/boot/efi/boot/grub/grub.cfg
,内容是:按照脚本逻辑分析,应该是尝试从这个grub.cfg中解析出entry,但是因为定位到的
/boot/efi/boot/grub/grub.cfg
仅仅是做了一个类似转发的操作,实际的grub.cfg在/boot/grub目录下,导致上面的错误。继续寻找$GRUBDIR/$GRUBFILE
的来源,在getGrub函数内的第257行。