3年前、Fedoraでのメジャーバージョンのアップグレード後に失敗したブートから回復する方法を説明する記事を書きました。その時、私はFedora 25で作業していましたが、突然、デスクトップにアクセスできなくなりました。この問題はバグのあるinitramfsであることが判明しました。これは、Ubuntuで、2009年に一度だけ発生した問題です。それ以来、静かになっています。
さて、時間の輪は最初に私たちを捨てました。同じ問題が再び発生しました。私は（ある程度）最近Fedora29のインスタンスをFedora30にアップグレードしましたが、見よ、私は同じ問題に直面していることに気づきました。ほとんど。画面が真っ暗になり、「コンソールへのアクセスを開くことができません。rootアカウントがロックされています」というメッセージが表示されました。この時点で、何かをしようとしても結果は得られませんでした。再起動するしかありませんでした。私は別のカーネルを試しましたが、これは役に立ちました-デスクトップにアクセスしました。問題は似ているように見えますが、私はそれを修正するために少し異なる方法をとらなければなりませんでした。
問題の症状の詳細
アクセス可能な診断ツールや、問題をトラブルシューティングできる使用可能な環境がないことに、私はかなり困惑していました。再起動する必要があるということは、おそらく貴重な情報を失うことを意味します。少なくとも、他のカーネルで起動できたので、何か作業が必要でした。
最新の1カーネルでは、最初に2年前の自分のアドバイスに従おうとしましたが、systemctlstatusboot-efi.mountコマンドは何の役にも立ちませんでした。私は常に、新しくて現代的なブートフレームワークがいかに壊れやすく、複雑で、実際には人間に優しいものではないかに困惑しています。前号では、複雑さに関する進捗状況の記事を書くように促されましたが、その結論は何年も経った今でも維持されています。
最も単純な障害は、/ var/logの下にある情報の可用性です。古き良き初期の時代には、通常、syslog / messages、ブート、古いブート、カーネルログがあります。これらは、猫を使って簡単かつ即座に検査できるテキストファイルでした。
Fedoraでは、これらのファイルのすべてではなく、いくつかを取得します。たとえば、boot.logはありますが、次のようになります。
sudo less boot.log
"boot.log"はバイナリファイルの場合があります。とにかくそれを見ますか？
おかしなことに、それはテキストファイル（いくつかの奇妙な文字を含む）であり、実際に猫と一緒に表示することができます。しかし、このファイルでは、問題を特定するのに役立つ有用な情報は得られませんでした。
次に、journalctlのさまざまなオプションを読むのにもう少し時間を費やしました。これにより、以前のブートログを表示するオプションが提供されます。これを行うには、負の整数値を指定して古いログを表示します。これはあまり直感的ではありませんが、原則としてバイナリログ形式のアイデアに憤慨していますが、少なくとも必要なものは得られました。最近、ラップトップの問題をデバッグしたときに、これを確認しました。同様のテーマ。
journalctl --boot =-1
ここで、私はエラーを探して、行を調べました。 systemctlthingieは以前は役に立ちませんでしたが、このコマンドを使用すると、最終的に重大な起動の問題に遭遇しました：
7月11日13:55:07テスターsystemd[1]：マウント/ boot / efi ...
7月11日13:55:07テスターマウント[899]：マウント：/ boot / efi：不明なファイルシステムタイプ'vfat '。
7月11日13:55:07テスターsystemd[1]：boot-efi.mount：マウントプロセスが終了しました、code =exited、status =32 / n / a
7月11日13:55:07テスターsystemd [1]：boot-efi.mount：結果'exit-code'で失敗しました。
Jul 11 13:55:07 tester systemd [1]：/ boot/efiのマウントに失敗しました。
Jul 11 13:55:07 tester systemd [1]：ローカルファイルシステムの依存関係に失敗しました。
Jul 1113:55:07テスターsystemd[1]：local-fs.target：ジョブlocal-fs.target/startが結果'dependency'で失敗しました。
7月11日13:55:07テスターsystemd[1]：local-fs.target：OnFailure=依存関係のトリガー。
3年前に起こったことと非常によく似ています。繰り返しになりますが、私たちはひどく組み立てられたinitramfsを持っているようですが、これは私の好みにはあまりにも頻繁に起こっているようです。さらに、バージョンのアップグレードと相関関係があります。 FAT32モジュールについて何がそんなにトリッキーなのか疑問に思いますが、それは他の誰かへの質問です。 initramfsファイルに関する限り、/bootの下に次のものがあります。
ls -ltr initramfs *
-rw-------。 1ルートルート734439632018年5月19日initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw-------。 1ルートルート22953495Apr2 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------。 1ルートルート229616875月20日13:11initramfs-5.0.16-200.fc29.x86_64.img
-rw-------。 1ルートルート230152085月20日21:17initramfs-5.0.16-300.fc30.x86_64.img
最後の1つは犯人でしたが、前の1つ（上記）は正常に機能しました。更新中に何が起こっても、ファイルシステムの正しいマウントを可能にするvfatモジュールなしで、2番目のinitramfsが破損しました。好奇心から、画像を抽出して違いを確認することにしました。これは私の疑いを裏付けるものです。繰り返しになりますが、これは最も簡単な演習ではありませんでした。これまでのようにzcatとcpioを使用してinitarmfsファイルを抽出することはできないため、より複雑な組み合わせが必要です。
/ usr / lib / dracut / skipcpio initramfs-"version" .img | zcat | cpio -id
解決策
さて、ここにはいくつかのオプションがあります。 1つは、同じボックスにFedoraの2番目のコピーがあり、それが機能している場合、そのinitramfsファイルをコピーして、当時のUbuntuで行ったように使用できます。これは簡単なオプションではありませんが、持っていればラッキーです！
そうでない場合は、私のシナリオで行ったように、古いカーネルが役立つはずです。次に、システム更新を実行するか、initramfsファイルを手動で再作成できます。これを行う方法の詳細については、私のUbuntuスローブートの記事を読むことができます。他のカーネルを起動できず、ホスト上に他のLinuxインスタンスがない場合、最後のオプションは、ライブセッションを使用して、そこでリカバリを実行するか、再インストールすることです。
結論
私はこの状況に驚き、ややがっかりしました-すべてです。エラー自体、ライブでデバッグできないこと、Fedoraのアップグレード後にこれが起こったという事実（再び）、通常のシステムアクティビティの後に起動できないディストリビューションになってしまったという事実、systemdの全体的な複雑さ。これらすべてが私に不安感を残します。
2020年のテクノロジーの世界は、10年前ほど抽象的で、堅牢で、回復力がありません。それどころか、エラーは発生し続けており、エラーが発生すると、周囲の生態系の使用と作業が以前よりもはるかに困難になります。これにより、トラブルシューティングと問題解決がさらに苛立たしくなります。そうです、私はそれを修正しました、そしておそらくそれが重要です、しかしそれからいいえ、それは重要ではありません。シームレスなユーザーエクスペリエンスが最終目標です。悲しいかな、毎日、Linuxデスクトップはこの高貴な使命から徐々に遠ざかり、より大きな計画とはますます無関係になっています。とにかく、技術面では、この記事がお役に立てば幸いです。気をつけて。