Медленная начальная загрузка, долгое время загрузки ядра, из-за неправильного устройства резюме
В течение некоторого времени мой процесс начальной загрузки занимает слишком много времени (почти 1 минута).
systemd-analyse time
шоу, что ядро занимает 35,765 с
Взгляд на dmesg, кажется, что проблема с монтированием файловых систем:
...
[ 2.186084] sdb: sdb1 sdb9
[ 2.186919] sd 2:0:0:0: [sdb] supports TCG Opal
[ 2.186922] sd 2:0:0:0: [sdb] Attached SCSI disk
[ 2.499795] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.844320] clocksource: Switched to clocksource tsc
[ 35.670493] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[ 35.782128] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 35.803610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
...
Мой /etc/fstab похож на это:
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=3996-2381 /boot/efi vfat umask=0077 0 1
#/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0
Как я могу диагностировать это?
Править: пристально смотря на сообщения загрузки (после удаления тихой опции в личинке), я определил подозрительную строку:
gave up waiting for suspend/resume device
Я думаю, что моя подкачка шифруется, и я также думаю UUID в /etc/initramfs/conf.d/resume не соответствует никакому устройству.
Должен я отключать возобновиться/приостановить? и как сделать это?
4 ответа
Хорошо, я нашел решение, благодаря комментарию Судханшу.
Проблема была в том, что мой своп был зашифрован. Таким образом, скрипт local-premount в initramfs ожидал недоступного устройства подкачки, пока не истекло время ожидания. Соответствующее сообщение было gave up waiting for suspend/resume device.
Чтобы отключить это (поскольку восстановление из подкачки невозможно с помощью зашифрованной подкачки, и я все равно не использую спящий режим), я изменил этот файл: /etc/initramfs-tools/conf.d/resume.
В этом файле строка с
RESUME=none
(вместо UUID, который был здесь) отключит ожидание устройства возобновления.
Запустите
sudo update-initramfs -u
, чтобы применить изменения.
Система теперь загружается нормально.
Ни одно из этих решений выше или в другом месте не сработало для меня, но я нашел решение, которое сокращает время моей загрузки до 40 секунд с 2 минут и 10 секунд.
Я использовал для создания и удаления разделов подкачки, и почему-то эти журналы остались в файле etc / fstab. Поэтому моя система пыталась смонтировать те ранее созданные разделы подкачки, которых больше не существует. Поэтому, пожалуйста, позвольте мне объяснить, что я сделал, шаг за шагом.
-
Я запустил эту команду
sudo blkid | grep swap, чтобы узнать мои разделы подкачки. Их было два, но один на самом деле не существует (он не относится ни к одному из моих разделов). -
Поэтому я пошел редактировать файл / etc / fstab, набрав
sudo gedit /etc/fstab -
Затем я понял, что существует так много файлов подкачки, которые я удалил, но каким-то образом возобновил существующие в этом файле. Поэтому я сослался на шаг 1 и удаленные разделы, которых больше не существует .
Пожалуйста, смотрите два перед & amp; после / etc / fstab скриншоты файла. После этой очистки все работает как обычно.
Это неотредактированный файл / etc / fstab , неотредактированный / etc / fstab
и здесь после удаления несуществующих разделов подкачки clean / etc / fstab [ 113]
![clean / etc / fstab [ 113]](https://i.stack.imgur.com/7xflj.png){kind=link}
У меня возникла эта проблема после установки 2 разных дистрибутивов Linux. Каким-то образом в одном дистрибутиве раздел подкачки получил другой UUID, назначенный ему, а затем ожидал. Мое решение было: во-первых, запустите sudo blkid, чтобы получить правильный UUID для раздела подкачки. Скопируйте UUID свопа. Вставьте его в /etc/initramfs-tools/conf.d/resume, чтобы получить RESUME=_the_correct_UUID_. Теперь запустите sudo update-initramfs -u, чтобы применить это изменение.
Затем проверьте / etc / fstab и измените UUID раздела подкачки, если это необходимо. (Я должен был)
Я также видел это в Linux Mint (на основе Ubuntu) и провел некоторое время, работая, что шло не так, как надо.
Это происходит, если Ваша система установлена на LVM и использует объем LVM в качестве диска подкачки.
Существует давняя, повторяющаяся ошибка, где файл резюме неправильно имеет UUID (который недопустим для LVM) вместо пути устройства, который это должно иметь. См. https://bugs.launchpad.net/ubuntu / + source/initramfs-tools / + ошибка/1768230
Можно зафиксировать его путем редактирования /etc/initramfs-tools/conf.d/resume файл и замена UUID с путем устройства диска подкачки. Следующий отрывок команды сделает это для Вас, с помощью первого диска подкачки, о котором, найденного и сообщает blkid:
sudo bash -c 'mv /etc/initramfs-tools/conf.d/resume /tmp/resume.bak; echo RESUME=$(blkid | \grep -I swap | head -n 1 | cut -d : -f 1) > /etc/initramfs-tools/conf.d/resume'