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

109

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

Скриншот

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

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

cpd1
источник
Возможно, вы захотите клонировать свой SSD, и тогда вы можете вырубить себя :) (попробуйте CloneZilla для этого)
Grammargeek
Ха, да, я думаю, что смогу сделать это. Я подожду, пока я вернусь домой из отпуска, чтобы я мог переместить его туда, где у меня будет больше места
cpd1
1
Я закончил тем, что исправил это. Я не думаю, что когда-либо был обмен, если я иду Gparted. В итоге я создал один и изменил запись в fstab. Это сработало и не более 90 секунд загрузки
cpd1
1
если вы решили свою собственную проблему, сделайте свой собственный ответ и нажмите на флажок, чтобы пометить его как решенный :)
Grammargeek
1
Имеет смысл ... Я добавил это
cpd1

Ответы:

115

Если вы получаете «стартовое задание, запускаемое dev-disk-by ..» с последующей 90-секундной задержкой при каждой загрузке, выполните следующие шаги:

  1. Установите gparted с помощью Центра программного обеспечения
  2. Откройте gparted и посмотрите, какие разделы использует Ubuntu
  3. Отредактируйте файл fstab, используя строку ниже.

    sudo -H gedit /etc/fstab
    
  4. Найдите устройство, которое вы не используете в настоящее время

  5. Вставьте #в начале этой строки пробел и закомментируйте его.

  6. Сброс, надеюсь, это работает для вас!

Уильям Макдональд
источник
3
Пошаговые инструкции помогут всем! Спасибо!
Джон Холл
Я отметил вас как ответ, так как вы дали шаги
cpd1
9
+1 ... для тех, кто не может найти это /etc/fstab, вы можете также проверить это /etc/crypttab- это был мой случай.
Гжегож
7
Если изменился идентификатор блока, вместо того, чтобы комментировать его, я предпочитаю исправить идентификатор устройства. Используйте lsblk -f, чтобы увидеть, какое устройство связано с каким идентификатором, и заменить идентификатор.
user1708042
3
Для меня сработало изменение шага 4 на «Копировать UUID, найденный в gparted для устройства, вызывающего задержку при загрузке», и шаг 5: «Заменить его там, где устройство найдено в файле fstab». Иногда, когда вы меняете перемещение разделов, UUID меняются, и это является причиной проблемы. Вам просто нужно исправить новый UUID для измененного раздела.
m4l490n
35

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

  1. У меня сейчас своп
  2. И загрузка идет с точностью до секунд против 90+ секунд
cpd1
источник
5
Я изменил размер моего основного раздела (удаление / воссоздание подкачки) и столкнулся с этой проблемой. Я использовал sudo blkid для вывода списка устройств по UUID, а затем использовал новый UUID в / etc / fstab.
Брэд Госс
32

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

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

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

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

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

Мэтью Кордаро
источник
Помогло и мне после перемещения раздела подкачки
po.pe
17

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

Калле Эльмер
источник
6

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

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

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

sudo blkid

найти его.

Алессандро Д'Инкал
источник
4

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

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

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

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

Лорд ферм
источник
Да. Это именно та проблема, которую решает UUID. Система монтирует любой раздел с таким идентификатором, независимо от того, на каком устройстве он находится или где расположен раздел. С другой стороны, вам нужно менять UUID всякий раз, когда вы уничтожаете / создаете раздел или устанавливаете новый диск. А дублирование раздела (gparted copy / paste) создаст копию с одинаковым UUID, что может вызвать проблемы, если оригинал и копия одновременно находятся в режиме онлайн. Для большинства людей это нормально, но вы должны помнить об этом при клонировании / замене дисков.
Дэвид С.
3

Моя загрузка замедлилась, потому что я поменял местами накопитель, а 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
Дэн
источник
Как это предложение ускорит загрузку? Любая ссылка?
Мостафа Ахангарха
Я отвечал на его вопрос об ошибке, который вызвал медленную загрузку. Я пояснил свой ответ.
Дан
1
Да, монтирование по имени устройства позволяет избежать этой проблемы, но также создает проблему, которую UUID (и метки тома) должны были решить - при подключении диска к разным местам (например, из одного интерфейса SATA в другой) имя устройства изменится, ломая ваши горы. Вам нужно решить, с какой проблемой легче жить, но убедитесь, что вы помните свое решение, потому что оно может быть очень неприятным, когда проблема возникает из-за того, что вы забыли.
Дэвид С.
3

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

Уже ответил подробно ... (Вам нужно проверить 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
intika
источник
1
Спасибо, это очень хороший ответ, и его следует принять. Большинство других ответов здесь опасно неправильны, и даже если они обходят проблему, они вводят другие проблемы, которые могут быть менее очевидными, например, удаление шифрования устройства подкачки.
Вакар Лим
2

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

Случайный плакат
источник
1
Это помогло мне решить проблему. Мой / etc / fstab был в порядке. Затем, кроме того, /etc/default/grubмне также пришлось внести изменения в /boot/efi/EFI/fedora/grub.cfg. Параметр linux "resume = UUID = ..." устарел после того, как я вручную изменил раздел подкачки.
Стефан
1

Вы можете пропустить ожидание и перейти к экрану входа в систему непосредственно с помощью « Ctrl+ c», а затем поработать над решением. Иногда это будет продолжаться вечно, если нет.

Рамон Суарес
источник
Это буквально Ctrl, клавиша плюс и c?
Муру
Да, вот и все :)
Рамон Суарес
0

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

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

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

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

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

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

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

merchamion
источник