先日Ubuntu 14.04.1 LTSがリリースされました。そこで今回は、前回のLTSであるUbuntu 12.04から、最新のLTSであるUbuntu 14.04へアップグレードする際に知っておいたほうが良いこと、注意すべき内容をご紹介します。
LTSとポイントリリースのおさらい
既にLTSであるUbuntu 12.04をお使いの方ならご存知だとは思いますが、Ubuntuの長期サポート（Long Term Support）とポイントリリースについておさらいしておきましょう。ちなみにSoftware Designの2014年6月号 には、あわしろいくやさんによる詳しい解説もありますので、興味のある方はそちらも併せて参照してください。
なお、ここで説明する話はあくまで2014年現在の情報に基づいています。これまでにも何度かあったように、サポート期間やその提供方法はコミュニティを取り巻く状況やCanonicalのお財布事情に合わせて変わって行きます。
長期サポート（LTS）について
Ubuntuは4月と10月、半年毎の定期的なリリースを行っています。通常のリリースのサポート期間は9ヵ月です。よって、10月にリリースされたバージョンは次の4月のリリースの3ヶ月後にはサポート期限を終えます。サポート期限の終了を「EOL（End of Life） 」と呼び、より新しいリリースへのアップグレードを呼びかけるアナウンスが流れます。たとえば、2013年10月にリリースされた13.10は7月17日にEOLを迎えました 。よって、12.04以降の通常リリースを使っている方はほとんど既に14.04にアップグレードされていることでしょう[1] 。
通常のリリースとは別にUbuntuでは2年に1回、より長期間のサポートを行う「長期サポート版（Long Term Support） 」をリリースします。LTSでは原則として5年間のサポート期間が設けられています。つまり通常のリリースが次のリリース後それほどせずにアップグレードする必要があるのに対して、LTSでは「次の次のLTS」がリリースされるまでは同じバージョンを使い続けることができるわけです。
前回のLTSは2012年4月にリリースされた12.04でした。そして2年後の2014年4月にリリースされた14.04もまたLTSとなります。12.04は2017年、14.04は2019年までサポートされます。
フレーバーやリミックスといった公式の派生物 となるKubuntuやXubuntu のLTS対応やその対応期間についてはその開発コミュニティの判断を基にTechnical Boardが決定しています。詳しくは14.04リリース時のアナウンス を参照してください。
ではこの「サポート」とはなんでしょうか。Ubuntuにおいては、おもに次の3つが提供されることを意味しています。
main、restrictedコンポーネントに対するセキュリティチームによるセキュリティアップデート
universe、multiverseコンポーネントに対するコミュニティによるアップデート
最新のパッケージを配信するアーカイブサーバー
ちょっとややこしいのですが、Ubuntuは「コミュニティによって」開発されているLinuxディストリビューションです。Canonicalはその開発コミュニティを金銭的に支援しているに過ぎません。よってUbuntuにおける「オフィシャル」とは「開発コミュニティ」を指します。Canonicalではありません。少なくとも建前上は。
Canonicalは開発コミュニティ支援の一貫として、セキュリティチームメンバーをフルタイムワーカーとして雇っています 。オフィシャルの開発コミュニティによるセキュリティサポートは、セキュリティチームによるサポートであり、結果的にCanonical社員によるセキュリティサポートとなっています。universe、multiverseの「コミュニティによる」は、セキュリティチーム以外の開発コミュニティも担当するアップデートということになります。
「main、restricted、universer、multiverse」は、コンポーネント と呼ばれるパッケージのカテゴリーの一種です。セキュリティチームによるメンテナンスが行われるかどうか、と、フリーソフトウェアであるかどうかをおもな判断基準として振り分けられています。
さて気を付けなければいけないのは、サポート期間において最も重要である「セキュリティアップデート」はmain、restrictedコンポーネントに対してのみ保証されているということです。もちろんuniverseやmultiverseのコンポーネントに対してもセキュリティアップデートは行われますが、これはボランティアで構成される開発コミュニティによる作業となりますので、場合によってはいつまでたっても修正されないということも起こり得ます。同様にLTSもあくまでmainコンポーネントに対するサポート期間ですので注意してください[2] 。
ポイントリリースについて
ポイントリリースは、LTSのリリース後に一定期間ごとに提供される、最新のアップデートを適用したインストールメディアです。
LTSは5年間サポートが継続します。リリース後もさまざまなパッケージがアップデートされますので、リリース時のインストールメディアを使ってインストールした場合、インストール直後にかなりの数のパッケージをアップデートする必要が出てきます。これは手間がかかるうえに、セキュリティ的にもネットワーク的にもあまり嬉しくありません。
そこでLTSでは、LTSのリリースから数ヵ月後に1度、さらにその後の通常リリースから数ヵ月後に1度ずつ次のLTSがリリースされるまで、それまでのアップデートを適用したインストールメディアを「ポイントリリース」という形でリリースしています。
ポイントリリースではバージョン番号の後ろに数字を追加します。14.04の最初のポイントリリースは7月25日にリリースされた 14.04.1ですし、12.04の5回目のポイントリリースは12.04.5です。後述するHWEに関する例外を除いて、アップデート適用済みのインストーラーと言う位置付けなので、普通にLTSをインストールした環境をアップグレードして言っても、ポイントリリースと同じ環境になります。
たとえば14.04をインストールした環境を最新の状態にアップグレードしていれば、次のように「14.04.1」と表示されていることでしょう。
$ lsb_release -d
Description: Ubuntu 14.04.1 LTS
LTSでは、HWE（Hardware Enablement） Stacks という名前で、より新しいカーネルやドライバー、それを動かすためのソフトウェアを提供しています。ポイントリリースでは、このHWEが適用済みの状態でインストールされるため、14.04のリリース時には不具合があったり、ドライバーがないことによってインストーラーが動作しなかったハードウェアに対しても、Ubuntuをインストールできるようになっている可能性があります。
ちなみにLTSをインストールした状態から普通にアップデートするだけではHWEは適用されません。HWE用のパッケージをインストールする必要があります。また12.04において、12.10から13.10までのHWEを適用した場合、今後それらのHWEは更新されませんので早急に14.04のHWE（パッケージ名にtrustyと名前のついているHWE）を適用してください。Server版であれば、おそらくログイン時に次のようなメッセージが出ているはずです[3] 。
14.04のHWEパッケージをインストール済みの場合：
Your Hardware Enablement Stack (HWE) is supported until April 2017.
グラフィカルスタックもインストールしている場合：
There is a graphics stack installed on this system. An upgrade to a
supporte (or longer supported) configuration will become available
on %(date)s and can be invoked by running 'update-manager' in the
Dash.
コマンドで確認したい場合：
$ hwe-support-status
Your Hardware Enablement Stack (HWE) is supported until 4月 2017.
HWEに関しては第278回 の記事でも紹介していますが、Software Designの2014年6月号のほうがより詳しく最新の情報に追随しています。
LTSからLTSへのアップグレードについて
LTSは2年ごとにリリースされますのでLTSの間には3回の通常リリースをはさんでいます。あるLTSから次のLTSにアップグレードしたいとき、この通常リリースを経てアップグレードを行うのは手間がかかりますし、そもそもサポートが切れたリリースを使うことはセキュリティを考えると現実的ではありません。そのためLTSでは、LTSからLTSへと直接アップグレードする仕組みを用意しています[4] 。
Ubuntuは次のバージョンが正式にリリースされたら、アップデートマネージャーで、リリースされたこととアップグレードを促す通知が表示されます。しかしながらLTSの場合は、次の通常版をリリースしてもアップグレード通知が行われず、「 次のLTSの最初のポイントリリースをリリース」してはじめてアップグレード用のメタデータ が更新され、アップグレード通知が表示されるようです[5] （ 注6 ） 。
図 アップデートマネージャーによる通知アップグレードの手順はとてもかんたんで、デスクトップ版であればアップデートマネージャーの指示に従うだけ、サーバー版であれば以下のコマンドを実行するだけです[7] 。
$ sudo apt-get install update-manager-core
$ sudo do-release-upgrade
アップグレード中いくつか問い合わせ画面が表示されますので、適宜回答を行ってください。時間はかかりますが最終的にアップグレードが反映されて再起動したらアップグレード完了です。
12.04からの大きな変更点
おそらく12.04を使い続ける方はそろそろ14.04への移行を考えているところだと思います[8] 。Ubuntu 12.04 LTSから約2年。Ubuntu 14.04 LTSは12.04と比べてどんな風に変わっているのでしょうか。一番手っ取り早いのは、12.04からのリリースノートをすべて読むことです。
一応14.04のリリースノートは12.04からアップグレードする利用者のことも考えて記述はしているようなのですが、残念ながらUbuntuのリリースノート自体が網羅性が低く、取りこぼしているものも数多く存在するため、12.10から一通り読んだほうがより安全です。
12.04の利用者にとってとくに注意の必要な違いは次のとおりです。
Unity 2Dが廃止されました。
3Dアクセラレーションが動作しない環境でもGallium llvmpipeなどを使った描画が行われるため、Unityが使えなくなると言うわけではありません。ただしCPUの性能が悪い場合は、これまで以上にデスクトップが重く感じるかもしれません。どうしても重い場合は、他のデスクトップ環境への移行も考えてみてください。Unity自体の軽量化はだいぶ進んでいるため、3Dアクセラレーションさえ有効であれば12.04よりも動作がかなり軽快になっているはずです。
Unityが5.xから7.xになりました。
Unity自体は見た目や細かい機能がいろいろと変わってはいるものの、大きな変更はないのでそれほど操作に戸惑うことはないでしょう。注意すべき点として、Unity検索時に検索クエリーをインターネットに送るということです。この挙動を変えたい場合は、システム設定の「セキュリティとプライバシー」から設定を変更してください。
新しくWebApps という機能が追加されました。
これは、任意のWebサービスを1つのアプリケーションとして独立したウィンドウで起動したり、専用のメニューを表示できるようになる仕組みです。対応済みのサービスに通常のブラウザーからアクセスした場合、WebAppsを追加するかどうか問い合わせてきますので、必要に応じて使い分けると良いでしょう。詳しくはあわしろいくやさんの第246回 の記事を参照してください。
ドライバーの設定場所が変わっています。
プロプライエタリなドライバーは、ソフトウェアセンターのソフトウェアソースにある「追加のドライバー」タブでインストールできるようになりました。
Ubuntu Oneクライアントが削除されました。
オンラインストレージとしてのUbuntu Oneサービスが終了 しました。このためクライアントなどはインストールされません。14.04でのサービスの移行先の例などはきっと誰かがRecipeで書いてくれるはずです。きっと書いてくれるはずです。
UEFI Secure Bootに対応しています。
マウントポイントが変更されています。
udisks2になったことで、USBディスクなどを接続したときの自動マウント時のマウントポイントが/media/$DISKから/media/$USER/$DISKに変更になって います[9] 。
initデーモンはUpstartのままです。
12.04と比べるとかなり多くの機能が追加されています。今後14.10から16.04にかけてsystemdへの全面移行が行われる予定ですが、14.04を使い続ける限りはUpstartを使うことになります。ちなみにudevやlogindのために、systemdもインストールされています。
インストールメディアが変更されました。
アップグレードする場合はあまり関係ありませんが、容量の問題でインストールメディアがCDからDVD（もしくはUSBメモリー）になっています。またデスクトップの推奨アーキテクチャも32bit版から64bit版に変更になりました。
Wubiが廃止されました。
Windows上にパーティションを切ってインストールするWubiは廃止になりました。またデスクトップ版のインストール時にWindowsからデータをマイグレーションする機能も廃止になっています。
いくつかのコマンドは標準でインストールされません。
gksuコマンドやatコマンドなどは標準ではインストールされなくなりました。必要な場合は手動でパッケージをインストールしてください。
日本語入力関係が変わっています。
日本語入力システムはIBusのままですが、バージョンの違いにより操作性が大きく変わっています。詳しいことはあわしろいくやさんによる第296回 や第319回 を参照してください。さらに日本語RemixではIBusの代わりにFcitxを標準インストールするようになりました。Fcitxについては第274回 や第297回 、先ほどと同じ第319回も参照してください。
LTSからLTSへアップグレードする際にやっておくべきこと
最後にLTSからLTSへ移行する前後で注意すべきポイントを列挙します。と言っても通常のアップグレードのときとほとんど変わりません。と言うか当たり前のことばかりです。
1．情報を収集する
当然のことながら、アップグレード前の情報収集は非常に重要です。とくに何かあったときのリカバリーの時間がだいぶ変わってきます。
たとえば使っているソフトウェアのバージョンやハードウェアの仕様など既存の環境の状態、PPAや外部リポジトリは何を使っているかと言った情報を集めたうえで、アップグレード先でそのハードウェアはサポートされているのか、何か問題は起きていないか調べましょう。その際は、リリースノートが役に立つ はずです。
ソフトウェアはメジャーバージョンが変わって仕様が変わっているかもしれませんし、パッケージの名前が変わっているかもしれません。「 dpkg --get-selections」を実行すればインストールしているパッケージ一覧をdpkgで読み込み可能なフォーマットで出力できます。「 dpkg --list」でバージョン一覧が出ます。「 apt-cache policy パッケージ名」と組み合わせれば 、外部リポジトリからインストールしたかどうかを確認できるでしょう。
PPAの場合は、12.04ではパッケージを提供しているけれども、14.04のパッケージは提供していないということもままあります。14.04では公式リポジトリからインストールできるようになっているのであれば良いのですが、そうでない場合は別途インストール方法を考えないといけません。各PPAのページ にある「Published in:」を対象のコードネームにしてFilterボタンを押せば、そのリリースでのパッケージが提供されているかどうかわかります。
不要なPPAがあるようであれば、第314回 で坂本貴史さんが紹介しているppa-purgeを使ってあらかじめ整理しておいたほうが良いでしょう。
2．本当にアップグレードが必要か考える
集めた情報を基に本当にアップグレードが必要かどうかを考えます。
LTSは5年サポートなので、12.04の場合は17.04まで使用できます。もし移行に際して何か障害があるのであれば、当面は12.04のままで14.04の修正を行うという対応も可能です[10] 。ただし3年後にはアップグレードが必要になることは覚えておいてください。
時間がないようであれば、もしくは他の理由を基にUbuntuではなくDebianやCentOSと言った異なるディストリビューションへの移行を考えるのも良いでしょう。
状況が許すなら「アップグレード」ではなく「クリーンインストール」を選択肢に入れることもお勧めします。LTSにしろ通常リリースにしろ、アップグレード自体はサポートしているものの、「 ちゃんとアップグレードできる」かどうかはその利用者の環境に依存します。とくにインストールしてから数多くカスタマイズしていたり、PPAといった外部リポジトリを追加した環境の場合、アップグレードに失敗する可能性が高くなってきます。
LTSをクリーンインストールするタイミングを奇貨として、一緒に不要なリポジトリの削除、インストール後に必要な作業の見直しやドキュメント化まで行ってしまえば、今後のアップグレードやインストール時に役立つでしょう。
[10] 実際のところこのような不具合修正は、14.04が「リリースされるより前に」確認し、不具合報告を行ったほうが修正期間や手間が短くなりますので、事情が許す限り新しいLTSのリリース前の数ヵ月は、積極的にテストに参加するようにしたほうが良いでしょう。
3．データのバックアップを取る
普段からやっておけばいいことではあるのですが、あらためてバックアップについても確認しておきましょう。とくにアップグレードに失敗した場合に本当にリカバリーできるかどうかが非常に重要になってきます。
あわしろいくやさんによる[11] 、第289回 と第290回 は前後編にわたって、特製のLiveイメージから起動してPC上のディスクにインストールされているUbuntuイメージを、そのまま別の外付けディスク領域にバックアップする方法を解説しています。さらにVirtualBoxへのリストアを行う方法も説明しているので、14.04への移行後に旧環境を確認したくなった場合も万全です。
4．最新の環境を試してみる
別のマシンを用意できるのであれば、先に新しいリリースをインストールして試してみるのは良いことです。物理マシンがなくてもVirtualBoxなどの仮想マシンでも試せます。
移行対象のマシンでテストするとすれば、先にHWEを使ってカーネルやグラフィックスタックだけ上げてしまうのも良いでしょう。カーネルについてはたとえ起動に失敗したとしても、GRUBのエントリーを書き換えるだけで元に戻せるのでお手軽です。
5．十分な時間と心の余裕を作る
アップグレードは時間のかかる作業です。アップグレードボタンを押してあとは放置、とできれば良いのですが実際はそう簡単には行きません。アップグレードを行う場合は万全の準備を行ったうえで、さらに時間と心の余裕をもたせたほうが良いでしょう。
伝え忘れていましたが、アップグレード時は新しいリリースのパッケージをダウンロードし、インストールすることになります。このため時間や心だけでなく、ネットワークトラフィックとディスク容量の余裕も持たせてください。前者はともかく後者は余裕がないと確実にインストールに失敗します。目安としては、クリーンインストールに必要な量と同じくらいのデータをダウンロードすると思っておきましょう。
6．アップグレードが完了したら
ここまでのことをやったうえで、アップグレードが成功したらほぼ勝ったも同然です。祝杯の準備をしつつ、アップグレードではケアされない部分の対応を行いましょう。
まずPPAを含むサードパーティのリポジトリはすべて無効化されています。/etc/apt/sources.list.d/以下にあるファイルの先頭の「# 」を外すなり、あらためてadd-apt-repositoryコマンドを実行するなりして、必要なPPAを有効化しましょう。日本語Remixの場合も日本語Remix用のリポジトリが無効化されていますので注意してください[12] 。
/usr/localなどに独自のソフトウェアをインストールしていた場合は、改めて動くかどうか確認してください。再コンパイルするだけで動くことも多いでしょう。また各種サービスが期待通り立ち上がっているかどうかのチェックも必要です。
不幸なことにアップグレードに失敗した場合は、状況に応じていろいろな対応方法が考えられます。do-release-upgradeコマンドがわかりやすいメッセージを出力している場合はそれに従ってください。大抵はすぐに解決するでしょう。do-release-upgradeが不正終了するようなケースは、リカバリーが難しいかもしれません。あらかじめ作成しておいたバックアップをリストアしてしまったほうが早いでしょう。
自力で解決したい場合、Launchpadやask ubuntuで「upgrade fail 」のような単語で検索すれば、いろいろとハウツーが見つかりますので、そこから対応方法を絞り込んでください。
[12] サードパーティリポジトリの無効化は/etc/update-manager/release-upgrades.d/thirdparty.cfgというファイルを作り、その中に「[Sources]」と「AllowThirdParty=True」の2行を追加すれば抑制できます。アップグレード中にサードパーティリポジトリが必要な場合は試してみてください。
まとめ
「Ubuntuはかんたん」とはよく言われることではありますが、アップグレード1つとっても「ハマる」ポイントはたくさん存在します。とくに初期設定状態から乖離すればするほど、つまり自分用にカスタマイズすればするほど、予想外の事態が起きやすくなるものです。
常に不具合の神様の数手先プラス斜め上下左右あたりを読みつつ、どうしようもなくなったときは笑ってすませられるような状況を用意して臨むようにしましょう。少なくともコンピューターは指示したとおりに動きます。へそを曲げることはあっても裏切ることはないはずです。Ubuntuハトモダチ、コワクナイ。
次週のUbuntu Weekly Recipeは、お盆休みをいただく予定です。
