分类目录归档:享受过程

从 iso 到 qcow2 的坎坷之路

之前在云上部署下一代防火墙(NGFW)的时候,须订购云主机并安装指定的 NGFW 产品系统镜像。大致步骤:将该 NGFW 的镜像包(qcow2 格式)先上传至云内对象存储,再导入至自定义操作系统列表,就可以灌装到云主机中。再把 VPC 内的其他主机路由表下一跳指向该主机,就可以实现 NGFW 对 VPC 内流量统一管理。

此次,某客户在订购了裸金属服务器后,须安装指定的某版本操作系统,但不在标准操作系统选单中,于是紧急以 iso 安装包起手,拿出指导帮助文档,利用手头的环境边走边学 qcow2 镜像的制作过程,是为记。

手头 VMware 的虚拟机中已有 CentOS 7.9,但没有 GUI,制作工具 virt-manager 是底层 python 、表层 GTK 或 Qt 写就的 GUI 工具,那么纯命令行的系统则不行。于是第一步便是把 CentOS 的 GUI 给出弄出来:

yum groupinstall "GNOME Desktop" "Graphical Administration Tools" -y
systemctl get-default 可以看到当前默认的模式为 multi-user.target
systemctl set-default graphical.target 修改为图形界面模式


将 CentOS 7.9 GUI 设置好之后,virt-manager 装好之后,一通折腾,最后仍然以缺 python 的 gi 库告终,摊手。点亮斜门初级技能:把命令行系统变出 GUI 。

最后还是想到了自己那台万能的 N100 小主机。含 GNOME 的 Manjaro,各方面都符合要求,于是准备用其从 iso 制作 qcow2 。 sudo pacman -S virt-manager,并把其他缺失包一一装好后,又出现了新的问题:Virtual Machine Manager 里面没有 QEMU,只有 LXC 。

搜了下,LXC(Linux Containers)是基于容器的虚拟化,KVM(Kernel-based Virtual Machine)是更底层的内核级虚拟化。那为什么没有 KVM 呢,问了下最近觉得技术方面比较给力的 Google Gemini,回答如下:

在使用 Manjaro 安装 virt-manager 后,出现 LXC 而没有 QEMU,通常意味着 virt-manager 默认连接到了 LXC hypervisor,而不是 QEMU/KVM 。
这里有几个常见的原因和解决方法:

1. 确保你已经安装了 QEMU 和 Libvirt 相关的必要包。在 Manjaro 上,这通常包括 libvirt virt-manager 以及可选的 KVM 模块 qemu-arch-extra;
2. libvirtd.socket 或 libvirtd.service 的启用问题,要确保 libvirtd.socket 或 libvirtd.service 已经启动并启用;
3. 用户权限问题:用户需要添加到 libvirt 用户组才能无密码地使用 virt-manager 连接到 QEMU/KVM;

之后又给出了一些复查命令。

照做之后,果然在 Virtual Machine Manager 中出现 QEMU/KVM 。之后就是在 virt-manager 的 QEMU 中新建虚拟机,这里的界面很像 VMware 的硬件配置界面。

把 iso 文件导入虚拟 CDROM,简单配置下硬件,Begin Installation,得到的磁盘镜像文件就是 qcow2,类似于 VMware 的 vmdk 。

最后 qemu-img convert -c -O 把镜像文件压缩一下就行。写到这里,我突然想到:在 VMware 里制作 vmdk,用 qemu-img convert 直接转成 qcow2 呢,应该也可以吧。如果绕路了,那也一定是为了看风景。:D

Manjaro Linux 抢救记

2024 年中秋适逢台风贝碧嘉来袭(熟悉的开头:D),强降水给小区带来的树倒、停电等一系列灾害,我的装了洗手.jpgManjaro 系统的 N100 小主机在 226 天的 uptime 后终于趁着停电休息了一把。供电恢复后通过 openVPN 、智能家居 app 发现路由器、 IoT 设备都已重新上线,困惑的是唯独这台小主机仍然处于失联状态。等到节后回来便研究了一番。以下全程感谢 @wzyboy 再一次的不吝指导。

接上显示器和外设开机发现,系统已经处于 emergency mode 状态。此时遇到的第一个坑是,emergency mode 的第一行提示 “loadkmap short read”,加上按一些字母键都没有反应(此时实为输入密码状态,但无回显),由于对 emergency mode 不熟悉使我和 gpt 误认为键盘映射出现问题。实际上此时只要输入 root 的密码就可以登录系统。

以 root 登录后输入 dmesg 查看内核输出的启动信息,发现在正常启动过程中有以下看起来很关键的报错:

intel_ish_ipc: ishtp-ish timed out waiting for fw-initiated reset
intel_ish_ipc: ISH: hw start failed.

于是一阵搜索,越搜越觉得困惑和茫然,是不是内核 bug,是不是硬件损坏…gpt 也小心翼翼地建议在 grub 启动项中屏蔽 ish 有关硬件,满怀希望地保存后重启,问题依旧。

emergency mode 中,系统很明确地提示要用 journalctl -xb 命令去查看启动日志,于是很仔细地查看这一千七百八行日志,这里我边看边在想,和 dmesg 不同的是阻塞正常启动的关键错误信息可能不会按时间顺序出现在日志的最后面,但仍会以不同颜色的字体标出。

仔细观察日志后发现与 /etc/fstab 有关的挂载错误,却没被我放在心上。我知道挂载一个不存在的分区会引起启动问题,因此在 /etc/fstab 中设置了 nofail 来长期把一移动硬盘挂载在系统中。虽然排错时移动硬盘未插入,不至于影响正常启动吧?所以又错过了奇点,从别的角度甚至是 USB Live CD 的 chroot 等方式试图修复系统。等到回过头继续从 journalctl -xb 日志侦错时,还是觉得大致记下报错的分区 UUID 去 /etc/fstab 看一眼吧。这一看才发现该 UUID 所对应的是一个未设置 nofail 、已经被合并了进 / 了的、不存在的分区,因为操作时间久远且一直未重启才忽略了该问题,注释该行,问题解决。

在排错的过程中,因为系统设置了中文导致 emergency mode 的字体全变成方块,这个问题在我首次接触 debian 时也遇到过,不过此次学到了通过设置变量 export LANG=C 的方法强制 fallback 到比 en_US.UTF-8 还基本的 locale 来避免中文显示问题。甚至还了解到了有趣的 Linux tty 勉强型中文字体——戴着有限字符空间的镣铐跳起支持中文的舞。又让我想起了一些汉化版 FC 游戏因 ROM 空间不足而被迫实施的一些奇技淫巧。

Linux 启动排错可能使人更有机会了解 “Linux 系统是怎么编排硬件的” 。而我一直想象的一个场景是:把桌面环境的 Linux 自行配置成家用路由器——通过安装 pppoe 、 upnp 等软件包来实现家用路由器功能;配置多网卡、网桥、路由表等来实现 WAN-LAN 口转发等,这样的场景想必更有挑战,也会使人更加了解 “Linux 系统是怎么编排网络的” 。