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

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

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

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

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

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

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

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

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

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

Уже ответил подробно... (Вам нужно проверить 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

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

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

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

sudo blkid

найти его.

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

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

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

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

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

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

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

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

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

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

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

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

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

В моем случае своп был сгенерирован дважды с /dev/sda5 сначала с UUID следующим образом:

      # swap was on /dev/sda5 during installation 
UUID=74db72c3-6fd6-44d6-9403-fc5d0f4d0163 none            swap    sw  0       0
# swap was on /dev/sdb2 during installation 
UUID=b56fd46a-f3c3-4387-ab40-4e39eeaacab7 none            swap    sw  0       0

но с disksтолько первый в /dev/sda5 был правильным, поэтому я

      sudo cp /etc/fsatab /etc/fstab-backup 

а затем прокомментируйте второй

      # swap was on /dev/sdb2 during installation
# UUID=b56fd46a-f3c3-4387-ab40-4e39eeaacab7 none            swap    sw              

тогда:

      sudo update-grub2

в конце концов :

      sudo reboot

и теперь он загружается менее чем за 10 секунд на моем старом Acer Apsire 7551G с ssd-диском. Спасибо всем, кто дает рабочие предложения в этом посте!

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

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

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

Я пробовал редактировать /etc/fstab && файл / etc / default / grub

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

Снятие отметки с опции "монтировать при запуске системы" устранило проблему.

В моем случае я создал 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

Для тех, кто использует nixOS и сталкивается с этим:

Я увеличил свой системный раздел EFI (удалив немного места вокруг него и переместив его влево, чтобы он был воссоздан), и из-за этого UUID моего раздела изменился. Я мог бы восстанавливаться каждый раз, когда перестраивал конфигурацию nix, меняя свой fstab, но fstab каждый раз перегенерируется на основе/etc/nixos/hardware-configuration.nix. Обязательно измените UUID на новый внутри этого файла.

В любых других дистрибутивах убедитесь, что/etc/fstabразумен, обычно этого должно быть достаточно.