web-dev-qa-db-ja.com

18.04の新規インストール時のSSDおよびLVMを使用した低速ブート

最初のインストールにはLVMが含まれておらず、BIOSの起動後約15秒かかりました。 2回目のインストールにはLVMが含まれており、BIOSが起動してから約45秒かかりました。多くのグーグルの後、一般的なコンセンサスは、これがインストール中に「特定の」SSDを使用してLVMを選択すると、システムがスワップファイルを探して見つからない間に長いブートを引き起こすバグであると思われます。タイムアウトは30秒です。誰かがこれの回避策を見つけましたか？

bootlvm
1
wirebender

免責事項：執筆時点では、他の回答をコメントするのに十分な評判がありませんので、新しい回答を入力する必要があります（主に自分用の参照として）

Ubuntuの新規インストールでも同様の問題があり、ベアメタルインストールは15秒以内に起動し、LVMインストールの起動には50秒かかりました（黒い画面で約30秒の休止）。

Sudo systemd-analyze blameへの最初の呼び出しは、別の問題があることを指摘しました。

$ Sudo systemd-analyze blame
     40.699s snapd.seeded.service
     ...

この他のQ＆Aのおかげで解決できたこと： SSDのクリーンインストール（18.04）での通常のdist-upgrade後のUbuntuロード/スプラッシュ画面での長いブート遅延rng-toolsをインストールして定義するHRNGDEVICE=/dev/urandomのランダムデータの入力ソースとして/etc/default/rng-tools。

これにより、スナップされたエントロピーの問題が解決されました。

$ Sudo journalctl -u snapd.seeded.service --since today
  -- Logs begin at Tue 2018-08-21 18:22:53 CEST, end at Tue 2018-08-21 19:40:09 CE
  # Before: ~40s
  Aug 21 18:22:54 zen systemd[1]: Starting Wait until snapd is fully seeded...
  Aug 21 18:23:36 zen systemd[1]: Started Wait until snapd is fully seeded.
  Aug 21 18:50:18 zen systemd[1]: Stopped Wait until snapd is fully seeded.   
  -- Reboot --
  # After: <1s
  Aug 21 18:51:19 zen systemd[1]: Starting Wait until snapd is fully seeded...
  Aug 21 18:51:19 zen systemd[1]: Started Wait until snapd is fully seeded.
  ....

しかし、カーネルの起動にはまだ〜35秒かかったため、 nils-fenner の "Idiot Proof"の方法を試しました。最初は動作しませんでしたが、 ArniそしてDavid ようやく開始時間を10秒まで短縮することができました。

（自分の）参考のために、問題を解決するための安全なパスのバージョンを以下に示します。

 $ cd <whatever back up folder on your machine>
 # backup initial config
 $ cp /etc/initramfs-tools/conf.d/resume .

 # Retrieve the correct path to the swap partition (for manually configured LVMs)
 $ Sudo fdisk -l

   ... some partitions

   Disk /dev/mapper/vg_zen-uswap: 4 GiB, 4294967296 bytes, 8388608 sectors
   Units: sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes

   ... some more partitions

 # Update the "resume" file with the new path
 # Caution "vg_zen-uswap" is for *my* machine only :)
 $ echo "RESUME=/dev/mapper/vg_zen-uswap" | Sudo tee /etc/initramfs-tools/conf.d/resume
   RESUME=/dev/mapper/vg_zen-uswap   

 # Recreate initrd
 $ Sudo update-initramfs -u 
   update-initramfs: Generating /boot/initrd.img-4.15.0-32-generic

 # reboot

それは私のためのトリックを行いました。 HTH。

1
Bruno Sinou

次の2つの方法のいずれか、または両方を試してください。

最初の方法

ターミナルを開いて次のように入力して、カーネルの起動時間がどれくらいかを確認します。

systemd-analyze

wait-for-root in /usr/share/initramfs-tools/scripts/localは、30秒が経過するとタイムアウトします（スランバー値）。 dev_id変数には、/etc/initramfs-tools/conf.d/resumeで定義されているRESUMEの値が割り当てられます。 RESUMEに割り当てられるこのUUIDは、LVMスワップパーティションのUUIDです。 LVMスワップパーティションのデバイスファイルパスをRESUMEに割り当て、wait_for_udevの代わりにwait-for-rootを使用します。

これを行うには、次のように入力します（ターミナルで）：

Sudo sed -e 's/^RESUME=/#RESUME=/g' \
   -i /etc/initramfs-tools/conf.d/resume

終了したら、次を入力します。

echo "RESUME=/dev/mapper/ubuntu--YOUR FLAVOR OF UBUNTU HERE--vg-swap_1" | \
Sudo tee -a /etc/initramfs-tools/conf.d/resume

Initrdを再作成し、システムを再起動します。

Sudo update-initramfs -u

終了したら、次を入力します。

Sudo reboot

カーネルの起動時間を短縮する必要があります。次のように入力して確認します。

systemd-analyze

この後、休止状態を使用することもできます。

（ ソース ）

第二の方法

/etc/initramfs-tools/conf.d/に移動します

「再開」を右クリックして、管理者として編集を選択します。行を変更する

RESUME=UUID=<WHATEVER YOUT NUMBER IS>

（例：RESUME=UUID=67b3fe6f-1ec4-413f-8c5a-1136bc7f3270）：

RESUME=none

ターミナルを開いて、次を入力します。

Sudo update-initramfs -u

終了したら、次を入力します。

Sudo reboot

カーネルの起動時間を短縮する必要があります。次のように入力して確認します。

systemd-analyze

（ ソース ）

1
Arni

上記の2番目の方法は一般に機能しないようです。また、スワップUUIDを誤ってオーバーライドしないようにするために、もう少し「馬鹿な」方法をお勧めします。

Sudo -i    #become root
cd /etc/initramfs-tools/config.d
mv resume resume.uuid
echo "RESUME=/dev/mapper/YOUR UBUNTU FLAVOUR HERE--vg-swap_1" > resume
#Example: echo "RESUME=/dev/mapper/lubuntu--vg-swap_1" > resume

update-initramfs -uk all
sync && reboot

これで、2つのファイルの名前を変更するだけで簡単に切り替えることができます。

0
Nils Fenner