a start job is running for dev disk by как исправить
Долгая загрузка системы. Сообщение A start job is running for dev-disk-by
Недавно столкнулся с тем, что при включении компьютера, система Elemntary OS стала загружаться вместо считанных секунд больше минуты.
Во время загрузки отображается логотип дистрибутива. Если нажать клавишу Esc, то можно увидеть лог загрузки. У меня выводилось следующее сообщение, и шел обратный отсчет секунд (90-секундный таймер, который и тормозил запуск):
Также чтобы просмотреть лог загрузки, можно воспользоваться командой:
У меня в логе были следующие сообщения:
Подобные сообщения означают, что система пытается подключить какой-либо раздел диска, но не может этого сделать. Чтобы исправить ситуацию необходимо отредактировать файл /etc/fstab.
В моем случае вывод был следующим:
Теперь откроем файл /etc/fstab для редактирования. Воспользуемся для этого редактором nano:
У меня файл /etc/fstab выглядел так:
Вы должны проверить, что в данном файле нет записей о разделах диска, которые уже существуют или не используются. Если таковые имеются, то соответствующие записи нужно закомментировать (используя символ решетки #).
Сохраните изменения и закройте файл. Теперь можно перезагрузить компьютер, если все было сделано правильно, то подобные сообщения больше не должны появляться.
swap блокирует загрузку
Всем привет. Поставил Xenial, обновляя по LTS, и теперь система грузится через два раза на третий. Останавливается на сообщении A start job is running for dev-sda2.service + A start job is running for dev-disk-by-uuid\(uuid раздела со swap) с таймаутом в полторы минуты. Иногда к этому добавляется Coldplug all devices с бесконечным таймаутом. Но в конце концов это всё выливается в maintenance console, из которой загрузка не идёт дальше.
Понимаю, что без логов это слишком похоже на объяснение на пальцах, но тут у меня ещё загвоздка:
Specifying boot ID has no effect, no persistent journal was found
Вот так в дебиане интегрировали сустемд да. dmesg, /var/log/messages смотрел?
Дык нет такого файла. Вроде, всё перенесли в journalctl.
В dmesg только пара строчек по делу, примерно таких:
Хотя в этот раз корень (sda4) и /home (sda3) смонтировались без проблем, rw оба. Была пара случаев, когда /home тоже вис в пару к свапу.
Ещё раз полистал сбойный journalctl, так ничего и не выловил. Вот момент сбоя:
Инициализируйте swap file в четыре комманды, Arch wiki вам в помощь.
Да не в swap дело, похоже. swapoff /dev/sda2 и все упоминания в /etc/fstab убрал — та же петрушка. Разве что снести с этого места раздел для чистоты эксперимента, но это напоминает ампутацию против головной боли.
Вот. После этого должна быть строка про sensors (подсмотрел на работающем ноутбуке), но я так больше ничего из него и не выжал.
Вот. И что можно ожидать, от этого архаичного диска?
Он начал сыпаться, просто-напросто.
Он, мог бы технически верно оценить состояние HDD.
И так удачно сыплется, что при копировании системы не вылезло ни одной ошибки? Слабо верится. Не, я сейчас найду какую-нибудь приблуду для тестирования с live CD, может, где и есть коварный bad block.
Долгая загрузка системы. Сообщение A start job is running for dev-disk-by
Недавно столкнулся с тем, что при включении компьютера, система Elemntary OS стала загружаться вместо считанных секунд больше минуты.
Во время загрузки отображается логотип дистрибутива. Если нажать клавишу Esc, то можно увидеть лог загрузки. У меня выводилось следующее сообщение, и шел обратный отсчет секунд (90-секундный таймер, который и тормозил запуск):
Также чтобы просмотреть лог загрузки, можно воспользоваться командой:
У меня в логе были следующие сообщения:
Подобные сообщения означают, что система пытается подключить какой-либо раздел диска, но не может этого сделать. Чтобы исправить ситуацию необходимо отредактировать файл /etc/fstab.
Сначала выведите на экран информацию о разделах. Воспользуемся командой lsblk, которая выводит информацию о блочных устройствах в Linux:
В моем случае вывод был следующим:
Теперь откроем файл /etc/fstab для редактирования. Воспользуемся для этого редактором nano:
У меня файл /etc/fstab выглядел так:
Вы должны проверить, что в данном файле нет записей о разделах диска, которые уже существуют или не используются. Если таковые имеются, то соответствующие записи нужно закомментировать (используя символ решетки #).
Сохраните изменения и закройте файл. Теперь можно перезагрузить компьютер, если все было сделано правильно, то подобные сообщения больше не должны появляться.
Упоминает необходимость удалить раздел подкачки и создать его снова.
Отредактируйте файл fstab, используя строку ниже.
Найдите устройство, которое вы не используете в настоящее время
Вставьте # в начале этой строки пробел и закомментируйте его.
Сброс, надеюсь, это работает для вас!
У меня возникла та же проблема после изменения размера моего основного раздела на моей виртуальной машине, так как gparted live заставил меня удалить и повторно инициализировать мой своп для этого. Это привело к установке нового UUID, который не соответствовал файлу fstab.
Чтобы избежать этой проблемы, /etc/fstab вы можете либо
Замените UUID подкачки на новый (запустите, sudo blkid чтобы найти его) после изменения размера основного раздела.
Или закомментируйте раздел подкачки до (или после) изменения размера основного раздела.
Я бы порекомендовал первый, так как это способ установки ОС.
При изменении размера или удалении разделов с помощью gparted вам часто приходится создавать новый раздел подкачки.
Затем необходимо активировать своп через gparted после его создания (есть команда «Активировать своп»).
Более того, вы должны скопировать новый UUID в / etc / fstab, чтобы смонтировать его, иначе при загрузке ОС попытается найти его, но тщетно, поскольку файл fstab содержит UUID, ссылающийся на старый своп. Gparted предоставляет информацию для UUID, но вы можете легко запустить в терминале:
У меня была такая же проблема при загрузке.
Это сработало для меня, я надеюсь, что эта информация полезна.
Моя загрузка замедлилась, потому что я поменял местами накопитель, а UUID не совпадал. Это заставило Ubuntu выполнить сканирование во время загрузки.
Основная ситуация:
Это может быть вызвано udev, если у вас есть скрипт правила, /etc/udev/rules.d/ который не предназначен для запуска во время загрузки, если скрипт не удастся выполнить, этот шаг fstab будет продолжаться вечно, просто отредактируйте ваш скрипт в соответствии с вашими потребностями или удалите его.
Реальный UUID должен быть указан в etc/crypttab
Виртуальный UUID должен быть на /etc/fstab
Устройство, которое настроено для подключения во время загрузки, но отсутствует в системе или отключено, как USB-накопитель.
Проверка системных журналов
Mentions having to delete the swap partition and creating it again.
I can try to do this with Gparted but my main concern is losing my current set up in Ubuntu as I’m not entirely sure what will happen if I mess with swap as suggested in the thread. Anyone able to help?
15 Answers 15
A start job is running for dev-disk-by.
followed by a 90 second delay during each boot, complete the following steps:
Install GParted using the Software Center
Open GParted and see what partitions Ubuntu is currently using
Edit the fstab file using the line below.
If you have a device that you are not currently using, insert a # and a space at the beginning of that line comment it out.
Reboot and the start job shouldn’t appear again.
I had the same issue after resizing my primary partition on my VM since gparted live forced me to delete & reinitialize my swap to do so. That caused a new UUID to be set that didn’t match the fstab file.
To avoid the issue, in /etc/fstab you can either
Replace the swap UUID with the new one (run sudo blkid to find it) after the primary partition resizing.
Or, comment out the swap partition before (or after) the primary partition resizing.
I would recommend the former since it is the way the OS is meant to be setup.
Looks like the issue was due to the fact that even though fstab had an entry for a swap, there actually wasn’t one. I used GParted to resize the partition and created a new Swap. I then copied the UUID into the fstab file.
Main Situation :
You need to check the UUID under those files (answered in details on other answers. )
This could be caused by udev if you have a rule script under /etc/udev/rules.d/ that is not meant to run at boot time, if the script fail it will make that fstab step go on forever, just edit your script to match your needs or delete it.
Crypted partitions can be confusing because the main partition have an UUID and the mapped Decrypted one have an other UUID different from the main one for a single partition they have to be defined in different place etc/crypttab and /etc/fstab
Real UUID need to be specified in etc/crypttab
Virtual UUID need to be at /etc/fstab
A device that is setup to be mounted at boot time but is not present in the system or detached like an usb drive.