Ядро 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 секунд, чтобы смонтировать файловую систему, и если нет, как узнать больше? о том, что может быть причиной задержки?

РЕДАКТИРОВАТЬ 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)

РЕДАКТИРОВАТЬ 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)

Я сделаю пару перезапусков, чтобы выяснить, меняется ли это случайно или остается неизменным (блок кода в первом редактировании выполняется с первой загрузки после установки дополнительного жесткого диска).

РЕДАКТИРОВАТЬ 2.5: random: crng init doneобычно появляется в моменты времени, как показано в редактировании 1, редко как в редактировании 2. Кажется, что это ... случайно.

У меня была такая же проблема. Во время загрузочных сообщений будет указано, что истекло время ожидания возобновления работы устройства. Проверьте, /etc/initramfs-tools/conf.d/resumeесть ли в нем UUID, например, RESUME=some-uuidудалите uuid и замените его на «none» 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 of 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 после удаления раздела подкачки и создания файла подкачки.

Вывод 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

И теперь он загружается очень быстро.