
すでに起動の問題を抱えている人々からいくつかの質問が寄せられていることは承知していますが、私のケースはかなり特殊だと思うので、いくつかの新しい問題に対処できることを期待して、さらに別の質問を投稿します。
私は、インストールされなくなったカーネルの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
再作成することはできないことがわかりました。これは予想していたよりも少し面倒なことでした。config
System.map
depmod
これらすべてのファイルを再生成または取得する最も簡単な方法は次のとおりです。
- のすべての内容を削除します
/boot
。 linux-image
、linux-header
およびlinux-modules
使用する予定のないファイルをアンインストールします。- の残りのディレクトリをすべて削除し
/usr/lib/modules
、 - 再インストールし
linux-image
、使用しようとしていlinux-modules
たlinux-headers
ファイル(最新の汎用2バージョン)
注意: これら3種類のファイルを再インストールするすべて同時に/boot/System.map
とファイルを元に戻すことができたの/boot/config
は、ファイルを再インストールしただけではダメだったからです。モジュールまたはパッケージlinux-image
に含まれている可能性もありますが、私の場合はこれでうまくいきました。modules
headers
- その後、
update-grub
それらのファイルを再インストールし、/boot
正しく入力されたことを確認してから実行しました。 - および も実行した
bootctl install
ので、フォールバックとしてインストールした/etc/kernel/postinst.d/zz-udpate-systemd-boot
ことになります。systemd-boot
再起動後のある時点で、ではなくsystem.target
に再設定する必要がありました。これはおそらく、数日前にプログラムを実行するためにグラフィカル ライブ CD ですべてのマウントを ed したためで、これにはグラフィックスが必要です (動作させるには と が必要だったと思います)。multi-user.target
graphical.target
chroot
boot-repair
/dev/pts
/tmp
/run
display :0.0
systemctl set-default multi-user.target
はい、以上です。誰かの役に立てれば幸いです。