☰

systemdが「fstab」に存在しないディスクを待つのはなぜですか？

tag-icon • tag-icon boot systemd fstab uuid ecryptfs
systemdが「fstab」に存在しないディスクを待つのはなぜですか？

私のシステムは起動に95秒かかります。実際に起動するのに5秒、存在しないドライブを待つのに90秒かかります。

(...boot.log...)
A start job is running for dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device (1min 29s / 1min 30s)
Timed out waiting for device dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device.

デバイスがリストになく、fstabハードウェア（USBディスクなど）も見つかりません。どこから来て、どのように無効にしますか？

ホームディレクトリにecryptfsがあり、SSDディスクを保存するために手動でスワップを無効にしました。

答え1

grep -r 6bbb4ed8 /etcデバイスへの参照を見つけた後、initrd（）を再構築するために使用されますmkinitrd。

答え2

これは、暗号化されたファイルシステムの管理/etc/crypttabに対応する（よく知られていない）ファイルです。fstabUbuntuのデフォルトインストールでは、暗号化されたスワップファイルを設定します。

cryptswap1 UUID=6bbb4ed8-53ea-4603-b4f7-1205c7d24e19 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

最初はこのスワップパーティションのみを無効にしましたfstab。いいえ十分。

/etc/crypttabその目的と内部の仕組みについてもっと知っている人は、誰でもこのあいまいな独自の答えを拡張することを歓迎します。

答え3

私の場合、Dell LatitudeノートブックにはブートSSDとデータHDDが付属していました。データHDDに不良セクタが発生したため、最終的にデータをバックアップしてHDDを物理的に削除しました。ブート。

grep -r /etcHaukeの提案により、systemdが探していた/etc/crypttabHDD UUID（per）に対応する項目が見つかりました。/dev/disk/by-uuid

次に、数年前に両方のディスクに1つのLUKSパスワードを入力できるようにこの行を追加したことを覚えておいて、HDD復号化をルートファイルシステムのキーファイルとして指定します（起動時にLUKSパスワードを入力すると、復号化crypttab(5)）マルチディスクシングルLUKSパスワード設定に興味がありますか？）。

この/etc/crypttab行をコメントアウトすると、SSDの高速起動速度が復元されました（ありがとう！）。

関連情報