再インストールせずにFedoraを32ビット版から64ビット版にアップグレード
私が使ってきたのはFedoraで、すでに64ビット版への移行を決心していた。もう何年もLinuxのカンファレンスでFedora愛好家やRed Hatの社員に64ビット版へのクロスグレードについて話を聞いてきたが、その方法として返ってくる答えは決まって再インストールだった。しかし、再インストールはシステムのハードディスク・エラーが頻発して手の施しようがなくなったときの最後の手段にしておきたい、というのが私の考えだ。そこで、ディストリビューション全体のレベルでのクロスグレードが実行可能かどうかを確かめることにした。
警告： Fedora環境のアーキテクチャの32ビット版から64ビット版への変更は推奨されるものではなく、またいかなる形でもサポートされていないため、適切なバックアップを取ってから自己責任で行うこと。
試しに、VMwareのサーバインスタンスにFedora 7のi386版をインストールして、ホスト側仮想マシンのCPUアーキテクチャを64ビット版に変更した。続いて、この仮想マシンをFedora 8のx86_64版DVDイメージからブートする。既存のLinux環境をアップグレードするオプションを選択すると、インストーラから既存の環境とDVDイメージとでアーキテクチャが異なる、との警告が出た。不吉なことに、“この操作は続行するな”とのメッセージも添えられている。だが、私はこの警告を無視した。すると、アップグレード作業は何事もなく進み、普通に仮想マシンをリブートすることができた。また、クロスグレード完了後も仮想マシンは万事問題なく動作しているように見えた。こうして仮想環境での成功を得た私は、いよいよ実環境でのライブシステムのクロスグレードに取りかかることにした。
この作業に取り組む場合は、Clonezillaのようなツールを使ってシステムの完全バックアップを行うことをお勧めする。そうしておけば、システムのクロスグレードに失敗しても、移行を試みる前の状態にすぐに戻すことができる。
また、必要になりそうなRPMファイルはすべて作業開始前にダウンロードしておきたい。Fedora 8のEverythingディレクトリとupdatesディレクトリをミラーリングしている場合は、厳密には必要のないファイルまでダウンロードすることになるが、厄介なアップグレード作業の途中で600MBものデータのダウンロード待ち状態に陥るよりはずっとマシだ。2007年12月時点で、DVDイメージ「Fedora-8-x86_64-DVD.iso」のサイズは3.7GB、Fedora 8 のx86_64用Everythingディレクトリは12GB、同じくx86_64用updatesディレクトリは3.2GBとなっている。Everythingディレクトリの取得と、そのためのyumのローカルリポジトリ設定には、以下に示すスクリプトを使用する。ただし、wgetに与えるURLは利用できる最も高速なFedoraミラーに変更すること。新しいローカルリポジトリ用にyum.repoファイルを作成することで、それらをデフォルトの「fedora.repo」および「fedora-updates.repo」ファイルよりも優先して使うことができる。なお、「/yum-repo-mirrors」は次のすべてのデータが入るほど大きなパーティションでなければならない。
# cat f8everything.sh #!/bin/bash mkdir -p /yum-repo-mirrors/f8everything cd /yum-repo-mirrors/f8everything wget -Y off -m "ftp://mirror.../pub/fedora/linux/releases/8/Everything/x86_64/os/Packages/" cd /yum-repo-mirrors/f8everything nice createrepo `pwd` /etc/yum.repos.d]# cat f8everything.repo [f8everything] name=Fedora $releasever - $basearch baseurl=file:///yum-repo-mirrors/f8everything/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
実インストール環境のアップデート
必要な全パッケージのダウンロードとシステムの確実なバックアップを行ったうえで、Fedora 7のi386環境が入ったマシンをFedora 8のx86_64用DVDイメージからブートした。データベースサーバを実行している場合は、アップデート前にテキスト形式のSQLファイルにバックアップしておく。また、ネイティブのバイナリ・オンディスクフォーマットを使用しているものも32ビットから64ビットへの変更の影響を受けやすい。
アップグレードが始まって早々、「/usr/tmp」が正しいシンボリックリンクではない、というメッセージが表示された。「/usr」でXFSファイルシステムを使っていたが、「/etc/fstab」ではファイルシステムの種類をautoとしているためだとわかった。Fedora 8のDVDではこれが受け入れられず、「/usr」のマウントに失敗した。「/etc/fstab」でこのファイルシステムの種類をxfsに変えることにより、上記の問題は解決された。
アップグレード中、やはりアーキテクチャの違いに関する警告が出たが、仮想マシンのときと同様にそのまま作業を進めた。だが、何らかの理由により、私のインストール環境ではGNU GRUBのアップグレードが行えなかった。とりあえず、ブートの設定は以前のままにしておき、あとで修正することにした。
アップデート作業の終了後、リブートをかけると、GRUBに新しいカーネルが表示されたので、それを選んでブートした。GRUBのアップデートの問題がなぜ起こったのかはわからないが、とにかくブートは何の障害もなく完了した。
早速、オーディオの再生に関する問題に見舞われた。Fedora 8ではPulseAudioに移行しているのだが、それがうまく動作しなかったのだ。この問題を解決するために、自分のユーザアカウントをpulse-accessグループに追加し、「~/.xinitrc」ファイルに「pulseaudio -D」と書き加えたところ、PulseAudioデーモンの動作が確認できた。また、一部のメディアプレーヤもうまく動作しなかった。おそらく、システムライブラリが新しいバージョンにアップデートされ、もはや存在しない共有ライブラリをメディアプレーヤの実行ファイルが探していたためだろう。だが、これは64ビット版へのクロスグレードに特有の問題ではなく、32ビット版のFedora 8にアップグレードしても同じことが起こったはずだ。
アップデートによって問題が起こるだろうと予想していた点の1つが、整数のサイズの違いだった。直接RAMの内容をダンプしてバイナリファイルに状態を格納するアプリケーションの場合、32ビット環境用の設定ファイルは64ビットのインストール環境下では動作しない。バイナリ形式のboost::serializationを使用しているアプリケーションは今回のアップデートの影響を受けるため、設定ファイルを手作業で修正しなければならなかった。
この時点で、私のシステムはi386とx86_64のRPMが混在する奇妙な状況にあった。devel RPMの大半はi386用のものしかなかった。それらのアップデート版はFedora 8 DVDに含まれていないからだ。RPMのファイルもやはり32ビット環境で実行中とレポートされるだろう。以下に、i386用のRPMパッケージを削除する前後で、どのアーキテクチャ上で実行されているかに関するRPMの初期レポートがどう変わったかを示す。
# rpm --eval '%{_arch}'
i386
# rpm -e rpm.i386 rpm-python-4.4.2.2-2.fc7.i386 rpm-build-4.4.2.2-2.fc7.i386
# rpm --eval '%{_arch}'
x86_64
i386とx86_64の双方のパッケージがインストールされたあと、まだアップデートが必要なものと削除して構わないものの区別を容易にするために、各パッケージがどちらのアーキテクチャ向けにコンパイルされたかをRPMに表示させるようにした。
# vi /etc/rpm/macros
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
%_query_fmt %%{name}-%%{version}-%%{release}.%%{arch}
また、rpmとyumがデフォルトでx86_64用パッケージを取得するようにrpmのプラットフォーム・ファイルを更新する必要もあるだろう。
# cat /etc/rpm/platform x86_64-redhat-linux
i386用とx86_64用のパッケージが混在しているので、yumにはexcludeオプションを適用する必要があった。通常はyumで明示的に「foo.x86_64」と指定すれば、依存関係ファイルも64ビット版がインストールされる。
# yum install --exclude="*.i386 *.586 *.686" foo
この時点で、ほかのパーティションがまったくマウントされていないことに気付いた。「/etc/fstab」を調べると、アップデートによってこのファイルの内容がクリーンアップされ、ファイルシステムの種類がautoのパーティションなど、理解されなかったものはすべて削除されていた。これには参った。というのも、私は「/etc/fstab」ファイルに多数のコメントを残していて、一部のファイルシステムはコメントアウトしていたからだ。そのため、新しい「/etc/fstab」と（もちろんバックアップは済ませてあるだろうから）バックアップしておいたものを手作業でマージする破目になった。
また、クロスグレード時のfstabのクリーンアップにより、共有メモリデバイスである「/dev/shm」も破壊されていた。私の環境では、4つのファイルシステムをさまざまな用途向けにtmpfsタイプとしてマウントしていた。クリーンアップ後も残ったのは最初のtmpfsファイルシステムだけで、それは「/dev/shm」ではなかった。「dev/shm」がtmpfsとしてマウントされていない状況では、共有メモリは機能しなかった。
クロスグレード後の環境を適切なものにするために、i386用のdevelパッケージをアップデートし、Fedora 8のupdatesリポジトリから新しいアップデートも用意した。その際、一部のパッケージについては手を加えなければならなかった。単純なyumアップデートで依存関係の解決を試みたところ、25のライブラリが壊れていると表示された。大抵の場合、この問題は「RPM -e package.i386 」に続けて「yum install package.x86_64 」を実行することで解決できる。Fedora 8 x86_64ディストリビューションでは、1つのパッケージにi386用とx86_64用の双方のRPMが付随している場合がある。また、Fedora 7のi386用RPMとFedora 8のx64用RPMの間には、互換性がない可能性がある。たとえば、以下のコードはCinePaintにおいて互換性がないことを示している。この問題は、i386用のパッケージを削除するか、ローカルリポジトリのミラーディレクトリに移動したうえで次のように新しいほうのパッケージを強制的にアップデートすることで解決できる。
file /usr/lib/python2.5/site-packages/gimpui.pyc from install of cinepaint-0.22.1-5.fc8 conflicts with file from package cinepaint-0.22.1-4.fc7 ...
このようなパッケージはいくつかあり、たとえばkoffice-krita、NetworkManager、mono、gstreamer、rubyなどがそうである。なお、MonoとGstreamerの問題はi386用RPMをrpmコマンドを使って手動でFedora 8のRPMファイルにアップデートすることで解決できた。
yum updateによる次なる試みでは、合計ダウンロードサイズが339MBと表示されたものの、トランザクションテストの途中、再びファイルの互換性の問題で失敗した。こうした問題は、互換性のないi386用のRPMをシステムから削除することでx86_64用のRPMだけがインストールされ、解決できる場合がある。gnome-keyring、gphoto2、nas、openldapなど、大きな依存関係ツリーを持つi386用パッケージの場合は、EverythingまたはupdatesのリポジトリミラーにあるRPMファイルで強制アップデートを行ったほうがよいだろう。強制アップデートにより、パスの競合がなくなり、yumによってシステムのほかの部分が問題なくアップデートされる。
セカンドシステムのクロスグレード時には、以下のようなコマンドを使って、すべてのdevelopmentパッケージのx86_64版をインストールしてからi386用パッケージを削除するようにした。i386用のdevelopmentパッケージがすべて削除されたら、再びrpmを実行して問い合わせを行い、すべてのパッケージでx86_64版がインストールされていることを確認するとよいだろう。
# cd /tmp
# rpm -qa --queryformat '%{name}.%{arch}\n' |grep i386 >| /tmp/i4
# yum install $( grep devel /tmp/i4|sed 's/.i386/.x86_64/g' | tr '\n' ' ' )
# yum remove $( grep devel /tmp/i4 | tr '\n' ' ' )
また、共有ライブラリの検索パスにlib64を追加しておく必要もある。
# cat /etc/ld.so.conf.d/usr-local.conf /usr/local/lib /usr/local/lib64
まとめ
Fedora 7のi386環境からFedora 8のx86_64環境へのアップデートはサポートされていないため、多くの人は64ビット版Linuxに移行するには再インストール（クリーンインストール）するしかないと言うだろう。しかし、私はyum update実行時の主な問題をわずか1日で解決することができた。ただし、その手間は利用しているサードパーティ・リポジトリ、自分でインストールしたソフトウェアの量、システムライブラリに対するソフトウェアの依存度によって変わってくるだろう。
Ben Martinは10年以上もファイルシステムに携わっている。博士号を取得し、現在はファイルシステムlibferrisと検索ソリューションに注力している。
