長いブート修復プロセスの後、systemd 緊急プロンプトが表示されます。問題: fstab ファイルに FS がありません

長いブート修復プロセスの後、systemd 緊急プロンプトが表示されます。問題: fstab ファイルに FS がありません

すでに起動の問題を抱えている人々からいくつかの質問が寄せられていることは承知していますが、私のケースはかなり特殊だと思うので、いくつかの新しい問題に対処できることを期待して、さらに別の質問を投稿します。

私は、インストールされなくなったカーネルのinitramfs(initrd.imgおよびvmlinuz内のファイル)を持つ VM のブート プロセスを修復し、引き続きそれらのカーネルからブートしようとしていました。/boot

ほぼ完了に近づいていますが、systemd'sに再起動し続けますemergency mode(次のように表示されます: )

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

ライブ CD から起動し、3 つの関連パーティションを にマウントし/mnt、 に chroot しました/mnt

mount /dev/sda3 /mnt
mount /dev/sda2 /mnt/boot
mount /dev/sda1 /mnt/boot/efi
for i in proc dev dev/pts sys tmp run; do mount --bind /$i /mnt/$i; done
chroot /mnt

修復して再起動しました。

現在、 はfstabパーティションをマウントしていません。 正しく設定されていると思っていました。UUID は から直接コピーされますblkid | grep /dev/sda。何かが欠けているとは思いませんでした。

緊急モードプロンプトが表示される直前に表示されるエラーは次のとおりです。

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
[DEPEND] Dependency failed for Local File Systems
[DEPEND] Dependency failed for Unattended Upgrades Shutdown
[DEPEND] Dependency failed for /boot/efi

それで、もちろん を確認しましたが、を手動でマウントしないsystemctl status boot.mount限りフォルダーが空であるにもかかわらず、 はアクティブ (緑色) で、ロード済みと表示されます。/boot/dev/sda2

とても奇妙に思えます。明らかにそうでないのに、なぜパーティションboot.mountをロード中だと言えるのでしょうか?/boot

答え1

それで、私は実際に質問を書いている間に問題を理解しました。最初に書いたことからわかるように、それは非常に長いプロセスでした(助けを求めたいと思うようになるまで、約 2 日間取り組んでいました)。

Q の最後を見ると、dmesg起動プロセス中に次のメッセージを受け取っていました。

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.

それで、もちろん、systemctl status boot.mount何と書いてあるか確認しようとしましたが、boot.mountアクティブ (緑) で、ロードされていて正常に機能していると表示されましたが、/boot手動でマウントしない限り空でした/dev/sda2(これはまさに私が期待していたことの反対です)。

そこで、サービスに何か問題があるのではないかと考え始めましたboot.mount言った正常に動作していました:

systemctl disable --now boot.mount

再度有効にしようとしましたが、エラーが発生しました:

systemctl enable --now boot.mount
Failed to enable unit: Unit /run/systemd/generator/boot.mount is transient or generated

なるほど、それは理にかなっています。これはブート プロセスによってトリガーされ、ユーザー コマンドによって呼び出すことはできません。そこで、次のコマンドを使用してすべてのデバイスを再マウントしようとしました。

mount -a

そして、ファイルにエラーがあることがわかりました/etc/fstab:

error: rw,relatime is not a valid file system

(またはそれに類する内容)。

mount -aここで重要なのは、ファイルシステムを手動でマウントしようとしていなかったら、そのフィードバックを受け取ることはなかっただろうということです。不適切な構文が含まれている場合に表示されるエラー メッセージは、fstab非常に役立ちます。次のものよりはるかに役立ちます。

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.

...そして、マウントされていないboot.mountときに「動作する」systemdユニットを確認します(/bootした最終的には正しい場所に連れて行ってくれます。

そこで、 を編集しfstab、マウントに失敗したパーティションのファイルシステム情報を入力して/bootから、 を再実行しmount -a(これは基本的に と同じことを行いますboot.mount)、肯定的な応答を得ました。

これで、再起動後に 2 つのパーティションが適切にマウントされ、ホースラディッシュとマーマレードの世界ではすべてが順調になりました。

これで問題が解決しない場合は、私が助けを求めていた上記のポイントに到達する前に実行したプロセスに関する追加のメモを以下に示します (問題に到達したら、読むのをやめてもかまいません)。

2 日前に発生した最初の問題は、システムがシステムに存在しないカーネルから起動しようとしていたことです。そのため、ライブ CD で起動した後、フォルダーの内容 (すべてのファイルが保存されている/boot場所) を削除しました。initrd

initramfsインストールした現在のカーネルを使用してを再作成するだけだと考えましたが、またはファイルを単独でupdate-initramfs -c -k all再作成することはできないことがわかりました。これは予想していたよりも少し面倒なことでした。configSystem.mapdepmod

これらすべてのファイルを再生成または取得する最も簡単な方法は次のとおりです。

  1. のすべての内容を削除します/boot
  2. linux-imagelinux-headerおよびlinux-modules使用する予定のないファイルをアンインストールします。
  3. の残りのディレクトリをすべて削除し/usr/lib/modules
  4. 再インストールしlinux-image、使用しようとしていlinux-moduleslinux-headersファイル(最新の汎用2バージョン)

注意: これら3種類のファイルを再インストールするすべて同時に/boot/System.mapとファイルを元に戻すことができたの/boot/configは、ファイルを再インストールしただけではダメだったからです。モジュールまたはパッケージlinux-imageに含まれている可能性もありますが、私の場合はこれでうまくいきました。modulesheaders

  1. その後、update-grubそれらのファイルを再インストールし、/boot正しく入力されたことを確認してから実行しました。
  2. および も実行したbootctl installので、フォールバックとしてインストールした/etc/kernel/postinst.d/zz-udpate-systemd-bootことになります。systemd-boot

再起動後のある時点で、ではなくsystem.targetに再設定する必要がありました。これはおそらく、数日前にプログラムを実行するためにグラフィカル ライブ CD ですべてのマウントを ed したためで、これにはグラフィックスが必要です (動作させるには と が必要だったと思います)。multi-user.targetgraphical.targetchrootboot-repair/dev/pts /tmp/rundisplay :0.0

systemctl set-default multi-user.target

はい、以上です。誰かの役に立てれば幸いです。

関連情報