期末当头，我却被 Archlinux 两个坑爹的 bug 折腾了一晚上。这两个 bug 与启动管理器和内核镜像生成有关，十分严重以至于倘若不幸入坑的话会导致系统无法启动—— grub.cfg 损坏以及 kernel ramdisk 损坏……这两个 bug 都与 Arch 过分激进的更新策略有关，又一次成为了“ Archlinux 不适合生产环境”的有力佐证，以及再次印证了那句话——选择 Arch ，选择折腾。
LZ4压缩
这个 bug 是与内核 ramdisk 压缩算法有关的。在 Linux 3.11 中增加了对于 LZ4 压缩算法的支持（参见这篇新闻）。 LZ4 算法以压缩、解压速度著称，在这个存储空间几乎已经不是问题的年代，IO速度无疑才是瓶颈所在。另外 LZ4 能够很好地利用多核 CPU 的优势，充分发挥当代 PC 的硬件性能。 gzip 自不必说，连 LZO 的速度都比不上 LZ4 。
这其实是后话，我平常没事干也不会去关注这个。问题的起因是 Archlinux “紧跟潮流”在 initramfs 生成器（mkinitcpio）中增加了对于 LZ4 的支持。其实这是挺早以前的事情了，只是更新了 manpage 和默认的 mkinitcpio.conf ，没有引起我的注意。不过这儿其实还有一个打包上的 bug ——文档中提到了可以用 lz4 ，然而却没有把 lz4 列为 mkinitcpio 的依赖，导致事实上无法使用。这个 bug 得到了修复，从而也使我在更新时看到了 new optional depends: lz4 。一个好奇就去简单了解了一下，打算试试看，悲剧就这样发生了……
生成没有任何问题，一重启就发现—— kernel panic ！提示说是 ramdisk 无法解析（apparently junk…）。后来才发现原因是 lz4 的命令行工具开发者改变了生成的文件格式，而内核中使用的文件格式就成了“legacy”的……有人已经报告了这个问题，在 lz4 工具的项目主页和 Archlinux 论坛中都有。 Archlinux 的打包者没有经过任何测试，想当然地认为使用 lz4 命令行工具压缩出来的东西自然能被内核识别、解压……
其实这件事情 lz4 社区也有责任，完全不顾向后兼容性（而且还是在刚刚被加入 kernel mainline 的情况下）。而且解决方案竟然是增加一个未文档的 -l （--legacy）参数！（下一个版本里头应该会加入文档中。）但是，我认为问题主要还是在于 Archlinux 这边——对待 kernel ramdisk 这样重要的东西都这么随便。这个问题只要测试一下马上就能发现。不过其实 Archlinux 本来就是把用户当做测试员的发行版吧……在我们这种蛋疼的小白鼠尝试过以后，他们现在果然发现并修复了这个问题。
grub-mkconfig 生成的 grub.cfg 语法错误
要说上一个问题只有我这种闲得蛋疼愿意尝试非默认选项的人会遇到。那这个问题可就完全不一样了。在最近的某次 grub 升级之后， grub-mkconfig 工具在默认配置下所生成的 grub.cfg 有语法问题，语法检查会提示 out of memory 和 syntax error 。从而不会把生成的 grub.cfg.new 重命名为真正的 grub.cfg 。这要是在安装系统的时候遇到，就肯定无法启动了……而且安装过程中日志多得吓人，大部分人没看就直接重启，然后就会发现启动不了（grub.cfg not found）……
bug report 在这里。解决方案是在 /etc/default/grub 中添加一行：
GRUB_DISABLE_SUBMENU=y
不知道这个问题到底是上游的问题还是怎么回事（只说了是 known issue ）。但是明知道有问题也一定要更新启动管理器这样的东西真是令人无语……我倒想知道如果到下个月1号还没修复这个问题的话，他们是不是打算就这样把这个有问题的 grub 放进 install cd 里去，然后就会出现一大批被坑了无法安装系统的可怜虫……
Comment ( 1 )