結果

Question 1

デフォルトでは、仮想ボックス内でスワップを無効にして削除した後、同じ問題が発生し、UUIDが混乱しました。これにより、タイムアウトの問題と依存関係のエラーが発生し、起動するたびにファイルシステムを強制的に確認できます。したがって、UUIDを更新する必要があります。

スワップパーティションが削除された場合（たとえば、意図的にHDからSSDに移行する場合）、ファイルは完全に/etc/initramfs-tools/conf.d/resume空白または読み取られなければなりませんRESUME=。 UUID番号を削除してください。RESUME=NONE無効です。スワップを使用するかどうかにかかわらず、回避策は次のとおりです。

トラブルシューティングのために（オプション）：

sudo cat /var/log/boot.log

正しいパーティション UUIDS をリストします。

sudo blkid -c /dev/null -o list

次の3つのファイルがblkidにリストされている正しいUUID設定を持っていることを確認し、正しいUUIDで上書きします。

/etc/fstab                                      [for me swap was incorrect]
/etc/default/grub                               [for me RESUME=UUID was incorrect]
/boot/grub/grub.cfg                             [for me RESUME=UUID was incorrect]

次に、初期のRamファイルシステムを更新します。

update-initramfs -u

上記の3つのファイルを編集すると、cryptsetup: error: couldn't resolve deviceupdate-initramfsを実行したときにエラーが永久に解決されました。

これにより、UUIDを追加する必要はありませんが、/etc/initramfs-tools/conf.d/resumeまだ問題がある場合は、次のUUIDを追加するか、RESUME=UUID=c0198c37-f28b-41f5-bb0f-37d575e86896スワップRESUME=ファイルを使用しない場合は設定することをお勧めします。

次に、次を実行します。

update-initramfs -u

また、起動プロセスを高速化する/etc/default/grubに設定されていることを確認してください。GRUB_TIMEOUT=0ここで説明した内容がすべて終了したら、起動時に最後のファイルシステムチェックを一度実行しますが、1分30秒ではなく10秒で起動します。

Answer

デフォルトでは、仮想ボックス内でスワップを無効にして削除した後、同じ問題が発生し、UUIDが混乱しました。これにより、タイムアウトの問題と依存関係のエラーが発生し、起動するたびにファイルシステムを強制的に確認できます。したがって、UUIDを更新する必要があります。

スワップパーティションが削除された場合（たとえば、意図的にHDからSSDに移行する場合）、ファイルは完全に/etc/initramfs-tools/conf.d/resume空白または読み取られなければなりませんRESUME=。 UUID番号を削除してください。RESUME=NONE無効です。スワップを使用するかどうかにかかわらず、回避策は次のとおりです。

トラブルシューティングのために（オプション）：

sudo cat /var/log/boot.log

正しいパーティション UUIDS をリストします。

sudo blkid -c /dev/null -o list

次の3つのファイルがblkidにリストされている正しいUUID設定を持っていることを確認し、正しいUUIDで上書きします。

/etc/fstab                                      [for me swap was incorrect]
/etc/default/grub                               [for me RESUME=UUID was incorrect]
/boot/grub/grub.cfg                             [for me RESUME=UUID was incorrect]

次に、初期のRamファイルシステムを更新します。

update-initramfs -u

上記の3つのファイルを編集すると、cryptsetup: error: couldn't resolve deviceupdate-initramfsを実行したときにエラーが永久に解決されました。

これにより、UUIDを追加する必要はありませんが、/etc/initramfs-tools/conf.d/resumeまだ問題がある場合は、次のUUIDを追加するか、RESUME=UUID=c0198c37-f28b-41f5-bb0f-37d575e86896スワップRESUME=ファイルを使用しない場合は設定することをお勧めします。

次に、次を実行します。

update-initramfs -u

また、起動プロセスを高速化する/etc/default/grubに設定されていることを確認してください。GRUB_TIMEOUT=0ここで説明した内容がすべて終了したら、起動時に最後のファイルシステムチェックを一度実行しますが、1分30秒ではなく10秒で起動します。

Question 2

mercurial@providence:~$ systemd-analyze
Startup finished in 7.913s (kernel) + 20.621s (userspace) = 28.534s 
graphical.target reached after 20.605s in userspace

いくつかの問題を修正した後に得られた結果です。ご覧のとおり、起動時間が1分5秒から28秒に徐々に短縮されます。

1. sudo update-initramfs -u -k all: カーネル時間

これは、見つからないデバイスから回復しようとしているという大きな音です。つまり、私のシステムに回復ブロックがあります。grub.cfg

cryptsetup: ERROR: Couldn't resolve device 
    UUID=fee92c6d-7b60-4014-a66b-c48cd9094162

それは間違いだけです。

cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
    nor crypto modules. If that's on purpose, you may want to uninstall the 
    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
    integration and avoid this warning.

このクールなコード行では、システムが回復できるように新しいスワップパーティションを宣言する必要があります。

I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=c0198c37-f28b-41f5-bb0f-37d575e86896)
I: Set the RESUME variable to override this.

だから私はそうだった、

mercurial@providence:~$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=c0198c37-f28b-41f5-bb0f-37d575e86896

2. systemd-analyze 問題: ユーザー空間時間

私のネットワーク管理者がオンラインになるまでに少し時間がかかるので、私がしなければならないことはそれをブロックするだけです。

sudo systemctl mask NetworkManager-wait-online.service

結果

今私の起動時間は28秒に短縮されました。以下は私の責任と重要なチェーンです。

mercurial@providence:~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @20.605s
└─udisks2.service @9.969s +10.636s
  └─basic.target @9.515s
    └─sockets.target @9.515s
      └─dbus.socket @9.515s
        └─sysinit.target @9.333s
          └─swap.target @9.333s
            └─dev-disk-by\x2duuid-c0198c37\x2df28b\x2d41f5\x2dbb0f\x2d37d575e86896.swap @8.843s +490ms
              └─dev-disk-by\x2duuid-c0198c37\x2df28b\x2d41f5\x2dbb0f\x2d37d575e86896.device @8.841s
mercurial@providence:~$ systemd-analyze blame
         10.636s udisks2.service
          6.628s dev-sda6.device
          5.486s ModemManager.service
          4.935s accounts-daemon.service
          4.346s exim4.service
          4.156s NetworkManager.service
          3.211s bluetooth.service
          3.203s atd.service
          3.174s apt-daily.service
          3.132s pppd-dns.service
          3.128s alsa-restore.service
          2.765s systemd-logind.service
          2.762s avahi-daemon.service
          2.751s rsyslog.service
          2.750s wpa_supplicant.service
          2.594s networking.service
          2.168s lightdm.service
          2.148s plymouth-quit-wait.service
          2.024s upower.service
          1.975s systemd-udevd.service
          1.955s apparmor.service
          1.718s polkit.service
          1.412s systemd-tmpfiles-setup.service
          1.161s colord.service
          1.000s systemd-rfkill.service

私は改善の余地があると思うので、いくつかのコアシステム管理者が少し情報を提供するのを待ちます。ありがとうございます。

Answer

mercurial@providence:~$ systemd-analyze
Startup finished in 7.913s (kernel) + 20.621s (userspace) = 28.534s 
graphical.target reached after 20.605s in userspace