编辑2:在使用 subiquity 和 cloud-init 的两周时间里,我拼凑了一个新的shell 脚本以用户数据文件为例,grub.cfg
由于 21.10 中删除了 isolinux,因此 covertsh 修改的那个文件对我来说不再有效。该脚本会自动重新打包 ISO 以在 EFI 和 MBR 系统上启动,并且可以获取这里。部分脚本内容来自此主题:重新制作 Ubuntu 20.10 的安装映像
编辑:如果这听起来过于愤怒,请原谅,但这就是我过去几天与压迫作斗争的感受。
按照我做事的顺序:
1. 下载每日直播服务器 ISO (jammy 22.04 ~1,4Gb)
2. 将 iso 解压到一个文件夹
3.删除[BOOT]目录
4. 使用一些 dd magic 从 ISO 文件 (boot_hybrid) 中获取 efi 和传统分区
5. 编写一个用户数据文件,使用 cloud-init 根据架构检查该文件
6. 将用户数据和空元数据文件放入 ISO 根目录中名为服务器的新目录中
7. 将新的 grub.cfg 和新的菜单项放置在 /cdrom/boot/grub/ 中
8. 使用 xorriso 将 iso 重新打包成一个新文件 9. 创建虚拟机并启动整个系统
现在,以下的事情让我感到困惑:
安装程序似乎识别了 GRUB 中的新条目并采取了相应的措施,同时还接受我的输入,仅以交互方式打开网络部分以及初始身份部分。
但安装后,安装程序似乎使用了 LVM 而不是直接方法进行存储,并且未执行任何后续命令以及一个用户数据 runcmd 命令。apt 下配置的所有软件包也都丢失了。
调试这种情况需要哪些步骤?
我的第一个猜测是 /var/log/subiquity.log,但我没有机会理解或按时间顺序跟踪其中的任何乱码输出。
更新 1:
令人震惊的是,到目前为止,相关日志都无法提供任何可计算的信息来解释安装程序为何会如此行事。唯一提供的是一些关于 cloud-init 内部操作的令人困惑的信息,这些信息既与任何输入或输出无关,无法为实际调试奠定基础。坦率地说,输出设计是不可接受的。
这使我相信,可能对 grub、自动安装键或 subiquity 进行了更改,但这些更改没有得到很好的记录,或者,最有可能的是,我一定是在 20.04 或 21.x 之间的某个地方犯了文档错误,而现在,另一方面,我很好地记录了我的试验,它以前确实是那样工作的。我只是觉得 stacks markdown 不支持删除线。
更新 3:到目前为止,我已经设法解决了 grub 错误并进入了实际的自动安装,但仍然无法安装软件包ubuntu-desktop-minimal
我可以给其他人一些提示:
- 忘记日志吧,它们接近(但并非完全)垃圾
- 确保严格遵循 yaml 架构,单个空格可能会导致 cloud-init 架构检查亮绿灯,但会导致自动安装错误,因为操作系统会忽略格式不正确的文件(不会向您发出任何提示)以在 ISO 中的某个位置找到默认用户数据文件。我已经受够了,想去搜索那个文件在哪里。
- 确保在你的 iso 中通过 loopback.cfg 复制 grub.cfg,不知道这是谁的主意,但即使几乎没有人需要它,它就在那里。
- 有些
grub.cfg
需要看起来像这样
menuentry "Autoinstall Ubuntu Server + Desktop + Ordersprinter" {
set gfxpayload=keep
linux /casper/vmlinuz quiet autoinstall "ds=nocloud;s=/cdrom/nocloud/" ---
initrd /casper/initrd
}
- casper/vmlinuz(tab)quiet < 确保正确无误,否则自动安装会开始抛出错误。
- grub 没有抛出错误,这显然不是一个错误,而是将自动安装密钥重定向到用户空间。但是,嘿。让我们将该消息格式化为错误,谁在乎呢。
更新 4:ubuntu 本身的安装日志有时似乎确实包含一些有用的信息!在 200 行令人困惑的内容之后,您可能会看到一个名为的部分,traceback
如果您足够幸运,它会告诉您云配置的哪个部分实际上导致了失败。但有时甚至该部分也只包含垃圾。但这是一个开始。老实说,traceback
应该是该日志中的第一件事,而不是隐藏在深处。
更新 5:现在可以确认,ubuntu-desktop-minimal
安装过程中,软件包是整个安装停止的点,即使不太可靠,VM 的 CPU 使用率也接近于零,vdisk IO 也是如此。稍后我将尝试通过 late 命令安装软件包。
更新 6:为什么会这样用户使用 sudo
for tee
,但是不能使用sudo
viacurtin
来apt
运行-q -y
?