web-dev-qa-db-ja.com

クリーンなSSDインストールでの通常のdist-upgradeに続くUbuntuのロード/スプラッシュ画面での長い起動遅延（18.04）

私は公式リリースの日にクリーンなSSDをインストールしてから18.04を問題なく実行しています。
ログイン時の電源投入は数秒（最大10）

次に、私は定期的なアップグレードを行いました今朝：

$ Sudo apt update && Sudo apt dist-upgrade

インストール/アップグレードされたパッケージ：

Install: linux-headers-4.15.0-24:AMD64 (4.15.0-24.26, automatic), linux-headers-4.15.0-24-generic:AMD64 (4.15.0-24.26, automatic), linux-modules-extra-4.15.0-24-generic:AMD64 (4.15.0-24.26, automatic), linux-modules-4.15.0-24-generic:AMD64 (4.15.0-24.26, automatic), linux-image-4.15.0-24-generic:AMD64 (4.15.0-24.26, automatic)
Upgrade: gnome-control-center-data:AMD64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-headers-generic:AMD64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center:AMD64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-image-generic:AMD64 (4.15.0.23.25, 4.15.0.24.26), linux-signed-generic:AMD64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center-faces:AMD64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-generic:AMD64 (4.15.0.23.25, 4.15.0.24.26)

アップグレードが完了したらリブートし、buntuのロード/スプラッシュ画面（ログイン前）で2〜3分の遅延に気づいた（進行状況/アクティビティが点で示されていない）。

電源をオフにして再度起動しようとしましたが、この遅延が常に発生しています。また、クローズダウンも非常に遅くなります。

更新＃1（2018-07-03）：
systemdの分析：

$ Sudo systemd-analyze blame
3min 53.073s plymouth-quit-wait.service
    2min 20.699s snapd.seeded.service
         49.949s snapd.service
          6.186s NetworkManager-wait-online.service
          1.148s dev-sda2.device
          1.098s plymouth-start.service

plymouth-quit-wait.service（これはUbuntuのロード/スプラッシュ画面に関連していると思われます）とsnapd.seeded.serviceが、開始するのに最も長い間実行されているサービスであることを示しています。そこで、dist-upgradeの前と後の時間を比較しました。

$ journalctl -u plymouth-quit-wait.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:38:05 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:15:46 user-laptop systemd[1]: Started Hold until boot process finishes up.
-- Reboot --
Jul 03 04:21:17 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:24:52 user-laptop systemd[1]: Started Hold until boot process finishes up.

前アップグレードplymouth-quit-wait.serviceがかかりました秒。 後アップグレードにかかった時間分 35秒

$ journalctl -u snapd.seeded.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:42:14 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:15:43 user-laptop systemd[1]: Started Wait until snapd is fully seeded.
-- Reboot --
Jul 03 04:22:47 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:24:49 user-laptop systemd[1]: Started Wait until snapd is fully seeded.

前アップグレードsnapd.seeded.serviceはかかりました秒。 後かかったアップグレード2分 2秒。

更新＃2（2018-07-06）：
今朝のブートでは、遅延の戻り値が確認されました。
だから私たちはまだkernel/plymouth/snapdの更新を待っているであると思います。

更新＃（2018-07-12）：
問題解決されたようです、しかし、スナップまたはプリマスへのアップデートは見られず、4.15.0-24カーネルを実行しています。だから、どのパッケージのアップデートが問題を解決したのか、それともどういうわけかそれ自体を解決したのかどうかはわかりません。ランチパッドでバグの更新を読むと、どのパッケージに対して何が実行されたか（または実行されているか）がわかりません。 それが非常に有用であることを明確にすることができれば

boot18.04snapplymouth
23
Broadsworde

これはカーネル関連の回帰であり、ランチパッドのバグは次のとおりです。 https://bugs.launchpad.net/ubuntu/+bug/1779827

回避策として、キーを押すか、起動時にマウスを移動します。

簡単に言うと、/ dev/urandomまたはgetrandom（）を使用するサービスは、十分なエントロピーが利用可能になるまでブロックします。以前は、/ dev/urandomに必要なエントロピーははるかに少なかった。

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 の最新のステータスは次のとおりです。

メタパッケージはロールバックされており、修正の適用とアップロードが進行中です。

Snapdチームもこれを調査し、bsonアップストリームと協力して、起動に/ dev/unrandomが不要であることを確認しました（ https://github.com/snapcore/snapd/pull/5464 ）

そのため、この問題は、カーネルまたはsnapdアップデートを介してすぐに修正する必要があります。

13
Michael Vogt

システム内でマウスを移動したり、エントロピーを増やしたりできます。

Sudo apt install haveged

避難したウェブサイト

デフォルトのカーネルとukuuで動作します。これにより、システムはカーネル4.17.4で正しく起動できます。

10
Radoslaw Brzozowski

私が管理する2つのデスクトップでこのマニフェストを見ました。次のコマンドを実行してrng-toolsをインストールすると、問題が解決します。

Sudo apt install rng-tools

Arch wikiから rng-toolsは、カーネルでの乱数生成に関連するユーティリティのセットです。これは主に、カーネルのエントロピーの量を増やして/ dev/randomを高速化するのに役立ちます。

5
psiphi75

4.15.0-24-generic #26-Ubuntu SMPでも同じ問題があります

user@nb:~$ systemd-analyze blame |head
         4min 2s plymouth-quit-wait.service
          1.440s systemd-udev-settle.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

一時的な回避策の場合、起動中にマウス/タッチパッドを移動するだけです、「通常の」起動時間になります。私の場合：

user@nb:~$ systemd-analyze blame |head
          1.440s systemd-udev-settle.service
           882ms plymouth-quit-wait.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

ソースの修正： https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

5
Francio