Ядро Xubuntu 18.04 завантажується довго

Після оновлення з 17.10 я пережив триваліші завантаження. Спочатку це зайняло більше 5 хвилин. dmesgвиявив винуватця неіснуючої дискети, яку ядро ​​намагався знайти.

Швидко усунувши це, 5 хвилин знизилися приблизно до 40 секунд, що, як мені здається, ще більше, ніж минуло до оновлення. Повторний запуск dmesgпоказує, що для монтажу файлової системи ( повного виводу ) потрібно 30 секунд із таким повідомленням:

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Я завантажуюся з SSD, підключені ще два жорсткі диски, один з яких відформатований у ext4, але не містить системних даних. Я припускаю, що це SSD. За ці 30 секунд жодного тексту не відображається, а також не сплеск, а лише порожній екран.

Тепер я сказав, що це відчувається повільніше, ніж до оновлення, тому що я не мав точного часу раніше, тому моє перше запитання - чи нормально зайняти 30 секунд для монтажу файлової системи, і якщо ні, як дізнатися більше про те, що може спричинити затримку?

EDIT 1:

Увімкнення або вимкнення свопу не впливає ні на що

Тим часом я також встановив ще один жорсткий диск у свій комп’ютер. Здається, я ще більше збільшив час завантаження на 10 секунд, а ще один рядок з'явився на dmesgвиході, безпосередньо перед згаданою 30-секундною затримкою:

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

EDIT 2:

systemd-analyze blameрезультати тут

тим часом, після декількох перезавантажень, dmesgлінії, які я звинувачував вище, змінили свій час таким чином:

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Я зроблю пару перезавантажень, щоб дізнатися, чи змінюється це випадковим чином, чи залишається таким же (блок коду в першому редагуванні відбувається з першого завантаження після вставки додаткового жорсткого диска).

EDIT 2.5: random: crng init doneзазвичай з’являється в рази, як показано в редагуванні 1, рідко як у редагуванні 2. Це здається… випадковим.

У мене була така ж проблема. Під час завантажувальних повідомлень було б сказано, що він вичерпав очікування відновлення пристрою. Перевірте, /etc/initramfs-tools/conf.d/resumeчи є UUID в ньому, як RESUME=some-uuidвидалити uuid і замінити на "немає", щоб бути RESUME=none. Після цього біжи, sudo update-initramfs -uk allі слід добре піти.

У мене була ця проблема не раз, і моє рішення працює в будь-яких ситуаціях.

Під час запуску dsmeg помилка відображається як:

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

Рішення полягає в:

Спочатку порівняйте свій fstab та blkid:

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"



$ sudo nano /etc/fstab


# /etc/fstab: static file system information
#
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

Як ви бачите, мій своп у / dev / sda7 має інший UUID у fstab, ніж у blkid. У моєму випадку це було викликано іншою установкою Linux, яка перезаряджала своп і спричиняла зміни UUID. Затримка завантаження викликається системою, яка намагається знайти новий UUID свопу. Щоб виправити це, просто скопіюйте UUID у blkid, який не відповідає файлу fstab, а потім збережіть.

Якщо після перезавантаження помилка завантаження все-таки є, вам потрібно додатково відредагувати файл initramfs.conf.

Зробіть це:

$ sudo nano  /etc/initramfs-tools/conf.d/resume

Потім або створивши новий файл, або відредагувавши поточний файл резюме, напишіть у перший рядок RESUME = UUID = << UUID swap >>

Наприклад, так виглядає моя

RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59

Потім запустіть команду нижче, щоб оновити файл initramfs.

#sudo update-initramfs -u

Потім перезапустіть. Помилки не буде.

Я випробував подібне збільшення часу завантаження, і після того, як розслідування з dmesgі systemd-analyze blameзлочинець опинивсяrandom: crng init

Здається, що проблема не є достатньою ентропією при завантаженні з SSD для ініціалізації. Ця гіпотеза, як видається, підтверджується, тому що, коли маніпулювання мишею купу під час завантаження скорочує час завантаження приблизно від 2 хвилин вниз, щоб закрити те, що було раніше.

Під час завантаження ядро ​​чекає, коли рухи миші ініціалізують генератор випадкових чисел. Повідомлення ядра під час завантаження:
sudo dmesg | less

Проблема:
kernel: random: crng init done

Рішення:
sudo apt install haveged
sudo systemctl enable haveged

У мене виникли проблеми з повільним завантаженням на ubuntu 19.04 після видалення swap-розділу та створення файлу swap.

Вихід dmesg

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

Немає свопфайлу в / etc / fstab. Усі змонтовані диски / uuids були правильними.

Я перевірив, /etc/initramfs-tools/conf.d/resumeале цей файл відсутній.

Я просто бігаю

sudo update-initramfs -uk all

І зараз він завантажується дуже швидко.