Повільне завантаження - "запущене завдання запуску для dev-disk-by ..."

Я не пам'ятаю, коли проблема почала виникати, але, ймовірно, коли я перемістив своє зображення VMWare Ubuntu на зовнішній SSD, щоб я міг використовувати ОС на будь-якому моєму ПК. У Google не так багато посилань на цю проблему, але про них, як видається, йдеться fstab. Наприклад, повільне завантаження - що таке "Запуск завдання працює для dev-disk-by ..."? - Форум OpenSUSE .

Згадує про необхідність видалити розділ swap та створити його заново.

Я можу спробувати це зробити з Gparted, але моя головна стурбованість - це втрата поточного налаштування в Ubuntu, оскільки я не зовсім впевнений, що станеться, якщо я зіпсуюся з свопом, як запропоновано в потоці. Хтось може допомогти?

Якщо ви отримаєте "стартову роботу, запущену dev-disk-by .." з подальшим затримкою на 90 секунд під час кожного завантаження, виконайте наступні дії:

1. Встановіть gparted за допомогою Центру програмного забезпечення
2. Відкрийте gparted і подивіться, які розділи зараз використовує Ubuntu

3. Відредагуйте файл fstab за допомогою рядка нижче.

   sudo -H gedit /etc/fstab
   

4. Знайдіть пристрій, яким ви зараз не користуєтесь

5. Вставте а #та пробіл на початку цього рядка, прокоментуйте його.

6. Скиньте, сподіваємось, це працює для вас!

Схоже, проблема виникла через те, що хоча fstab мав запис для своп, насправді такого не було. Я використовував GParted для зміни розміру розділу та створив новий Swap. Потім я скопіював UUID у файл fstab ...

1. Зараз у мене є своп
2. І завантаження знизиться протягом декількох секунд проти 90+ секунд

У мене була така ж проблема після зміни розміру мого основного розділу на моєму VM, оскільки gparted live змусив мене видалити & повторно ініціалізувати мій своп, щоб це зробити. Це призвело до встановлення нового UUID, який не відповідав файлу fstab.

Щоб уникнути проблеми, /etc/fstabви можете будь-яке

• Замініть підкачку UUID на новий (запустіть, sudo blkidщоб знайти його) після зміни розміру основного розділу.

• Або прокоментуйте розділ swap до (або після) зміни розміру основного розділу.

Я рекомендував би попередній, оскільки це спосіб налаштування ОС.

У моєму випадку я раніше використовував зашифрований своп, і згадувалося завдання запуску /dev/mapper/cryptswap1. Щоб вирішити проблему, мені довелося також видалити файл /etc/crypttab, крім кроків, описаних у відповіді Вільяма Макдональда.

Під час зміни розміру або видалення розділів з gparted часто доводиться створювати новий розділ swap.

Потім необхідно активувати своп через gparted після його створення (є команда "Активувати своп").

Крім того, вам доведеться скопіювати новий UUID в / etc / fstab, щоб встановити його в іншому випадку під час завантаження ОС намагатиметься знайти його, але марно, оскільки файл fstab містить UUID, що посилається на старий своп. Gparted доставляє інформацію для UUID, але ви можете легко запустити в терміналі:

sudo blkid

щоб знайти його.

У мене була така ж проблема при завантаженні.

У моєму /etc/fstabфайлі мої розділи, де визначено як /dev/sda1, /dev/sda2і т. Д., Але під час завантаження кілька разів з'являлося повідомлення " Запускається завдання для dev-sdx " ("x" визначає, на який підрозділ чи розділ вплинуло).

Щоб вирішити це, я змінив значення /dev/sdxUUID розділу. Щоб побачити UUID, з запуску терміналу lsblk -f. Потім скопіюйте UUID зачіпаючого розділу та запишіть його у /etc/fstabфайл, замінивши /dev/sdaxнаступним чином: /dev/sda1зміни в UUID=xxxxxxxxxxxxxxxxxx.

Це працювало для мене, сподіваюся, ця інформація корисна.

Моє завантаження сповільнилося, тому що я поміняв свій диск і UUID не збігався. Це спричинило сканування Ubuntu під час завантаження.

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

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1 /               ext4    errors=remount-ro 0       1
/dev/sda2 none            swap    sw              0       0

Основна ситуація:

Вже детально відповіли ... (Вам потрібно перевірити UUID під цими файлами)

/etc/crypttab 
/etc/fstab
/etc/grub.d/40_custom 
/boot/grub2/grub.cfg

Альтернативна ситуація I - Удев:

Це може бути викликано udev, якщо у вас є сценарій правила,/etc/udev/rules.d/ який не призначений для запуску під час завантаження; якщо сценарій не вдасться, він зробить цей крок fstab продовженням назавжди, просто відредагуйте свій сценарій відповідно до ваших потреб або видаліть його.

Альтернативна ситуація II - Криптований Dev:

Зашифровані розділи можуть бути заплутаними, оскільки основний розділ має UUID, а відображений Розшифрований має інший UUID, відмінний від основного, для одного розділу вони повинні бути визначені в іншому місці etc/crypttabта/etc/fstab

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi

Реальний UUID потрібно вказати в etc/crypttab

# cat /etc/crypttab
sda2_crypt  UUID=727fa348-8804-4773-ae3d-f3e176d12dac  none  luks

Віртуальний UUID повинен бути на /etc/fstab

# cat /etc/fstab
UUID=P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi / ext4 defaults,errors=remount-ro 0 1

Альтернативна ситуація III - Ghost Dev:

Пристрій, встановлений для встановлення під час завантаження, але його немає в системі або від'єднати, як привід usb.

Оформити замовлення справжніх підключених пристроїв із lsblk -o name,uuid,mountpointта відредагувати, /etc/fstabщоб зберегти лише підключений пристрій АБО не залишати там непоєднаний пристрій, але налаштувати їх на ігнорування під час завантаження за допомогою параметра noautoта встановити такий рядок

UUID=BLA-BLA-BLA /mount ext4 option,noauto,option 0 0

Перевірка системних журналів

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service

На додаток до перевірки /etc/fstabабо /etc/crypttabяк зазначено в інших відповідях, також перевірте наявність UUID, що надходять із параметрів ядра в /etc/default/grub. Якийсь час мене дуже бентежила система, яка мала ідеально кромулентність /etc/fstabлише виявити resume=…параметр ядра в конфігурації GRUB.

Ви можете пропустити очікування та перейти на екран входу безпосередньо, використовуючи " Ctrl+ c", а потім працювати над рішенням. Іноді це триватиме назавжди, якщо ні.

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

1. завантажте машину в робочу установку (багатозавантажена машина, livecd в іншому випадку)

2. змонтуйте кореневий розділ системи із проблемою

3. mount dev, sys і proc як для робочого chroot

4. chroot в корінь файлової системи

5. виконати mkinitrd

6. вихід chroot та перезавантаження.