web-dev-qa-db-ja.com

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

しばらくの間、ブートプロセスに時間がかかりすぎています（約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

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

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

bootkernel
37
alci

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

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

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

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

RESUME=none

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

走る

Sudo update-initramfs -u

変更を適用します。

システムが正常に起動します。

52
alci

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

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

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

/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'
1
Nameless Voice

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

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

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

  2. そこで、Sudo gedit /etc/fstabと入力して/ etc/fstabファイルを編集しました

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

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

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

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

1
deni

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

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

0
Benny