本帖最后由 天权璇玑 于 2023-8-7 09:30 编辑

论坛主贴：

https://52.ht/thread-1159839-1-1.html

github：

https://github.com/leitbogioro/Tools

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

一直以来，Cloudcone（又称 cc，https://app.cloudcone.com/ ，论坛坛友二手交易热门商家） 的重装卡 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 的软链接。

Tips: Linux 软链接和 Windows 下的快捷方式类似，但又有不同，Windows 的快捷方式仅能双击访问，不能被其他程序操作并影响到其指向的原文件，Linux 下软链接的文件和目录和操作真实文件的效果一样，但是在 Windows 下查看 Linux 软链接文件，显示的结果又是快捷方式。



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

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



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

或许，我应该找一些同类脚本测一下，为保证测试公正性，首先把系统重装成后台模板自带的 Debian 11.2 ，这也是截止到直至本次测试时间结束（2023 年 8 月 6 日），该商家 Readyidc 后台 Debian 模板中提供的最新版本。

对以下测试结果有质疑的水友，欢迎在此商家或 Cloudcone 开机，以以上时间戳为准，用以下当期版本的脚本（不算它们在未来的更新修复）做交叉验证：



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

煎饼哥（bin4-9）的：

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





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





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

本帖最后由 天权璇玑 于 2023-8-7 09:32 编辑

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

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

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

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

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

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



很明显，'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 中相关内容如下：





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



重装后顺利连接机器，不再面临卡 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插脚的东西，最终的结局大概率是会作恶；
• 无论做人还是做事，一定要分得清自己的能力边界，就怕没那个本事，野心还不小，又菜又爱玩，志大才疏，最后搞得谁都不喜欢。
  

文本总结：

文章主要讨论了 Cloudcone 机器中 grub 启动的问题。这些机器在启动时不是由系统自带的 grub 引导，而是由外部的 grub2 来启动，这导致了一些问题。作者曾经保存了一个防止重启后卡 grub 的解决方法，但是这个方法后来似乎不再有效。文章中还提及了一个泰国商家 readyidc 和他的机器配置。

文章继续描述了这个启动问题的手动解决方法，但是每次重启都需要手动操作，非常不便。作者曾尝试在 Debian 9 上重新安装系统并通过创建一个软链接来解决这个问题，但没有成功。

文章中还尝试了不同的脚本来解决这个问题，但大多数都遇到了问题。作者认为，要彻底解决这个问题，需要重新查看模板系统，并找出其中的差异。

文中还探讨了外部 grub2 如何寻找机器自带的 grub 来启动的问题。文章结束时，作者提供了一些有关分区和文件系统的想法，并对 Ubuntu 和 Debian 进行了一些评论，强调 Debian 的稳定性和纯粹的社区驱动的决策方式。

关键点：

Cloudcone 机器的 grub 启动问题。
手动和自动的解决方法尝试。
分区和文件系统的讨论。
对 Ubuntu 和 Debian 的评论

全场 MVP：AI

技术贴顶顶

技术贴顶顶

以前玩Cloudcone的没遇到过，我都是网络重装，删除以前所有分区，重新分区安装centos7，安装完直接就进去了。

红帽系 7+ 都是 grub2 引导，挂载 iso 安装，保持全盘只分一个区的策略，应该是没问题的