この投稿に基づきます。
Archlinuxについては、完全に真実ではないものも含めて多くのうわさがあります。 特に、世間の一般的な意見では、Archは最新のものであるため、更新を頻繁に中断します。 実際には、これは、ほとんど毎日更新しながら、再インストールせずに何年も存続できる最も永続的で保守可能なシステムの1つです。
時には、年に1、2回程度、まだ問題が発生します。 いくつかの悪意のあるバグは、システムの更新後にリポジトリにリークすることがありますが、ユーザーとしては、これとはほとんど関係ありません。ロールバックする必要があります。
状況
次の更新で、すべてが壊れます わさび犬へ 。 考えられる問題のレベルは、「フォントがくなった」から「ネットワークが機能しなくなった」、「カーネルがディスクパーティションを認識しない」までさまざまです。 多くのArchユーザーは、この問題に何らかの方法で対処できます。この記事では、その方法を説明します。
システムの制御を戻す
修理するには、コンソールと稼働中のネットワークが必要です。 あれば、いいです。 そうでない場合、それらを保証する簡単で迅速な方法があります。 起動可能なUSBフラッシュドライブから起動し、ディスクパーティションをマウントして、システムにロールインします。
arch-chroot /mnt
それだけです、私たちはシステムのコンソールにいて、ネットワークがあります。
そして、武器庫にブータブルフラッシュドライブが存在することはほぼ必須です。
修復アルゴリズム
- 問題が自分で解決できないことを確認します
- 問題の原因と問題の更新日を特定する
- 代わりに/etc/pacman.d/mirrorlist
- パックマンをします
システムが修復されました！
仕組み
Arch Linux Archive （以前のArch Linux Rollback Machineと呼ばれる）と呼ばれる特別な更新サーバーがあり、個々の日付のすべてのリポジトリの「キャスト」を保存します。
ミラーリストファイルに特別な方法でサーバー名を指定することにより、希望する日付を選択できます。 古いファイルをバックアップし、新しいファイルを作成して、そこに1行追加するのが最も簡単です（この例では2017年12月1日）
## ## Arch Linux repository mirrorlist ## Generated on 2042-01-01 ## Server=https://archive.archlinux.org/repos/2017/12/01/$repo/os/$arch
その後、 pacman -Syyuuコマンドはパッケージデータベースを選択した日付に対応するデータベースに強制的に更新し、バージョンがこの日付と一致しないシステム内のすべてのパッケージを強制的に再インストールします。
私たちのタスクは、最も近い日付、作業システムに与えるロールバックを決定し、翌日に更新されたパッケージを見つけ、これらのパッケージのどれが故障を引き起こしたかを見つけることです。
さあ始めましょう！
希望の日付を決定する
システムがそれほど前に更新されていない場合は、毎回pacman -Syyuuを実行して問題が消えたかどうかを確認することにより、ミラーリストの日付を段階的に減らすことができます。 このアプローチの利点は、特定のパッケージをすぐに計算し、IgnorePkg行の/etc/pacman.confに追加できることです。
たとえば、最後の更新から1か月が経過している場合、時間間隔を繰り返し半分に分割します。 最初に、半月前にロールバックします。 問題が解決した場合は、1か月前に更新され、そうでない場合は1か月前に更新されます。 などなど。 この方法を使用すると、わずか9回の日付変更で、昨年中に発生した障害の正確な瞬間を特定できます。
犯人の特定
つまり、1週間更新されていません。pacmanは、更新されていないパッケージが200個あると報告しています。 アップグレード後、システムが故障します。
1日ロールバックします。いくつかのパッケージは以前のバージョンに「更新」されます。 チェック-システムはまだ壊れています。
別の日にロールバックし、さらにいくつかのパッケージがバージョンを減らします。 システムが壊れています。
別の日、次の3つのパッケージが逆に「更新」されて歓声を上げ、問題は解消されました！
これで、これら3つのパッケージのいずれかが原因であることが確実にわかりました。 linux 、 linux-headers、およびgnome-shellとしましょう。 linux-headersはlinuxの後に拡張されるため、それらは考慮されません。これは依存関係です。 したがって、2つのオプションしかありません。
次に、候補を1つずつ/etc/pacman.confに追加します。
linuxパッケージから始めましょう：
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup IgnorePkg = linux #IgnoreGroup =
次に、 pacman -Syuを使用してシステムを更新し、問題が解消されたかどうかを確認します。 それが消えた場合、犯人が更新が禁止されているとしてpacman.confに記録されたためです。 消えない場合は、作業システムにロールバックし、IgnorePkgに次の候補を入力して、サイクルを繰り返します。
最初にするアイテム
そして、実際には誰がバグですか？ この記事では、ディストリビューション全体のレベルの問題に焦点を当てています。 問題がそれらの更新によって引き起こされない限り、パッケージの古いバージョンにロールバックする意味はありません。 したがって、私たちが最初に行うことは、すべての可能な方法でエラーをグーグルし、新しいレコードのみの出力を設定することです。 問題が一般的な場合、公式の配布フォーラムで新しいスレッドに遭遇する可能性が非常に高く、問題の更新の正確な日付、問題のパッケージの名前、さらには技術的な理由（実際には内部で破られた）でさえ、すべての詳細がわかります。
上記の例をご覧ください。 gnome-shellパッケージをバージョン3.26.2に更新した後、システムがグラフィカルモードで起動しないことがわかったとします。
次に何をする？
まず、システムを機能させます-有害な更新よりも1日前の日付にロールバックし、 gnome-shellをIgnorePkgに追加します（オプションとして-gnomeグループ全体をIgnoreGroupに追加して、gnomeが部分的に更新されないようにします）。
次に、Googleで質問に対する答えを見つけようとします-「これは私の個人的な問題ですか、それとも他の人にも当てはまりますか？」 このような問題がインターネットで見つからなかった場合、これはバグが新鮮すぎることを示している可能性があります。 私たちは数日間、自信を持って待っています。時には異なる組み合わせで検索クエリを繰り返します。 問題が、問題のあるパッケージが実際にリポジトリにクロールしたことである場合 - それは確かにインターネット上に出てくるでしょう ！ Archには巨大なユーザーベースがあり、人々はバグレポートを書いてフォーラムで質問をするでしょう。
数日間、問題について言及されていない場合、悪いニュースがあります。 100％に近い確率で、システムを自分で破りました。 アクションを記憶し、ログを分析し、何が起こったかを理解します。 一般的に、このようなケース（一部の更新が故障につながるが、これはバグではない場合）は、「更新時には手動による介入が必要です」という見出しのニュースで常に取り上げられる状況によく見られます。 これは、次の更新がシステムに重大な変更をもたらし、更新自体がこれを正しく実行できない場合に発生します。