Ядро 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:
Включение или выключение подкачки не имеет никакого эффекта whatosever
Между тем я также установил другой жесткий диск в свой компьютер. Это, кажется, далее продлило мое время начальной загрузки приблизительно на 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. Это, кажется... случайно.
5 ответов
У меня была такая же проблема. Во время загрузочных сообщений будет указано, что истекло время ожидания возобновления работы устройства. Проверьте в /etc/initramfs-tools/conf.d/resume, есть ли в нем UUID, например RESUME=some-uuid, удалите uuid и замените на «none», чтобы оно было RESUME=none. После этого запустите sudo update-initramfs -uk all, и все будет хорошо.
Я испытал похожее увеличение времени загрузки, и после исследования с 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
У меня была эта проблема многочисленные времена и мои работы решения во всех ситуациях.
При выполнении 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 подкачки>>
Например, мой похож
RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59
Затем работайте ниже команды для обновления initramfs файла.
#sudo update-initramfs -u
Затем перезапуск. Ошибка закончится.
У меня была та проблема с медленным временем начальной загрузки на человечности 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
И теперь это загружается действительно быстро.