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

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

1. у меня теперь есть подкачка
2. , И начальная загрузка до в течение секунд по сравнению с 90 + секунды

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

Для предотвращения проблемы в /etc/fstab Вы можете любой

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

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

я рекомендовал бы первому, так как это - способ, которым ОС предназначена, чтобы быть установкой.

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

затем необходимо активировать подкачку через gparted после его создания (существует команда "Activate swap").

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

sudo blkid

для нахождения его.

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

Моя начальная загрузка была замедлена, потому что я подкачал свой диск, и 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

Можно пропустить ожидание и перейти к экрану входа в систему непосредственно при помощи' Ctrl + c ' и затем работать над решением. Иногда это будет продолжаться навсегда если нет.

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

В моем /etc/fstab файл, мои разделы, где определено как /dev/sda1, /dev/sda2, и т.д., но при начальной загрузке, несколько раз появлялся сообщение" , А запускаются, задание работает за dev-sdx" ("x", определяет, какая единица или раздел были затронуты).

Для решения его я изменил значение /dev/sdx UUID раздела. Для наблюдения UUID, от терминала работает lsblk -f. Затем скопируйте UUID затронутого раздела и запишите это на /etc/fstab файл, заменив /dev/sdax следующим образом: /dev/sda1 изменения в UUID=xxxxxxxxxxxxxxxxxx.

Это работало на меня, я надеюсь, что эта информация полезна.

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

1. загружают машину в рабочую установку (машина мультиначальной загрузки, livecd иначе)

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

3. монтирует dev, sys, и proc что касается рабочего chroot

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

5. выполняют выход mkinitrd

6. chroot и перезагрузку.

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

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

Необходимо проверить UUID под теми файлами (ответил в деталях о других ответах...),

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

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

Это могло быть вызвано udev, если у Вас есть сценарий правила под /etc/udev/rules.d/ это не предназначено для выполнения во время начальной загрузки, если сбой сценария, он сделает это шагом fstab, продолжается навсегда, просто редактирует сценарий, чтобы соответствовать потребностям или удалить его.

Альтернативная ситуация II - Crypted Dev:

Разделы Crypted могут сбивать с толку, потому что основной раздел имеет 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 - Фантом Dev:

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

Контроль реальные подключенные устройства с 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/default/grub

Безрезультатно. Используя gnome-disks, я обнаружил, что мои разделы загружались как блочные устройства при запуске системы.

Снятие флажка с опции «монтировать при запуске системы» решило проблему.

У меня была запись fstab, созданная установщиком для раздела подкачки:

# swap was on /dev/sda2 during installation
UUID=459dcc25-6bfb-449d-941d-5b2e46f93af2 none            swap    sw              0       0

Просмотр диска в диспетчере разделов (в моем случае gnome-disks) показал, что назначен разделом подкачки, но по какой-то причине имеет другой UUID. Простое исправление UUID как root в /etc/fstab исправило это.

В моем случае я создал 2 раздела подкачки на разных дисках, потому что у меня была мультизагрузка со многими разными дистрибутивами.

После комментирования (позже созданного) раздела подкачки он загружался нормально и быстро.

# swap was on /dev/nvme0n1p4 during installation
UUID=4323177d-e25d-42b6-a8db-5b8da8e90cb7 none            swap    sw   0    0


## Commenting the swap partition created at /dev/sda7

# swap was on /dev/sda7 during installation
# UUID=082966df-70f0-4c22-b9da-fc8aa6fb4e9e none            swap    sw   0    0