Ubuntu, медленная для начальной загрузки после изменения размеров разделов

Я удалил свой раздел подкачки и создал новый, который больше. Теперь моя начальная загрузка берет о 30-х больше, чем она привыкла для.

Вот вывод systemd-analyze: Startup finished in 34.275s (kernel) + 8.404s (userspace) = 42.679s graphical.target reached after 8.397s in userspace

Я проверил, чтобы удостовериться что мой /etc/fstab файл имеет корректный UUID для файла подкачки, который он делает.

Вот вывод systemd-analyze blame:

  6.266s NetworkManager-wait-online.service
  2.931s plymouth-quit-wait.service
  2.316s postgresql@10-main.service
  1.112s dev-sda1.device
   772ms dev-loop2.device
   766ms dev-loop3.device
   765ms dev-loop25.device
   764ms dev-loop5.device
   763ms fwupd.service
   761ms dev-loop6.device
   750ms dev-loop4.device
   747ms dev-loop7.device
   728ms dev-loop8.device
   723ms dev-loop26.device
   721ms dev-loop23.device
   717ms dev-loop9.device
   713ms dev-loop10.device
   712ms dev-loop12.device
   704ms dev-loop11.device
   704ms dev-loop13.device
   703ms dev-loop24.device
   699ms dev-loop17.device
   698ms dev-loop28.device
   692ms dev-loop27.device
   688ms dev-loop21.device
   685ms dev-loop14.device
   683ms dev-loop15.device
   680ms dev-loop19.device
   678ms dev-loop20.device
   677ms dev-loop18.device
   677ms dev-loop30.device
   677ms dev-loop16.device
   673ms dev-loop22.device
   654ms motd-news.service
   653ms dev-loop29.device
   636ms dev-loop31.device
   623ms plymouth-start.service
   621ms snapd.service
   614ms systemd-rfkill.service
   522ms systemd-journal-flush.service
   278ms snap-canonical\x2dlivepatch-41.mount
   270ms systemd-fsck@dev-disk-by\x2duuid-A9BB\x2d3F03.service
   252ms systemd-logind.service
   244ms systemd-udev-trigger.service
   238ms snap-kotlin\x2dnative-7.mount
   230ms snap-gnome\x2dcalculator-180.mount
   205ms udisks2.service
   196ms snap-communitheme-533.mount
   189ms snap-core-4830.mount
   182ms systemd-udevd.service
   179ms NetworkManager.service
   179ms networkd-dispatcher.service
   178ms snap-gtk\x2dcommon\x2dthemes-319.mount
   175ms libvirtd.service
   174ms systemd-resolved.service
   172ms upower.service
   168ms systemd-timesyncd.service
   148ms snap-postman-21.mount
   146ms snap-gnome\x2dsystem\x2dmonitor-45.mount
   143ms snap-gnome\x2dsystem\x2dmonitor-51.mount
   136ms snap-gnome\x2dsystem\x2dmonitor-36.mount
   136ms snap-vscode-38.mount
   130ms snap-gnome\x2dcalculator-178.mount
   130ms snap-gnome\x2dcharacters-103.mount
   129ms snap-communitheme-575.mount
   127ms snap-gnome\x2dcharacters-101.mount
   127ms ModemManager.service
   124ms snap-postman-13.mount
   120ms accounts-daemon.service
   119ms snap-gnome\x2dcalculator-154.mount
   119ms snap-gnome\x2d3\x2d26\x2d1604-59.mount
   116ms snap-android\x2dstudio-51.mount
   115ms snap-postman-17.mount
   115ms snap-android\x2dstudio-47.mount
   108ms snap-gnome\x2dlogs-37.mount
   108ms snap-core-4917.mount
   108ms snap-gnome\x2d3\x2d26\x2d1604-70.mount
   108ms lvm2-monitor.service
   107ms snap-kotlin\x2dnative-6.mount
   106ms snap-gnome\x2dcharacters-69.mount
   106ms snap-gnome\x2d3\x2d26\x2d1604-64.mount
   105ms apparmor.service
   103ms grub-common.service
   102ms snap-core-4486.mount
   101ms snap-communitheme-483.mount
   100ms snap-spotify-16.mount
    99ms snap-slack-7.mount

Я использую человечность 18.04 на i5 ноутбуке процессора.

Запуск раньше занимал приблизительно 5-10 секунд, но теперь это спустя более чем 40 секунд после изменения размеров моих разделов.

Править: Вот вывод journalctl -k -b: https://pastebin.com/0ZAGvjit И вывод dmesg вскоре после начальной загрузки: https://pastebin.com/2fh9tExW

Я вижу 30-секундный переход здесь для монтирования раздела файловой системы:

[    3.092379] usb 1-8: Manufacturer: Samsung
[    3.102411] usbcore: registered new interface driver usbhid
[    3.102412] usbhid: USB HID core driver
[    3.804772] [drm] RC6 on
[   34.366616] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

Какие-либо идеи?

0
задан 11 July 2018 в 18:28

1 ответ

Зафиксированный это, для тех из Вас с подобными проблемами: Регистрация /etc/initramfs-tools/conf.d/resume если существует UUID в нем как RESUME=some-uuid удалите uuid и замену none быть RESUME=none. После того выполнения sudo update-initramfs -u и должно быть хорошо пойти.

Найденный решением здесь.

0
ответ дан 28 October 2019 в 09:08

Другие вопросы по тегам:

Похожие вопросы: