Fedora 16 → 17 いきなり躓く

ようやく重い腰を上げて、アップデートに取り組んだ矢先、いきなり撃沈。

私の環境は、/boot、/ が Software Raid なのだが、/boot が Software Raid であることが原因で、preupgrade がエラー終了してしまう。

http://ftp.riken.jp/Linux/fedora/releases/17/Fedora/i386/os//.treeinfo からツリー情報を取り込みました
ツリー情報のタイムスタンプ:Wed May 23 05:58:41 2012
/boot/upgrade/vmlinuz のチェックサムは OK です
/boot/upgrade/initrd.img のチェックサムは OK です
Traceback (most recent call last):
  File “/usr/share/preupgrade/preupgrade-gtk.py”, line 259, in on_assistant_apply
    self._do_main()
  File “/usr/share/preupgrade/preupgrade-gtk.py”, line 278, in _do_main
    self.main_preupgrade()
  File “/usr/share/preupgrade/preupgrade-gtk.py”, line 497, in main_preupgrade
    extra_args += ” ks=%s” % self.pu.generate_kickstart()
  File “/usr/lib/python2.7/site-packages/preupgrade/__init__.py”, line 607, in generate_kickstart
    return dev.bootpath_to_anacondapath(targetfile, UUID=True)
  File “/usr/lib/python2.7/site-packages/preupgrade/dev.py”, line 91, in bootpath_to_anacondapath
    raise PUError, “/boot is on RAID device %s” % bootdev
preupgrade.error.PUError: /boot is on RAID device md0

https://bugzilla.redhat.com/show_bug.cgi?id=500004 にあるように、2009 からあるバグらしいが、今も FIX されずに健在なバグ。/boot を Software Raid にすることは、推奨されていないのだから、直す気がないのか？個人的には /boot を Software Raid にすることが推奨されない理由が、運用面からは理解できない。

Google 先生に聞いてみると、このバグを回避するワークアラウンドがある。

しかし、この方法は Fedora 14 までで、Fedora 15 からは、install.img がどのミラーサイトにもないし、そもそも起動の仕組みが変わっているのか？Fedora 14 の時の上記ワークアラウンドは動かせない。実際あれこれやってみたが動かない。

どうもこの問題（/boot が Software Raid で preupgrade できない問題）をクリーンでもそうでなくても解決している事例はなさそうである。これって、インストールメディアを利用しても、/boot が Software Raid だと発生するみたいで、それを実際に確認してみようか？あるいは、/boot だけ Raid を外してみるか？

前者の確認はやってみればいいだけだが、後者となるといきなりハードルが高くなる。/boot の Software Raid を解くなんて事例が探し当てられない。

いずれの方法を取るにしても、インストールメディアがあれば、レスキュー起動もできるだろうから、やはりまずは前者を試してみるかな。今回先は非常に長そうだ。