systemdがファイルシステムをマウントしようとすると、システムがハングします。依存関係のタイムアウトにより失敗します。依存関係は、インストールさdev-disk-by\x2dlabel-cb\x2drootfs.deviceれるデバイスがある場所です/dev/disk/by-label/cb-rootfs。
systemd[1]: dev-disk-by\x2dlabel-cb\x2drootfs.device: Job dev-disk-by\x2dlabel-cb\x2drootfs.device/start timed out.
システムの設置を妨げることはありません。
mount -av
したがって、この場合、systemdはデバイスがすでにそこにあり、マウントする準備ができているため、間違ったことを待っているようです。
状況を複雑にすることは、ルートファイルシステムが同じデバイスを含むオーバーレイファイルであることです。簡単に言えば、initramfsは次のことを行います。
mount /dev/disk/by-label/cb-rootfs /host
mount -o loop /host/rootfs/foo.squashfs /ro
mount -t overlay overlay lowerdir=/ro,upperdir=/host/writable,workdir=/host/workdir /root
/rootしたがって、systemdがマウントを開始できるように、ルートファイルシステムを準備しました/etc/fstab。
その後、/etc/fstabマウントしてみてください。
/dev/disk/by-label/cb-rootfs /host ext4 defaults 0 0
私が言ったように、私はすることができ、mount -avLinuxは `/dev/disk/by-label/cb-rootfs.dll'をマウントするのに全く問題はありません。しかし、systemdは何とか準備されるまで無限に待っているようです。
systemd 何を待っていますか？これを待たないようにするにはどうすればよいですか？
答え1
systemdメーリングリストに関する私の質問への回答として、次の内容を受け取りました。この回答:
マンタミクレナス
デバイスユニットの待機ウデブデバイスを追加するためのueventをブロードキャストします。これは、udevが1.初期カーネルuevent（実際またはsystemd-udev-trigger.serviceによって生成された）を受け取り、2.デバイスのすべての.rules処理を完了したときに発生します（つまり、RUN = allで意味）開始ルールは終了する必要があります。など）。
udevルールにTAG + = "systemd"タグ付きのデバイスのみが.deviceユニットを生成します。通常、99-systemd.rulesはそれをディスクデバイスに追加します。
規則に従ってデバイスがENV {SYSTEMD_READY} = "0"とマークされている場合、.deviceデバイスは他のイベントがそのデバイスを削除するのを待ち続けます。
私の場合、udevが正しくインストールされていないか破損していることがわかり、/ devのデバイスを使用できるにもかかわらず、systemdはまだudevの信号を待っていました。
udevを再インストールすると問題が解決しました。