No recuerdo cuándo comenzó a ocurrir el problema, pero es probable cuando moví mi imagen de Ubuntu VMWare a un SSD externo para poder usar el sistema operativo en cualquiera de mis PC. No hay muchos enlaces en Google sobre el tema, pero los que aparecen hablan fstab
. Por ejemplo, Arranque lento: ¿qué es "Se está ejecutando un trabajo de inicio para dev-disk-by ..."? - Foro OpenSUSE .
Menciona tener que eliminar la partición de intercambio y crearla nuevamente.
Puedo intentar hacer esto con Gparted, pero mi principal preocupación es perder mi configuración actual en Ubuntu, ya que no estoy completamente seguro de lo que sucederá si me meto en el intercambio como se sugiere en el hilo. Alguien capaz de ayudar?
Respuestas:
Si obtiene "un trabajo de inicio iniciado por dev-disk-by .." seguido de un retraso de 90 segundos durante cada arranque, complete los siguientes pasos:
Edite el archivo fstab usando la línea de abajo.
Encuentra el dispositivo que no estás usando actualmente
Inserte un
#
y un espacio al comienzo de esa línea coméntelo.Restablecer, ¡espero que funcione para ti!
fuente
/etc/fstab
, también pueden revisarlo/etc/crypttab
, ese fue mi caso.Parece que el problema se debió al hecho de que aunque fstab tenía una entrada para un intercambio, en realidad no la había. Usé GParted para cambiar el tamaño de la partición y creé un nuevo Swap. Luego copié el UUID en el archivo fstab ...
fuente
Tuve el mismo problema después de cambiar el tamaño de mi partición primaria en mi VM ya que gparted live me obligó a eliminar y reiniciar mi intercambio para hacerlo. Eso provocó que se configurara un nuevo UUID que no coincidía con el archivo fstab.
Para evitar el problema,
/etc/fstab
puedeReemplace el UUID de intercambio con el nuevo (ejecutar
sudo blkid
para encontrarlo) después del cambio de tamaño de la partición primaria.O comente la partición de intercambio antes (o después) del cambio de tamaño de la partición primaria.
Recomendaría el primero ya que es la forma en que el SO está destinado a ser configurado.
fuente
En mi caso, anteriormente había estado usando intercambio encriptado, y el trabajo de inicio mencionado
/dev/mapper/cryptswap1
. Para resolver el problema, también tuve que eliminar el archivo/etc/crypttab
, además de los pasos descritos en la respuesta de William MacDonald.fuente
Al cambiar el tamaño o eliminar particiones con gparted, a menudo tiene que crear una nueva partición de intercambio.
Luego es necesario activar el intercambio a través de gparted después de su creación (existe el comando "Activar intercambio").
Además, debe copiar el nuevo UUID en / etc / fstab para montarlo; de lo contrario, en el arranque, el sistema operativo intentará encontrarlo, pero en vano porque el archivo fstab contiene el UUID que hace referencia al antiguo intercambio. Gparted entrega la información para el UUID pero puede ejecutarlo fácilmente en la terminal:
para encontrarlo.
fuente
Tuve el mismo problema al arrancar.
En mi
/etc/fstab
archivo, mis particiones se definieron como/dev/sda1
,/dev/sda2
etc., pero al arrancar, varias veces apareció el mensaje " Se está ejecutando un trabajo de inicio para dev-sdx " ("x" define qué unidad o partición se vio afectada).Para resolverlo, cambié el valor de
/dev/sdx
por el UUID de la partición. Para ver el UUID, desde la terminal ejecutelsblk -f
. Luego, copie el UUID de la partición afectada y escríbalo en el/etc/fstab
archivo, reemplazando de la/dev/sdax
siguiente manera:/dev/sda1
cambios aUUID=xxxxxxxxxxxxxxxxxx
.Funcionó para mí, espero que esta información sea útil.
fuente
Mi arranque se ralentizó porque cambié mi unidad y el UUID no coincidía. Esto hizo que Ubuntu escaneara durante el arranque.
Con frecuencia cambio unidades. Si sus monturas siempre están en el mismo lugar (como el mío), puede eliminar el UUID y colocar la ruta directa para evitar que ocurra ese error de escaneo ...
fuente
Situación principal:
Ya respondí en detalles ... (Debe verificar el UUID debajo de esos archivos)
Situación alternativa I - Udev:
Esto podría ser causado por udev si tiene un script de regla
/etc/udev/rules.d/
que no debe ejecutarse en el momento del arranque, si el script falla, hará que el paso fstab continúe para siempre, solo edite su script para que coincida con sus necesidades o elimínelo.Situación alternativa II - Desarrollador cifrado:
Las particiones cifradas pueden ser confusas porque la partición principal tiene un UUID y el descifrado mapeado tiene otro UUID diferente del principal para una única partición, deben definirse en un lugar diferente
etc/crypttab
y/etc/fstab
El UUID real debe especificarse en
etc/crypttab
El UUID virtual debe estar en
/etc/fstab
Situación alternativa III - Ghost Dev:
Un dispositivo que está configurado para montarse en el momento del arranque pero que no está presente en el sistema ni está separado como una unidad usb.
Verifique los dispositivos conectados reales con
lsblk -o name,uuid,mountpoint
y edite/etc/fstab
para mantener solo el dispositivo conectado O deje el dispositivo no conectado allí, pero configúrelos para que se ignoren en el arranque con la opciónnoauto
y configure la línea de esta maneraComprobación de los registros del sistema
fuente
Además de verificar
/etc/fstab
o/etc/crypttab
como se menciona en las otras respuestas, también verifique los UUID provenientes de los parámetros del núcleo en/etc/default/grub
. Durante un tiempo estuve muy confundido por un sistema que tenía un cromulent perfecto/etc/fstab
solo para descubrir unresume=…
parámetro del núcleo en la configuración de GRUB.fuente
/etc/default/grub
, también tuve que hacer cambios en/boot/efi/EFI/fedora/grub.cfg
. El parámetro "resume = UUID = ..." de Linux se volvió obsoleto después de alterar manualmente la partición de intercambio.Puede omitir la espera e ir directamente a la pantalla de inicio de sesión utilizando ' Ctrl+ c' y luego trabajar en la solución. A veces esto continuará para siempre si no.
fuente
Sé que esto es antiguo, pero me topé con este problema, el mismo mensaje de error, mientras clonaba una instalación con rsync. Al no tener errores en fstab, el problema se resolvió después de actualizar el initrdfs a mano. para lograr eso,
Arrancar la máquina en una instalación que funcione (máquina de arranque múltiple, livecd de lo contrario)
montar la partición raíz del sistema con el problema
monte dev, sys y proc como para un chroot que funcione
chroot en la raíz del sistema de archivos
ejecutar mkinitrd
salga de chroot y reinicie.
fuente