返璞归真，还原默认分区，远离cloudcone readyidc等重装烦恼

天权璇玑

论坛主贴：

https://hostloc.me/thread-1159839-1-1.html

github：

https://github.com/leitbogioro/Tools

图库为 sm.ms，国内用户需挂梯子全局才能查看。

一直以来，Cloudcone 的重装卡 grub 是困扰各位 MJJ 的不小难题，核心问题是其机器启动时，并非是从系统自带 grub 进行引导，而是由一个外部 grub2 来启动，且不可在面板设置中更改。

我很久没有再玩过 Cloudcone 的机器了，当时还保留了一个防止重启后卡 grub 的解决方法。

直到今天，tg 群里有一位水友，给一个来自泰国的，名叫“readyidc”的商家，他用我脚本重装系统后，也遇到了卡 grub 的问题。

机器起配 1C，2GB 内存，30GB 硬盘，1 静态 IPv4，200 Mbps 共享不限流量，150 ฿（泰铢，折合 RMB 30 元）/月，性价比一般。





我一看，症状和当年折腾 Cloudcone 几乎一模一样，真是一见如故，如图所示：





手动解决这个问题的办法不是没有，点按几次回车：





按照屏幕提示，按一下 c 键，然后进入 grub 救援模式，在这个界面，输入“exit”并回车，就能启动到机器自带的 grub 引导：








不过每次重启后，都要做一次重新手动引导，实在是太麻烦了，有没有办法能彻底解决这个问题呢？我想到以前记录下来的方法：

在 debian 9 下开始重装；

重装结束，进 VNC 选择 grub 界面，按 e 后进入配置界面，ctrl+c 退出进入 grub命令行，输入 exit 后正常进入系统；

正常进入系统后，执行 ln -s /boot/grub/ /boot/grub2 即可正常重启。


以上办法的核心思路，是在重装后的系统内，创建一个 /boot/grub/ 至 /boot/grub2/ 的软链接（和 Windows 下的快捷方式类似，但又有不同，Linux 下软链接的文件和目录和操作真实文件的效果一样）。

我在重装后的系统里同样执行了 ln -s /boot/grub/ /boot/grub2 ，但重启后系统并未按预期被外部的 grub2 顺利自动引导，还是得手动操作。

难道之前的办法行不通了？我搜过相关帖子，找到了一个：https://hostloc.me/thread-842829-1-1.html ，说是要在“C:\Boot\grub2\grub.cfg”加入：

[ol]

chainloader +1

boot[/ol]复制代码

这个方法或许在 Windows 下行得通，但在 Debian 下是不适用的，之前那个有效的方法，为什么也不管用了呢？

或许，我应该找一些同类脚本测一下，为保证测试公正性，首先把系统重装成后台模板自带的 Debian 11.2：





从自带系统重装到其他系统，且仅执行默认命令，不带任何高级参数，确保模拟小白用户面临的情况：

煎饼哥（bin4-9）的：

很遗憾，写完引导后，重启后无法被正确引导，又回到了原系统：








萌咖的脚本连 grub 都找不到，直接报错。我差点以为原系统不是 Debian，后来一想这个模板系统里，是带 grub2 软链接的，可能是这一因素影响到了 grub 引导菜单的查找和写入：








最后试了下 debi 的，重启后发现是以 dhcp 配置的网络，直接卡在配置网络那一步，我尝试在 VNC 里手动输入网络配置，最后重启后也卡在 grub：

天权璇玑

实事求是地说，在代码没更新前，以上各脚本的重装测试中，我的脚本是唯一一个至少能撑到最后系统装完，才卡在 grub 这一步的，其他脚本都遇到了令人不快的失败。

我之所以在 grub、网络等适配上下那么大功夫，就是为了做到让每个人仅运行 bash InstallNET.sh，就能轻松装好系统的程度，很多高级选项确实有拓展的必要，但那些是留给和我一样专业的人去使用的。

既要给懂的人最充分的自定义空间，也要给不懂的人最简单，最舒适、最适合的安装体验，让他们不必再为处理底层复杂的事务困扰，专注于建站、富强等其他顶层实现。以人为本的理念始终贯穿我开发这个脚本至今。

我觉得要解决这个问题，还是得重回模板系统，看看其环境和重装后的系统相比，有哪些不同。

目前报错的界面，应该是 grub2，但 Debian 的grub明明是 grub1，我推测可能是这台机器有一个总的 grub2 引导，用来引导其他系统，而不是直接读取机器自带的 grub 启动。

报错中有一段内容引起了我的注意，那就是：

[ol]

disk 'hd0,msdos1' not found.[/ol]复制代码

很明显，'hd0,msdos1' 透露出至少两条重要信息：

外部 grub2 引导程序，会试图从机器的第一个硬盘的第一个分区中，寻找硬盘自带的 grub，然后将其启动，否则报错；

外部 grub2 引导程序仅承认 mbr 分区，因为 grub 中 mbr 分区表格式就是“msdos数字”。


我突然想起，脚本自带的分区策略，很久之前为了考虑到支持 3TB 以上大容量硬盘，将默认分区策略改成了 gpt，然后考虑到 xfs 的性能和纠错能力比 ext4 更好，把默认的格盘文件系统改成了 xfs，把这两项还原，能否是解决问题的关键呢？

先看一下原系统中的 /boot/grub/grub.cfg 文件，确实指向的分区表是 mbr 的：





原系统中分区格式也是单分区，且 grub 和系统盘在同一个 /dev/vda1 分区：





以上观察可知，只要将 preseed.cfg 中，分区策略还原成默认即可。

在脚本中需要改动的部分，首先第一点：默认在单盘新安装系统，分区表和文件系统还原回默认的 mbr 和 ext4，如果指定“-partition "gpt"”，分区表和文件系统再调整成使用 gpt 和 xfs。








然后既然考虑到创建 grub2 的软链接，仅仅是一条命令的事，“ln -s /boot/grub/ /boot/grub2”可以直接放到 preseed.cfg 中，“d-i preseed/late_command”阶段，即在系统已安装完，直到重启前，执行一些自定义命令阶段：

最终 Debian 自动应答文件 preseed.cfg 中相关内容如下：








为保证公正，我用自己脚本测试的时候也仅使用最简单的命令启动：

[ol]

wget --no-check-certificate -qO InstallNET.sh 'https://raw.githubusercontent.com/leitbogioro/Tools/master/Linux_reinstall/InstallNET.sh' && chmod a+x InstallNET.sh

bash InstallNET.sh[/ol]复制代码

重装后顺利连接机器，不再面临卡 grub，手工修改 grub1 到 grub2 软链接等操作，此改善适用于 Debian 全系、Kali：








杂谈：

在甲骨文、Virmach、Racknerd、Server-factory、OVH、Wiki-idc、搬瓦工等等其他普通机器上都做过了测试，创建这个软链接对正常引导的机型并无影响；

这种由外部 grub2 引导的条件很苛刻，必须满足硬盘 mbr 分区表、ext4 文件系统、且 grub 文件和系统在同一分区且在单硬盘第一分区；

AlpineLinux、Ubuntu、红帽系经过测试，均无法解决以上问题，因为它们的默认分区表、分区策略、文件系统等至少有一个或多个不满足以上可被外部 grub2 正常引导的条件，如果为此进行修改，又会影响到其他机型；

Kali 和 Debian 共享同一套配置文件，所以 Debian 上能解决的问题，同样适用于 Kali；

Ubuntu 是从官方做的 cloud image dd 进硬盘里的，官方镜像为了保持和 UEFI 固件机型兼容，所以保留了一个 /boot/efi 分区，即使机器是 BIOS 固件，所以不满足 “grub 文件和系统在同一分区且在单硬盘第一分区这个条件”；

Ubuntu 如果还像以前一样，保持兼容 Debian 的 preseed，那么 Ubuntu 可立马享受该红利；

红帽、Canonical，总是想着下个版本改点什么，加点什么，不是提高内存占用，就是要弄点什么新东西来取代已有的成熟体系；

尤其是 Canonical，特别喜欢作死，总是不满足于老老实实做一个“超级优化版 Debian 发行版”的角色，总是想替代 Debian，但根本没那个能力，除了 cloud init 比较成功，其他什么 netplan、snap，不但没有解决 Debian 的问题，还徒增麻烦，全是令人唾弃的角色，要是等哪天把 apt 也给抛弃，Ubuntu 我是绝对不会再管了；

我认为 Debian 有个最可贵的品质，就是不作死，不折腾，这也是我一直以来推崇大家使用 Debian 的原因；

还是基于纯社区、minzhu决策的东西靠谱，有商业公司ducai插脚的东西，最终的结局大概率是会作恶；

无论做人还是做事，一定要分得清自己的能力边界，就怕没那个本事，野心还不小，又菜又爱玩，志大才疏，最后搞得谁都不喜欢。