前の投稿からの続きです。
無事にインストールが済んだとしても、 gentooはローリングアップデートですので頻繁に更新作業が発生します。
最近のディストリではsynaptic等で更新が降りて来ますので 感覚的にはそう差もなくなっていると思うのですが、 gentooはカーネルの更新も含めて全ての更新が日常茶飯事です。 作業的に逼迫している時にカーネルや大型のソフトウェアのアップデートがくると 優先順位に頭を抱えることもしばしばあります。
これがストレスになり、gentooを見限るケースもあるようです。 コストの配分はそれぞれなので、それも正しい判断だと思います。
さてさて。やっと書きたかったことに辿り着きました。 アップデート作業の手順を記録しておきたかったのです。
アップデート作業手順
環境によって差異はあるのですが、 自分の場合、起動はgrub2です。 systemdへは移行しておらずOpenRC環境です。
カーネル構築はgenkernelを使用します。 以前はmakeを叩いていたのですが、/usrをパーティション分けしていたことにより、 initramfsが要求されるようになり、手作業でのinitramfs構築に挫折しました。
各種設定
layman, eix, equery, dispatch-confを導入してあり、 カーネルはgentoo-sourceのUSE=symlinkが入っています。
- layman
- 追加の拡張ebuildを導入できる
- eix
- ebuildの検索が便利になる
- equery
- ebuildの依存関係や所属ファイルなどを検索できる
- dispatch-conf
- /etc以下の設定ファイルを確認しながら更新できる
- USE=symlink
- カーネルが更新されたときに/usr/src/linuxを自動でリンクする
と、それぞれ便利なツールです。
emerge完走まで
su
# ルート権限取得
screen -D -RR
# 必須ではありませんが、screenやtmuxのようなバックグラウンド実行できる環境で作業すると少し早くなる
emaint sync -a && eix-update && emerge -pvDNu @world
# 更新内容を確認して吟味する
# 不安な予兆を感知したら数日待つと更新内容が変わることもよくある
# ・ディスク容量が足りない
# ・ライセンスの設定が必要
# ・ライセンス絡みでファイルを自動でダウンロード出来ない
# 上記のような要因が起こると、ここで警告が出て止まるので出力に従って対処する新しいnews があったら
maskやuseで競合が起こったら
emerge --autounmask-write -vDNu @world
dispatch-conf
emerge -pvDNu @world
# 設定を自動更新して再度確認
# これでも競合が解消されなければ手作業でmaskやuseを調整Blockが起こったら
equery d <package>
# 依存関係を確認して、"emerge -C" でアンインストールするなりmaskするなりして対処
emerge -vDNu @world
# 実際に更新作業を開始
# 状況では数時間かかることもebuild側での依存関係の設定ミスやコンパイラが駄々をこねたりして途中で止まったら
個別アップデート対応
該当するパッケージがアップデートされていた場合、手を加える必要がいくつかあります。
gcc
下記のパッケージをインストールしている場合、更新が必要です。
- sys-devel/libtool
- sys-devel/llvm
- sys-devel/clang
python
perl
ruby
その他eselectに対応したもの
ライブラリ依存関係解消
現在はemergeに@preserved-rebuildが実装されているので必要なくなりましたが、 以前はライブラリの依存関係の修復に“revdep-rebuild”コマンドを使用する必要がありました。
今では滅多にないことですが、 何度か“revdep-rebuild”を打つようにとのログが出たことがあります。
-i オプションを付与することを推奨します。 たった一度だけですがhalかudevあたりの更新が頻繁に起こった時期に -iオプションを渡さないと依存関係を追跡してくれないという事象が起こりました。 それ以来、盲信的に-iを渡しています。
カーネルの更新
cd /usr/src/linux
cp ../<起動してるカーネルのソースディレクトリ>/.config ./
genkernel --oldconfig all
ls /boot/
# カーネルを更新して確認
grub2-mkconfig -o /boot/grub/grub.cfg
# grub2を更新
emerge @module-rebuild
dispatch-conf
# モジュールと設定を更新
reboot
# 再起動します
# Xを起動すると止まる場合
# 再起動後に上記のモジュール更新が必要emerge のログをメールで受け取る
個別アップデート対応が必要な作業は基本的にログに指示が出力されますので、 よく確認して漏れがないようにしなければなりません。
このため、emergeのログをメールで受け取れるように設定しておくと便利です。
sendmailコマンドでメールが送れるように設定してあることが前提です。
/etc/portage/make.conf に下記を追加します。
PORTAGE_ELOG_CLASSES="info warn error log qa"
PORTAGE_ELOG_SYSTEM="save_summary mail_summary"
PORTAGE_ELOG_MAILURI="<メールアドレス> /usr/sbin/sendmail"後片付け
更新は終わりましたが、作業領域の削除など、後片付けが残っています。
カーネルの片付け
portageの片付け
ls /var/tmp/portage
rm -rf /var/tmp/portage/*
# コンパイルに使用したワークディレクトリを確認
# 途中で止まった場合などに作業領域が残っている。消して構わないemergeオプション
–with-bdeps=y
emerge --depclean時にemerge --update --newuse --deep --with-bdeps=y @world を実行するよう指示がでることがあります。
--with-bdeps=yを指定すると、 依存関係の追跡に厳密には必要ないが、ビルド時に必要な依存関係を追加します。
これにより、インストール時にはそれらがインストールされるようになり、 –depclean時にはそれらも含めて削除されるようになります。
私は変更していませんが、/etc/portage/make.confに下記のように記述しておくと、 デフォルトの振る舞いを変更できるようです。
-e
コンパイラのバージョンが上がりバイナリの互換性が失なわれたときなど、 全てのパッケージを更新するときはemerge -eを使用します。
依存関係がどうしても解消できない時に、 これにより解決するということもあるかもしれません。 しかし、その場合ebuildが間違ったものであったということですので、 近いうちに修正されるものと思われます。 emerge -eは時間もかかりますから、緊急手段として使うのはお勧めしかねます。
おつかれさまでした
改めて書き出してみると、さすがに厄介なものだなという感じが拭えません。
しかし、実際には、競合やメンテナンスが必ず起こるわけではありません。 後片付けも、余裕があるときに行えばよいものです。 よって、もっとも平穏にアップデートが済んだ場合、
emaint sync -a && eix-update && emerge -pvDNu @world
emerge -vDNu @world
dispatch-conf
emerge --depcleanと、これだけです。
変更履歴
2018-06-22
- gcc のアップデートに sys-devel/libtool sys-devel/llvm sys-devel/clang を追加
2017-12-05
- Python: python-updator を消去
2016-07-19
- “emerge –sync” -> “emaint sync -a” 修正
2016-07-15
- 段落の前後を入れ替える等、全体の構成を微調整
emerge --with-bdeps=yについての記述を追加emerge -eについての記述を追加
0 件のコメント:
コメントを投稿