誤ったレジュームデバイスによる、遅いブート、長いカーネルロード時間

しばらくの間、ブートプロセスに時間がかかりすぎています（約1分）。

systemd-analyse time 

カーネルが35.765を使用していることを示しています

を見るdmesgと、問題はファイルシステムのマウントにあるようです。

...
[    2.186084]  sdb: sdb1 sdb9
[    2.186919] sd 2:0:0:0: [sdb] supports TCG Opal
[    2.186922] sd 2:0:0:0: [sdb] Attached SCSI disk
[    2.499795] ata5: SATA link down (SStatus 0 SControl 300)
[    2.844320] clocksource: Switched to clocksource tsc
[   35.670493] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[   35.782128] ip_tables: (C) 2000-2006 Netfilter Core Team
[   35.803610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
...

私/etc/fstabはこのように見えます：

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=3996-2381  /boot/efi       vfat    umask=0077      0       1
#/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

これをトラブルシューティングするにはどうすればよいですか？

編集：（grubのquietオプションを削除した後）ブートメッセージをよく見て、疑わしい行を見つけました：

gave up waiting for suspend/resume device

私のスワップは暗号化されていると思うし、UUIDは/etc/initramfs/conf.d/resumeどのデバイスにも対応していないと思う。

再開/一時停止を無効にする必要がありますか？そしてそれを行う方法？

わかりました、Sudhanshuのコメントのおかげで解決策を見つけました。

問題は、スワップが暗号化されていたためです。そのためlocal-premount、initramfs内のスクリプトは、タイムアウトになるまで使用できないスワップデバイスを待機していました。関連するメッセージはでしたgave up waiting for suspend/resume device。

これを無効にするには（暗号化されたスワップではスワップからの再開が不可能であり、とにかく休止状態を使用しません）、このファイルを変更しました/etc/initramfs-tools/conf.d/resume。

このファイルでは、次の行

RESUME=none

（ここにあったUUIDの代わりに）再開デバイスの待機を無効にします。

走る

sudo update-initramfs -u

変更を適用します。

システムが正常に起動するようになりました。

また、Linux Mint（Ubuntuベース）でこれを見て、何が間違っているのかを解決するのに少し時間を費やしました。

これは、システムがLVMにインストールされており、LVMボリュームをスワップディスクとして使用している場合に発生します。

レジュームファイルに、デバイスパスの代わりにUUID（LVMには無効）が誤って含まれる、長期にわたる繰り返し発生するバグがあります。https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230を参照してください

/etc/initramfs-tools/conf.d/resumeファイルを編集し、UUIDをスワップドライブのデバイスパスに置き換えることで修正できます。次のコマンドスニペットは、blkidによって最初に検出および報告されたスワップドライブを使用してこれを行います。

sudo bash -c 'mv /etc/initramfs-tools/conf.d/resume /tmp/resume.bak; echo RESUME=$(blkid | \grep -I swap | head -n 1 | cut -d : -f 1) > /etc/initramfs-tools/conf.d/resume'

上記のソリューションや他のソリューションでは解決しませんでしたが、ブート時間を2分10秒から40秒に短縮するソリューションを見つけました。

以前はスワップパーティションを作成および削除していましたが、これらのログはどういうわけかetc / fstabファイルに残っていました。そのため、私のシステムは、以前に作成された、もはや存在しないスワップパーティションをマウントしようとしました。それで、私が一歩一歩やったことを説明させてください。

1. このコマンドを実行sudo blkid | grep swapして、スワップパーティションを見つけました。2つありましたが、1つは実際には存在しません（私のパーティションを参照していません）。

2. そこで、次のように入力して/ etc / fstabファイルを編集しました。 sudo gedit /etc/fstab

3. それから、私は削除したが、どういうわけかこのファイルに存在することを再開した非常に多くのスワップファイルがあることに気づきました。そこで、ステップ1を参照し、存在しないパーティションを削除しました。

/ etc / fstabファイルのスクリーンショットの前後に2つ表示されます。この後、すべてが正常に機能します。

これは未編集の/ etc / fstabファイルです未編集の/ etc / fstab

そして、ここに存在しないスワップパーティションを一掃した後/ etc / fstabをきれいにします

2つの異なるLinuxディストリビューションをインストールした後、この問題が発生しました。どういうわけか、あるディストリビューションでは、スワップパーティションに別のUUIDが割り当てられ、その後予期されていました。私の解決策は次のとおりです。まず、実行sudo blkidしてスワップパーティションの正しいUUIDを取得します。スワップのUUIDをコピーします。貼り付けて/etc/initramfs-tools/conf.d/resumeくださいRESUME=_the_correct_UUID_。次に、sudo update-initramfs -uこの変更を適用するために実行します。

次に、/ etc / fstabを確認し、必要に応じてスワップパーティションのUUIDも変更します。（そうしなければならなかった）