Повільне завантаження, довгий час завантаження ядра через неправильне відновлення пристрою

Деякий час процес завантаження триває занадто довго (майже 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

Як я можу це усунути?

EDIT: уважно придивившись до завантажувальних повідомлень (після видалення тихої опції в grub), я помітив підозрілу лінію:

gave up waiting for suspend/resume device

Я думаю, що мій своп зашифрований, і я також думаю, що UUID в /etc/initramfs/conf.d/resumeне відповідає жодному пристрою.

Чи слід відключити відновлення / призупинення роботи? і як це зробити?

Гаразд, я знайшов рішення, завдяки коментарю Sudhanshu.

Проблема була через зашифрований мій своп. Тож local-premountсценарій в initramfs чекав пристрою для заміни, який був недоступний, поки він не вичерпався. Відповідне повідомлення було gave up waiting for suspend/resume device.

Щоб відключити цю функцію (як відновлення з свопу НЕ представляється можливим з шифрованого розділу підкачки, і я не використовую сплячий режим в будь-якому випадку), я змінив цей файл: /etc/initramfs-tools/conf.d/resume.

У цьому файлі рядок з

RESUME=none

(замість UUID, який був тут) відключить очікування пристрою відновлення.

Біжи

sudo update-initramfs -u

застосувати зміни.

Тепер система завантажується нормально.

Я також бачив це в Linux Mint (на базі Ubuntu) і витратив деякий час на розробку того, що пішло не так.

Це трапляється, якщо ваша система встановлена ​​на LVM і використовує об'єм LVM в якості диска своп.

Існує давня, повторювана помилка, коли файл резюме неправильно містить UUID (який недійсний для LVM) замість шляху пристрою, який він повинен мати. Дивіться https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230

Ви можете виправити це, відредагувавши /etc/initramfs-tools/conf.d/resumeфайл та замінивши UUID на шлях пристрою диска swap. Наступний фрагмент команди зробить це для вас, використовуючи перший диск swap, знайдений і повідомлений 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'

Жодне з цих рішень вище чи десь не працювало для мене, але я знайшов рішення, яке скорочує час завантаження до 40 секунд з 2 хвилин і 10 секунд.

Я використовував для створення та видалення swap-розділів і якимось чином ці журнали залишалися у файлі etc / fstab. Тому моя система намагалася змонтувати ті створені раніше розділи swap, яких більше не існує. Тому, будь ласка, дозвольте мені пояснити, що я робив крок за кроком.

1. Я запустив цю команду, sudo blkid | grep swapщоб дізнатися свої підкачки. Було два, але одна насправді не існує (вона не стосується жодної з моїх секцій).

2. Тому я пішов редагувати / etc / fstab файл, набравши sudo gedit /etc/fstab

3. Тоді я зрозумів, що існує стільки файлів своп, які я видалив, але якимось чином відновив існуючі в цьому файлі. Тому я посилався на крок 1 та видалив розділи, яких більше не існує .

Будь-ласка, перегляньте два екрани до & після / etc / fstab. Після цього очищення все працює як нормально.

Це не редагуваний / etc / fstab файл без редагування / etc / fstab

і тут після витирання неіснуючих swap-розділів очистити / etc / fstab

Цю проблему я отримав після встановлення 2 різних дистрибутивів Linux. Якось, на одному дистрибутиві, розділ swap отримав інший UUID, призначений йому тоді, як очікувалося. Моє рішення було: По-перше, запустіть, sudo blkidщоб отримати правильний UUID для розділу swap. Скопіюйте UUID свопу. Вставте його, /etc/initramfs-tools/conf.d/resumeщоб ви отримали RESUME=_the_correct_UUID_. Тепер запустіть sudo update-initramfs -uзастосувати цю зміну.

Далі, перевірте / etc / fstab, а також за потреби змініть UUID розділу swap. (Мені довелося)