결과

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

다음 세 파일이 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

위의 세 파일을 편집하면 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

다음 세 파일이 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

위의 세 파일을 편집하면 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