SOLUCIONADO Fallo actualizacion kernel 151-157 Linux Mint 19.2 Cinnamon 64 bits

[Manuel70]

Buenas tardes,

Tengo una HP 255 G7 con procesador AMD Radeon.Hoy he actualizado al último kernel correspondiente al Mint 19.2, el que acaba en -157.Lo he hecho con un cable de red 5E para que la descarga de la actualización fuera óptima.

Aparentemente así fue, me pide reiniciar, lo hago, y cargando sistema antes de llegar a la pantalla de contraseña se queda en negro, con el cursor inmóvil y de ahí no pasa... El teclado ni responde, ni siquiera se enciende la luz de BloqMayús.

Me voy a la tienda de un amigo informático que sabe un poco más que yo, y milagro! Arranca, carga, ahora sí reiniciamos correspondiente, apagamos, volvemos a encender y todo ok.

Regreso a casa, enciendo, pantalla negra ANTES de llegar a la de contraseña, teclado y ratón no responden, y me sale lo que veis en la imagen:

Lo escribo porque pesa demasiado...

SYSTEM JOURNALD (340) FAILED TO WRITE (21... 457 BYTES IGNORING: READ-ONLY FILE SYSTEM
El resto de líneas son del estilo y llenan toda la pantalla.

[Manuel70]

He seguido intentándolo y después de reparar 7 archivos desde la consola con fsck /dev/sda2 le he dado exit y he entrado a la pantalla de carga del sistema, y de ahí a la de contraseña, todo bien, he probado a navegar, moverme por las carpetas, abrir archivos, y al fin, cuando todo parecía resuelto (los siete archivos reparados desde la consola) reinicio, llego una vez más a la pantalla de contraseña... Y el teclado otra vez dejó de funcionar! y no pude meter la contraseña, sólo el primer carácter.

En fin... He podido cargar la foto de como quedó tras la operación de reparación de los archivos corruptos.
Y si no queda otra pues tendré que recuperar la última instantánea del sistema, que posiblemente fuera de ayer martes, y mandar la p...a actualización del kernel a la lista negra

Muchas gracias por la ayuda que me podáis ofrecer para solucionar esta situación.

[tomeu]

Algunas veces (pocas afortunadamente) he sufrido fallos del teclado que coinciden con actualizaciones del kernel. "Curiosamente" nunca en el portátil ni si el teclado es con cable. Es más, recientemente ha vuelto a ocurrir. El primer impulso es dar un puñetazo al teclado, pero no está recomendada esa hipotética solución.

Lo que por lo general lo soluciona (diremos el 99% de la veces, para no ser demasiado exagerado) es cambiar de ranura usb el conector del teclado (en mi caso como de ratón-teclado)

Otra solución que puedes probar es que, cuando salga el grub, te vas a opciones avanzadas y arrancas con el kernel anterior y comprueba si efectivamente es por el cambio de kernel.

De todas maneras por la foto que pones no parece un simple fallo de conexión del teclado... o dicho de otra manera parece que tienes más errores.

[Jo-con-Ël]

Por desgracia esa actualizacion del kernel tampoco le ha sentado muy bien a mi portatil (los de Ubuntu a veces tienen estas gracias).

Nunca antes me habia sucedido que al instalarla el sistema se metiera en 70ºC (ventiladores a tope) y que la CPU estuviera tanto tiempo al 100 %. De la misma menera nunca tras instalar una nueva versión del kernel me fué preciso hacer un chequeo del sistema de archivos de la partición que es lo que te ha ocurrido también a tí. En general nunca tuve nada que no se solucionara con un reincio o sólo en raras ocasiones con la reinstalación de los controladores de la Nvidia .

Yo intenté iniciar con el kernel anterior desde las opciones avanzadas del Menu GRUB pero tuve el mismo problema con el sistema de archivos y decidí iniciar con otro sistema que tengo instalado para hacer el chequeo del sistema de archivos de la partición. Quizás tengas que hacerlo desde un Live para asegurar (desde la terminal con sudo fsck -y /dev/sdxy reemplazando sdxy por lo que proceda para tu partión raíz según el resultado de sudo fdisk -l.

Al iniciar con el kernel nuevo parece que no se instaló de forma correcta y/o los cambios que introduce, dependiendo para que hadware, no le sienta bien. En mi caso inicio por defeto con la integrada intel y tambien tuve iguales resultados en lo referente al congelamiento del cursor al inicio, no cargar el escritorio, no pude ni abrir otra sesión gráfica desde una sesión de texto (Alt+Ctrl+F1 o F2 y tras logearte con startx). Esta vez tocó apagar de botón y tener que volver a chequear el sistema de archivos (aunque estaba limpio).

Si puedes iniciar desde un kernel anterior desde la Opciones Avanzadas del menu grub hazlo mientras decides que hacer antes de recurrir a Timeshift. Tampoco sería necesario en este caso ya que puedes iniciar con el anterior y desinstalar el 151 opcionalmente (desde el Gestor de Actualizaciones >Ver>Kernel de Linux) si quieres no pasar por el menú en cada inicio para ello.

Yo voy a probar a desahacer los cambios desde el gestor de paquetes Synaptic previa consulla del histórico (Archivo> histórico). En mi caso el paquete de actualizaciones instaladas (uso el kernel lowlatency) fué el que se muestra a continuación auque también recuerdo haber actualizado el controlador de la Nvidia y algo más pero no si reincié después (un mal dia lo tiene cualquiera).

Actualizó los siguientes paquetes:
google-chrome-stable (91.0.4472.164-1) to 92.0.4515.107-1
initramfs-tools (0.130ubuntu3.12) to 0.130ubuntu3.13
initramfs-tools-bin (0.130ubuntu3.12) to 0.130ubuntu3.13
initramfs-tools-core (0.130ubuntu3.12) to 0.130ubuntu3.13
linux-generic (4.15.0.147.134) to 4.15.0.151.139
linux-headers-generic (4.15.0.147.134) to 4.15.0.151.139
linux-headers-lowlatency (4.15.0.147.134) to 4.15.0.151.139
linux-image-generic (4.15.0.147.134) to 4.15.0.151.139
linux-image-lowlatency (4.15.0.147.134) to 4.15.0.151.139
linux-libc-dev (4.15.0-147.151) to 4.15.0-151.157
linux-lowlatency (4.15.0.147.134) to 4.15.0.151.139
linux-tools-common (4.15.0-147.151) to 4.15.0-151.157
linux-tools-lowlatency (4.15.0.147.134) to 4.15.0.151.139

Instaló los siguientes paquetes:
linux-headers-4.15.0-151 (4.15.0-151.157)
linux-headers-4.15.0-151-generic (4.15.0-151.157)
linux-headers-4.15.0-151-lowlatency (4.15.0-151.157)
linux-image-4.15.0-151-generic (4.15.0-151.157)
linux-image-4.15.0-151-lowlatency (4.15.0-151.157)
linux-modules-4.15.0-151-generic (4.15.0-151.157)
linux-modules-4.15.0-151-lowlatency (4.15.0-151.157)
linux-modules-extra-4.15.0-151-generic (4.15.0-151.157)
linux-tools-4.15.0-151 (4.15.0-151.157)
linux-tools-4.15.0-151-lowlatency (4.15.0-151.157)

Cuando lo haga esta tarde ya os contaré. Tu teniendo una instantánea reciente lo tienes fácil....úsala.

[Jo-con-Ël]

He iniciado con el kernel anterior 4.15.0-147 (el pobre no sabía con qué gráfica iniciaba) y desinstalado completamente el 4-15-0-151.

En mi caso también he tenido que reinstalar los controladodres de la Nvidia ya que el intercambio de gráfica se habia ido al garate es decir purgar la nvidia, reinstalar el controlador semiprivativo Nvidia (la nueva versión del 390) el bumblebee+bbswtch que es lo que mejor se adapta a mi viejo portátil,.. y resolver el problema del nvidia-prime que aún está ahí dando la lata

He vuelto a tener el portátil "casi" como lo tenia antes de la actulización. Lo digo porque el uso del sudo prime-select para iniciar con la nvidia o la intel por defecto lleva ahora una tardanza no habitual, de hecho antes no creo haber visto que el initramfs tuviera que hacer algo en esto y ahora se lleva unos segundos haciendo cambios en la carga de módulos...

Me pregunto si el responsable del incidente no tuviera que ver mas con la actualización de initramfs que con el kernel en si mismo...Lo cierto es que no recuerdo si esa actualización del intiramfs fué un dependencia o una actulización a parte. Si fue lo último fué un temeridad por mi parte actualizarlas a la vez. El caso es que no veo a nadie mas quejándose de la actualización del kernel por ahora..

Cuando tenga otro ratito volveré a la versión anterior del initramfs (aunque la reemplazada que parece ahí no es ofrecida como versión) y/o instalar el 4.15.0-151 para confirmarlo o instalaré el nuevo kernel 4.15 (lo que llegue antes).

[Manuel70]

Buenas tardes,

Bueno, he entrado desde el menú del GRUB con Opciones Avanzadas y he iniciado sesión con el Kernel 147, que es el que iba perfectamente. Todo bien, teclado, carpetas, audios, videos y navegación por internet.

Después directo a Time Shift y efectivamente la última instantánea era del martes, de antes de actualizar el Kernel. Restauro, se toma unos minutos para recolocarlo todo, sigo las instrucciones -nunca había hecho una restauración en Linux en los cuatro años que llevo utilizándolo- y todo OK.

Después de ver que todo iba como hasta ayer antes de actualizar, reinicio y sin ningún problema carga sistema y nueva sesión; también todo ok a la hora de suspender equipo y volver a la sesión.

Actualizo unas aplicaciones y aprovecho para enviar al cuarto oscuro al nuevo Kernel, y descarto futuras actualizaciones mientras siga trabajando bien con el actual.

Mientras en Canonical no sepan hacer bien su trabajo, yo no voy a hacer de conejillo de indias con sus actualizaciones de Kernel . Parece que los desarrolladores olvidan con frecuencia que su trabajo es facilitar el trabajo de quienes utilizamos sus aplicaciones, y si quieren que experimentemos con nuestros equipos particulares, de los que depende nuestro trabajo, para checkar su trabajo que nos ingresen entonces sus nóminas en nuestra cuenta bancaria.

¡Se acabo actualizar kernels por que sí!

Muchas gracias tomeu y Jo-con-Ël por vuestra ayuda.

Un saludo a todos.

[Jo-con-Ël]

Actualización 28-7-2021: He tenido un comportamiento irregular del sistema desde la instalación del kernel del mainline iniciando con él aunque ningún cuelque al inicio....hasta hoy. Mejor no instalar tampoco el del mainline por eso retiro todo lo comentando aquí al respecto ya que si va a ser de la instalacion y uso de ese kernel. Los que lo hayan instalado que al menos no inicien con él hasta que no se solucione con el próximo 4.15.0-153. Como digo aquí, ya está en pruebas..
-------------------------------------------

[Popopo]

Buenas,
Mi versión del gestor es diferente y no tengo una traza temporal como la que tienes mostrada en las capturas.

[Jo-con-Ël]

Esa traza temporal es el histórico del gestor de paquetes Synaptic que abro una vez efectúo la instalación (Menu>Administración>Gestor de paquetes Synaptic> y luego arriba en Archivo>Históŕico).

Puedes ver el registro en /var/log/apt/history.log ( por ejemplo con cat /var/log/apt/history.log en la terminal) y la respuesta que recibiste en la terminal cuando se instalaban en /var/log/apt/term.log, anque son registros activos y muy extensos.

Esto no tiene que ver con el proceso, sólo era para documentar que realmente se han instalado y qué paquetes.

[tomeu]

He seguido con mis pesquisas sobre este asunto y he procedido a instalar el kernel esta vez no el proporcionado directamente por Ubuntu a través de las actualizaciones, sino el del mainline disponible a través Gestor de Actualizaciones>Ver>Kernel de Linux>...

Yo desde que empecé con L.Mint siempre lo he hecho así. Hice caso a un tal Wibol y la cosa ha seguido funcionando.

Sin embargo, desde los cambios introducidos con LMint 20 (sinceramente no recuerdo si fue con una versión de L.Mint 19.?) tras actualizar el kernel de esa manera luego sigue apareciendo el aviso de actualización de kernel del gestor de actualizaciones, aunque ya es de diferente tamaño (menor)

[Jo-con-Ël]

Sin embargo, desde los cambios introducidos con LMint 20 (sinceramente no recuerdo si fue con una versión de L.Mint 19.?) tras actualizar el kernel de esa manera luego sigue apareciendo el aviso de actualización de kernel del gestor de actualizaciones, aunque ya es de diferente tamaño (menor)

Como digo en el Gestor de Actualizaciones se sigue recibiendo la actualzación del kernel recien instalado desde el mainline ya que deben realizarse cambios menores en el sistema y/o que el paquete "linux" de Ubuntu instala otros que aún deben actualizarse (linux-image-generic y headers que depedenden de la última versión del kernel instalado).

También en LM 19.X (imagen anterior), anteriormente el LM 18,X,...Quizás no lo recordarás o tenias configurado el Gestor de Actualizaiones para que no te mostrara las actualizacones del kernel (no recomendable aunque antes de la publicacion de las vulneralidades de las CPU esto no era tan acuciante).

[Popopo]

Hola,
prosigo con el mismo problema, veo que nos pasa a varios.
En mi caso únicamente instalo los Kernels que me vienen a través del gestor de actualizaciones de LM, luego no pillo como ver si es de Ubuntu o de una actualización de los propios creadores del sistema LM. ¿cómo saberlo?
Saludos

[Jo-con-Ël]

Descarta a LM de este asunto. Tanto el kernel oficial (del Gestor de Actualizaciones) como el del mainline (Ver>kernel/Nucleo de Linux...) proceden de los repositorios de Ubuntu.

El proceso de instalacion echa mano de dpkg y apt por lo que tampoco sería eso, quedarían descartadoas al no recibirl ningun error o fallo durante la instalalación y. Si eres de los que se fijan en esas cosas toca mirar el registro del sistema (/var/log/apt/history. log y tem.log así como /var/log/dkpg.log). Caulquier problema en la instalación de paquetes quedarían refejados en esos registros o en el aviso del fallo.

En cualquier caso este hilo trata de un problema muy concreto de LM 19.X asociado a una actualización muy concreta la del kelnel 4.15.0-151. Tal vez la lentitud de la conexión con el repositorio oficial de ubuntu... o la lentitud de los procesos de compresión/descompresion de las imagenes que pudieran fragamentar la imagen...quien sabe en este caso.

Tu caso sería distinto, te ocurre al actualizar cualquier kernel y en LM 20.X. A ninguno de los afectados que yo sepa les sale la advertencia/alerta sobre no encontrar la partición raiz como resultado del exit en la shell intiramfs.

Además aún no has segudo la propuesta de actualizar el kernel desde el mainline, que fué el motivo por el que te remitía a la lectuara de este hilo desde el otro.

[Jo-con-Ël]

Poco a poco se van sumando afectados por problemas con la actualización de ese kernel (ver aqui o aquí por ejemplo) y ya se han comunicado bugs como recoge karlchen en el primer enlace.

En uno de ellos se mencionan que ya han desarrollado un kernel 4.15.0-153 de pruebas por si alguien está interesado en probarlo antes de que salga el oficial. La forma de instalarlo es mediante descarga de los tres paquetes y luego en el directorio de descargar abrir una terminal y ejecutar sudo dpkg -i *.deb. Como dice el desarrollador el Secure Boot debe estar desactivado al ser un kernel no firmado.

[Jo-con-Ël]

Hoy ya estaba disponible el kernel 4.15.0-153 en el Gestor de actualizaciones. Instalada, reiniciado y sin problemas por ahora.

Nota: Esas actualizaciones recibidas no parcen que instalen un verdadero kernel, si ya desinstalaste el kernel problemátco y lo tienes en a lista negra mejor comprobarlo con uname -a.

También teneis disponible el kernel 4.15.0-153 desde el mainline (Ver>kernel de Linux,..) por si quereis probarlo tal cual.

[Popopo]

Hola a todos,

He actualizado el kernel a la versión 5.14 y por ahora el sistema parece estable, estoy probando un par de días a ver si de paso también desaparecen los cuelgues. Los errores ACPI siguen ahí, pero el sistema parece estable por lo demás.

Aunque el Kernel 5.14 todavía no está "en línea" desde el mint-update, se puede instalar de manera sencilla. Si alguno está experimentando problemas diversos debo decir que el LM20.2 parece trabajar por ahora bastante bien con este nuevo Kernel 5.14.
Saludos

[Jo-con-Ël]

Me alegra que hayas entrado en razones con lo de probar con kernels mas actuales, pero este hilo era para el seguimiento del problema de algunos usuarios LM 19.X con la actualización del kernel 4.15.0-151 que quedaría definitivamnte zanjado con la actualizacion al kernel 4.15.0-153.

Dudo que a los que siguen/seguimos con esta edición (Linux Mint 19.X) por definición equipos de una cierta edad, nos de por probar esos kernel ni aún estando disponibles, que no lo están, en Ver>Kernel de Linux (el útimo kernel es el 5.4 y así seguirá ya hasta el final del soporte de LM 19/Ubuntu bionic).