Медленная загрузка - «запускается задание для dev-disk-by…»

Я не помню, когда эта проблема начала возникать, но, скорее всего, я переместил образ VMWare Ubuntu на внешний SSD, чтобы я мог использовать ОС на любом из моих компьютеров. В Google не так много ссылок на эту проблему, но появляются те, о которых идет речь fstab. Например, медленная загрузка - что такое «запускается задание запуска для dev-disk-by ...»? - Форум OpenSUSE .

Упоминает необходимость удалить раздел подкачки и создать его снова.

Я могу попытаться сделать это с Gparted, но моя главная проблема - потерять текущие настройки в Ubuntu, так как я не совсем уверен, что произойдет, если я возьму swap, как предложено в теме. Кто-нибудь может помочь?

Если вы получаете «стартовое задание, запускаемое 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+ секунд

У меня возникла та же проблема после изменения размера моего основного раздела на моей виртуальной машине, так как gparted live заставил меня удалить и повторно инициализировать мой своп для этого. Это привело к установке нового UUID, который не соответствовал файлу fstab.

Чтобы избежать этой проблемы, /etc/fstabвы можете либо

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

• Или закомментируйте раздел подкачки до (или после) изменения размера основного раздела.

Я бы порекомендовал первый, так как это способ установки ОС.

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

При изменении размера или удалении разделов с помощью gparted вам часто приходится создавать новый раздел подкачки.

Затем необходимо активировать своп через gparted после его создания (есть команда «Активировать своп»).

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

sudo blkid

найти его.

У меня была такая же проблема при загрузке.

В моем /etc/fstabфайле, мои разделы , где определяется как /dev/sda1, /dev/sda2и т.д., но при загрузке несколько раз появилось сообщение « Задание запуска выполняется для Дев-SDX » ( «х» определяет , какая единица или раздел пострадал).

Чтобы решить эту проблему, я изменил значение /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 - Crypted 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. смонтировать dev, sys и proc как для рабочего chroot

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

5. выполнить Mkinitrd

6. выйдите из chroot и перезагрузитесь.