« | »

2013.12.17

CentOS6.5⇒6.4ダウングレード無事成功

12月15日早朝から行っていた、親(Host)サーバーのCentOS6.5から6.4へのダウングレードは無事完了しました。

結果的には力技でのダウングレードですが、今のところ問題なく動作。

また同じようなことがあったときの備忘録として記載します。

 

ダウングレードの選択肢。

CentOSの場合、ダウングレードの方法は

1.インストーラディスクで完全にシステムをクリーンインストールしなおす

2.yumのリポジトリ情報を強制的に過去のバージョンにして、過去のパッケージを強制上書きする

という方法が考えられます。

 

一番確実なのは1.のクリーンインストールしてしまうという方法。

しかし、今までセットアップした設定をもう一度しなければならないというおまけ付き。

非常に面倒です。

出来れば避けたいところ。

 

なので、2.のyumで強制的にシステムをCentOS6.4のパッケージで上書きしてシステムの再構築を実施します。

今回の場合システムのクリーンインストールを実行を考えていたところにyumでの強制上書きを実施しましたのでところどころ若干乱暴とも言えるコマンド操作も含まれています・・・が、そこは結果オーライということで。

 

yumで強制オーバーライトを実施する工程は下記の様になります。

1.yumのリポジトリを6.4に固定する。

2.yumのキャッシュエントリをすべて削除

3.yumリポジトリの内容で同期させる。(ダウングレード)

4.インストール前のチェックで弾かれたパッケージは手動で削除するので、yum同期後に手作業で削除したパッケージを再インストール。

 

1.yumのリポジトリを6.4に固定する

今回のアップグレードでわかったことは、CentOSがインストールするyumのリポジトリは常に最新パッケージを指し示すようになっていて、OSのバージョンという概念はないということ。

常に最新をリポジトリエントリに登録されていくので、結果として今回アップデートした内容がCentOS6.5になって更新されたということになります。

セキュリティという観点で考えるとこれは正解ではありますが、6.4は6.4の各モジュールのバージョンというものもあるわけで、場合によっては今回のように突然動かないアプリケーションも出てきますので、システムデフォルト設定のままでアップデート機能を使用するというのはちょっと危険…今回はそこが勉強になりました。

 

話を元に戻して、yumのリポジトリをバージョン固定化するのはわりと簡単です。

編集するファイルは /etc/yum.repo.d/CentOS-Base.repo

このファイルにリポジトリのurl情報が格納されています。

実際に編集する前に念のため、/etc/yum.repo.d/CentOS-Base.repoのバックアップを取っておきます。

 

次に、/etc/yum.repo.d/CentOS-Base.repoをvimなどで開いて、リポジトリのバージョンを示している「$releasever」の文字列を「6.4」に書き換えます。(vimでは、”:%s/$releasever/6.4/g“と入力すれば一括置換してくれます。)

 

これで6.4パッケージのバージョンアップはそのままに、6.5以上のパッケージはダウンロードされないようになります。ただし、既に古いバージョンとなっているわけですから、おそらくパッケージの更新はないと思います。

KDD-Labのftpサイトに入って6.4のパッケージを確認しても、2013/11/30以降パッケージは更新されていないようで、そこは想定内ということでダウングレードします。

 

2.yumのキャッシュエントリをすべて削除

親(Host)サーバーでは何度かパッケージの更新を行っていますので、ダウンロード済のパッケージ情報がキッシュされています。 これをそのまま残しておくとリポジトリは6.4のポインタをさして、キャッシュは直近アップデートした内容を保持するという不整合が発生します。

今回は何が記録されていようとも、リポジトリの内容に置き換えるわけですからyumのキャッシュデータは初期化 (削除)して しまいます。

 

コマンド # yum clean all

 

3.yumリポジトリの内容で同期させる。(ダウングレード)

準備が整えば、ダウングレード作業の開始です。

コマンド #yum distribution-synchronization

を実行して、yumリポジトリの内容と同期するように指定します。

リポジトリは6.4の最終リリースを指し示していますので、これで同期するということは6.5から6.4Finalにダウングレードするということになります。

 

[root@server_host yum.repos.d]# yum distribution-synchronization
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * base: mirror.fairway.ne.jp
 * extras: mirror.fairway.ne.jp
 * updates: mirror.fairway.ne.jp
Setting up Distribution Synchronization Process
Resolving Dependencies
--> Running transaction check
---> Package ModemManager.x86_64 0:0.4.0-3.git20100628.el6 will be a downgrade
---> Package ModemManager.x86_64 0:0.4.0-5.git20100628.el6 will be erased
---> Package NetworkManager.x86_64 1:0.8.1-61.el6_4 will be a downgrade
---> Package NetworkManager.x86_64 1:0.8.1-66.el6 will be erased

・・・・・・・・・・中略・・・・・・・・・・・

---> Package xorg-x11-server-common.x86_64 0:1.13.0-11.1.el6.centos.2 will be a downgrade
---> Package xorg-x11-server-common.x86_64 0:1.13.0-23.el6.centos will be erased
---> Package xorg-x11-xinit.x86_64 0:1.0.9-13.el6 will be a downgrade
---> Package xorg-x11-xinit.x86_64 0:1.0.9-14.el6 will be erased
--> Processing Conflict: p11-kit-trust-0.18.5-2.el6.x86_64 conflicts nss < 3.14.3-33
--> Finished Dependency Resolution
Error: p11-kit-trust conflicts with nss-3.14.3-4.el6_4.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

[root@server_host yum.repos.d]#

 

依存性確認のところで、いくつかコンフリクトが発生してErrorで停止しています。この段階では依存チェックなので書き込み動作は何もしていません。 ダウングレードを実行するのですから過去のパッケージに戻るために依存チェックで引っかかるのは致し方ないところ。

 

yumのメッセージとしては、“yum distribution-synchronization –skip-broken”を試してみてはどうか、“rpm -Va –nofiles –nodigest”を試してみてはどうか…とヒントを表示してくれますが、これらはおそらく役に立たないと思います。

私の環境で –skip-brokenオプションを実行して、細かく依存性確認を実施しましたが6時間かけてチェックして成果なしの結果となりました。 rpmにしても同様。

依存性確認のチェックを通らないとパッケージのダウンロード/インストールが開始されませんので、ここは強制的にチェックが通るようにします。 つまり、依存性エラーのパッケージは削除する…です。

 

コマンド #yum remove パッケージ名

で、コンフリクトを発生したパッケージをすべて記載して削除します。

(削除したパッケージはメモしておいてあとで手作業で再インストールします。)

今回のダウングレードでは“p11-kit-trust”パッケージのみコンフリクトを発生していましたので、このパッケージを指定します。

・・・しかしこのパッケージは他のパッケージとの依存関係あり上手く行きません。

依存関係があるものが多い場合、手間も膨大。

 

ここで熟考…同期チェックではこれら依存関係にあるものはErrorで弾かれていないようなので、ならば問題のものだけを強制的に削除してしまえ…と、強制削除を実施。(ちょっと乱暴ですが、「ダメなら再インストール」という気持ちで挑んでいるので許してください)

 

コマンド #yum remove –nodeps パッケージ名

–nodepsオプションを指定すると依存関係無視して当該パッケージを削除してくれます。

 

ここまで実施したたら再度 #yum distribution-synchronization を実施します。

 

今度は整合性チェックはOK…そのままパッケージダウンロード/インストールに進みました。

個々の環境に依存すると思いますが、今回ダウングレードに必要になったパッケーでは270個/233MBです。

20分もあればダウンロード/インストール/検証は完了しました。

 

4.手作業で削除したパッケージを再インストール。

3.の同期化のところでコンフリクトしたパッケージをインストールします。

 

コマンド #yum install パッケージ名

実行結果は…“既にイントールされているよ”というもの。

うーむ、削除したパッケージが同期化の途中で依存性解消のためインストールされていたようです。

それはそれで良いことなのですが、ちょっと気持ち悪いですね。

でもインストール時の検証工程で依存性に破綻はでていなかったようなので、これで様子を見てみることにします。

 

なお、この同期化処理ではパッケージのみが同期化されていますので、例えばLinuxカーネルなどは通常アップデート時には上書きではなく複数のバージョンが/bootに保存されています。

当然、CentOS6.4(Final)のカーネルがインストールされますが、grubのkernel起動設定は要確認です。

もしかしたら正しい値が書き込まれていない可能性があるので、起動するLinuxバージョンが、kernel-2.6.32-358.23.2.el6~となっているかdefault=xの値を確認します。

その後システムを再起動して、CentOSが6.4に戻っているか確認します。

 

ダウングレード前

20131214CentOS6.5

 

ダウングレード後

20131215CentOS6.4

 

問題なくダウングレードは実施できました。

CentOS6.5の時は起動できなかったVMwareWorkstation9も無事起動します。

VMware社がCentOS6.5対応の更新が実施されれば、また改めてOSのアップグレードを実施しようかと思いますが、Workstation9はすでに一つ前の世代。 微妙。

駄目なら駄目でそのとき考えるようにします。

公開サーバーはすべて仮想サーバーで行っていて、今回ダウングレードしたこのサーバーはファイヤーウォールでほとんど外部からのアクセスを遮断しているので無理にOSをアップグレードする必要はないかも知れないからです。

 

Trackback URL

Comment & Trackback

No comments.

Comment feed

Comment





XHTML: You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">