El kernel Xubuntu 18.04 tarda mucho en arrancar


10

Después de actualizar desde 17.10, he experimentado tiempos de arranque más largos. Al principio tardó más de 5 minutos. dmesgreveló que el culpable era una unidad de disquete inexistente, que el núcleo intentó encontrar.

Al eliminarlo rápidamente, los 5 minutos se redujeron a aproximadamente 40 segundos, lo que creo que es aún más de lo que tomó antes de la actualización. Ejecutar dmesgnuevamente muestra que lleva 30 segundos montar un sistema de archivos ( salida completa ), con el siguiente mensaje:

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Estoy arrancando desde un SSD, con otros dos discos duros conectados, uno de los cuales está formateado en ext4, pero no contiene datos del sistema. Supongo que este es el SSD. Durante estos 30 segundos, no se muestra texto, ni se muestra un mensaje de bienvenida, solo una pantalla en blanco.

Ahora, dije que se siente más lento que antes de la actualización, porque no tengo tiempos exactos de antes, así que mi primera pregunta es, ¿es normal tomar 30 segundos para montar un sistema de archivos y, si no, cómo obtener más información? acerca de lo que podría estar causando el retraso?

EDITAR 1:

Activar o desactivar el intercambio no tiene ningún efecto

Mientras tanto, también instalé otro disco duro en mi computadora. Parece haber prolongado aún más mi tiempo de arranque en unos 10 segundos, con otra línea que aparece en la dmesgsalida, justo antes del retraso de 30 segundos antes mencionado:

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

EDITAR 2:

systemd-analyze blamelos resultados están aquí

Mientras tanto, después de varios reinicios, las dmesglíneas que culpé anteriormente cambiaron sus tiempos de esta manera:

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Haré un par de reinicios para averiguar si esto cambia aleatoriamente o si permanece igual (el bloque de código en la primera edición es desde el primer arranque después de insertar el HDD adicional).

EDITAR 2.5: random: crng init donegeneralmente aparece en los tiempos que se muestran en la edición 1, rara vez como en la edición 2. Parece ser ... aleatorio.


¿Puedes ejecutar systemd-analyze blamey editar tu pregunta para incluir la salida de este comando?
vidarlo

Lo ejecuté antes y la suma de los resultados fue inferior a 8-9 segundos, así que pensé que sería irrelevante. He añadido los resultados.
Jes Wanson el

Respuestas:


17

Tuve el mismo problema Durante los mensajes de arranque, diría que se agotó el tiempo de espera para reanudar el dispositivo. Compruebe /etc/initramfs-tools/conf.d/resumesi hay UUID en él, como RESUME=some-uuideliminar uuid y reemplazar con "ninguno" RESUME=none. Después de esa carrera sudo update-initramfs -uk ally debería ser bueno ir.


2
¡Finalmente! Esto resolvió un problema que he estado investigando durante incontables horas: ahora redujo a la mitad el tiempo de arranque. Información útil sobre de qué se trata este currículum: askubuntu.com/questions/1057556/…
Casperrw

1
Esto parece funcionar para mí también, obtuve unos 38 segundos de arranque antes de esto y 8 segundos después.
Pablo Pazos

El problema apareció para mí después de la actualización de la distribución de 16.04 a 18.04, y este método también elimina el retraso de 30 segundos.
Bonlenfum

5

He tenido este problema varias veces, y mi solución funciona en todas las situaciones.

Al ejecutar dsmeg, el error aparece como:

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

La solución es:

Primero compare su fstab y blkid:

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"



$ sudo nano /etc/fstab


# /etc/fstab: static file system information
#
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

Como puede ver, mi intercambio en / dev / sda7 tiene un UUID diferente en fstab que en blkid. Esto fue, en mi caso, causado por otra instalación de Linux repartitoning el intercambio y causando que el UUID cambie. El retraso del arranque es causado por el sistema que intenta encontrar el nuevo UUID del intercambio. Para solucionarlo, simplemente copie el UUID en blkid que no coincida con el archivo fstab y luego guárdelo.

Si después de reiniciar el error de arranque sigue ahí, necesita editar adicionalmente su archivo initramfs.conf.

Haz esto por:

$ sudo nano  /etc/initramfs-tools/conf.d/resume

Luego, ya sea creando un nuevo archivo o editando el archivo de currículum actual, escriba en la primera línea RESUME = UUID = << UUID of swap >>

Por ejemplo, el mío parece

RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59

Luego ejecute el siguiente comando para actualizar su archivo initramfs.

#sudo update-initramfs -u

Luego reinicie. El error se habrá ido.


1

Experimenté un aumento similar en los tiempos de arranque, y después de investigar dmesgy systemd-analyze blameel culpable parecía serrandom: crng init

El problema parece no ser suficiente entropía al arrancar desde el SSD para la inicialización. Esta hipótesis parece confirmarse porque mover el mouse un montón durante el arranque disminuye el tiempo de arranque de alrededor de 2 minutos hacia abajo para acercarse a lo que era antes.


1

En el arranque, el kernel espera los movimientos del mouse para inicializar el generador de números aleatorios. Mensajes del kernel en el arranque:
sudo dmesg | less

El problema:
kernel: random: crng init done

La solución:
sudo apt install haveged
sudo systemctl enable haveged


0

Tuve ese problema con el tiempo de arranque lento en ubuntu 19.04 después de quitar la partición de intercambio y hacer el archivo de intercambio.

La salida de dmesg

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

No hay archivos de intercambio en / etc / fstab. Todos los discos / uuids montados fueron correctos.

Lo comprobé /etc/initramfs-tools/conf.d/resumepero faltaba ese archivo.

Acabo de correr

sudo update-initramfs -uk all

Y ahora arranca muy rápido.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.