linux mint 19 tara - Apagar sistema¿? [solucionado]

[mintxavi]

Buenos días tardes o noches ...felices sueños para estos últimos...
Como siempre felicidades por los grandes tutoriales que hacéis, quisiera consultaros si a alguno de vosotros os ocurre que al apagar mint 19 "tara", se quede en la pantalla de apagado (logo de mint) y no acabe de terminar el apagado.
Lo extraño que he observado es que ocurre con todas las nuevas versiones, es decir , cinnamon, mate y xfce de mint tara, (incluso habiendo actualizado desde mint18)pero me ocurre lo mismo con xubuntu bionic o Mx horizon, pero no ocurre con linux mint 18.3 silvia.
No puedo proporcionar informacion porque ya lo quite y puse de nuevo el mint 18.3...como un reloj funciona este, no entiendo que pueden haber cambiado en las nuevas versiones de las distros que afecte a todas por igual. Descartado los kernels( fue lo 1º que probe)

Saludos a todos y que paseis buen dia...Que tal el canal wibo?...todo bien?

[JOPETA]

La verdad es que cuando yo actualicé si se demoró el apagado bastante. Cuando me cansé de esperar me dispuse a a forzar el apagado pero fué tocar el teclado y se apagó el solito. En mi caso creo que fué debido a que no era capaz de desmontar no se que temp que se monta no se donde durante la actualización. Luego no tuve ese problema en los apagados posteriores.

Por lo general el sospecho de este tipo de relentizaciones al inciar o apagar suele la incapacidad de acceder a alguna partición como la swap o de finalizar un servicio/proceso. Si inicias sin los parámetros quite splash en la carga del kernel (mira aquí si no sabes como editar al opción del menu GRUB para hacerlo, pero sólo eliminando quite splash, nada de introducir otras cosas) verás los problemas de la carga y cierre del sistema. Así se puede proporcionar generalmente la información del cierre donde se estanca sin tener que recurrir a analizar el dmesg.

Por otro lado, echan muchas pestes del kernel 4.15.0.23 que se instala, pero en mi caso yo partía en la actualización de LM 18.3 con el kernel 4.15.0.24 y tal vez por ello no sufrí este percance de forma tan severa. ¿Con que kernel partiste al actualizar?

Si no tienes alguno anterior de la serie 4.15, instala por ejemplo el 4.15.0.22 de forma gráfica y prueba con él.

La decisión del volver a LM 18.3 me parece apropiada, ya que un nuevo lanzamiento requiere de tiempo para poder ir madurando lo suficente para evitar algunos problemas conocidos o que surjan con un uso normal. Como se deja claro en los tutoriales de actualización si tu sistema actual tiene soporte y funciona bien para qué las prisas.

(Editado)

[hatteras]

Mira a ver si creando un lanzador en el escritorio, con su icono correspondiente, con el siguiente comando, puedes apagar el pc haciendo doble clic sobre el lanzador:
dbus-send --system --print-reply --system --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop

A mi, con Mint Cinnamon 17.3 me funciona perfectamente, para que mi familia vea perfectamente desde donde se apaga el pc.

[mintxavi]

buenos dias jopeta(felices fiestas), buenas tardes hatteras(por si estas a turnos)

Te cuento jopeta, resumiendo para no hacer una pelicula:

1ºActualizando de mint18 silvia a mint19 tara, conservando kernel anterior 4.4 >>>falla apagado.
2ºInstalacion limpia de mint tara, kernel 4.15 >>> falla apagado ( cualquier escritorio)
3ºinstalacion de un Xubuntu bionic >>> mismo resultado
4ºMX horizon(debian kernel 4.15) >>> igual resultado
5ºMaquina virtual de tara en virtualbox >>> No se reproduce el fallo de apagado.

Podria una particion encriptada(no es de sistema ni de home) provocar el fallo en tara pero no en silvia?, cambiaron algo referente a discos? o tal vez otro disco en el que tengo manjaro?, no se me ocurre que pueda ser, pero en silvia funciona todo genial, por eso pienso en algo que cambiaron y que afecta a todos los debian nuevos por decirlo de esa manera.

Hatteras ya no lo tengo instalado el tara y no sirve probar el invento que me dijiste pero gracias
los muñequinos los pongo pa animar el posts y que no quede triston...chau

Feliz domingo chicos, y jopeta cuidado con la fiestuqui, saludos a todos y puxa linux!

[JOPETA]

..resumiendo para no hacer una pelicula:..

Resuminedo más aún para no hacer ni un "corto"

1º) El cambio de 4.4. a 4.15 es muy drástico, como digo harías bien en probar el cambio de kernel en LM 18.3 antes de actulizar,...pero espera unos dias para esto último.
2º)-4º) Puede que tengas problemas con ese kernel para tu BIOS o algún componente específico del Hardware, pero habría que entrar en detalles una vez instalado.
5º) Por razones obvias, la propia virtualización suprime la causa de los problemas anteriores.

Podria una particion encriptada(no es de sistema ni de home) provocar el fallo en tara pero no en silvia?, cambiaron algo referente a discos? o tal vez otro disco en el que tengo manjaro?, no se me ocurre que pueda ser, pero en silvia funciona todo genial, por eso pienso en algo que cambiaron y que afecta a todos los debian nuevos por decirlo de esa manera.

Si, sobre todos si haces automontaje al inicio, o bien al trajabajar con la partición encriptada que algún servicio o proceso siga funcionando e impida cerrar...pero sin poder recabar datos es como el que tiene tos y se resca... Si, muchas cosas han cambiado desde el propio GRUB al systemd, pasando obviamente por los cambios en el kernel, controladores, firmware,..

buenos dias jopeta(felices fiestas)...Feliz domingo chicos, y jopeta cuidado con la fiestuqui,

Igualmete. Si no fuera por lo mal que llevo lo del ruidaco nocturno (ayer hasta pasadas las tres de la madrugada sin poder pegar ojo)

[mintxavi]

Buenos dias a todos de nuevo...


En el mintUpdate de mint19 tara, solo se muestra el kernel LTs 4.15...Que puedo hacer para que se muestren los kernels anteriores, en especial el 4.4.?
Sin utilizar Ukuu



bueno, saludos a todos y feliz dia

[JOPETA]

Ten en cuenta que el nuevo sistema al que has actualizado se nuclea entorno al nuevo kernel LTS (en este caso el 4.15). Tampoco en el GRUB se deben mostrar mas opciones aunque hayas actualizado desde LM 18.3 y no se muestran porque realmente no han sido nunca instalados otros kernels en el nuevo sistema.

De conservarse los antiguos kernel/imágenes en el directorio /boot se corresponden con el sistema LM 18.3 y serán usadas para la restauración de las instantáneas que hayas realizado antes de actualizar.

Tratar de instalar un kernel anterior al LTS por otra parte se me antoja una tarea si no imposible muy difícil (para que tuviera un mínimo éxito habría que compilarlo desde las fuentes y por desgracia los compiladores del nuevo sistema también son de versiones diferentes).

El desarrollo del kernel es un desarrollo incremental y si te fijas en el propio acrónimo UKUU (cuya instalación no te recomiendo) significa Ubuntu Kernel Upgrade Utility, no downgrade La idea es proporcionar al nuevo hardware el ultimo kernel disponible en el mainline de Ubuntu no a la inversa.

Si tienes que probar un kernel anterior al LTS de la nueva edición mejor harías en permanecer con LM 18.3 y como te digo en el post anterior probar como se comporta con ese nuevo kernel (para LM 18.3 el nuevo kernel 4.15 es un kernel HWE) que instalado de la forma recomendad no ofrece mayores dificultades y es perfectamente reversible.

Si el fallo de no apagarse el sistema fuera debido a problemas específicos del kernel (como una regresión ya que con el kernel que instala LM 18.3, a pesar de la falta de soporte te funciona) tarde o temprano será parcheado el kernel LTS de forma conveniente.

Mientras permanece con un kernel/edición y trata de encontrar la solución a ese problema..Proporciona la información sobre tu sistema de la forma solicitada (no hay ningún dato sensible en ese listado de inxi -Fxznr) ya que los posibles culpables pueden ser varios (desde la conexión de red, pasando por el controlador de la gráfica, la configuración de la BIOS, ..... Tantos culpables como posibles soluciones y no todas dependen del kernel instalado.

Haz también lo recomendado sobre quiet splash para ver la consola al apagar o ejecutando los códigos de apagado en la terminal sudo shutdown -h now y viendo el proceso que impide el pagado.

[mintxavi]

buenas noches jopeta

No hay problema, sigo en mint18 syilvia, pero gracias a tu respuesta ya me quedo muy clara la situacion del downgrade...simplemente queria saber si se podia ir al otro kernel en la "tara" virtual(que mal suena esto)...como decia tamara...no cambié no cambieee no cambieeeeee

Espero que tara 19.1 si sea lo buena que se merece...mas que nada por que ya no será "tara"

Que paseis muy buena noche alla y gracias por la respuesta...chau

pd: el ukuu no lo he querido nunca y el kernel 4.15 de lo peor que he visto...al ponerlo aqui en silvia tambien hizo lo mismo del apagado, sigo en el 4.4(el 4.13 desde q lei aquello de las bios de lenovo tampoco lo quiero)

[JOPETA]

Aunque no fué tan sonado, a mi que me gusta trapichear con lo nuevos kernels en la edición anterior antes de cambiar, con el kernel LTS de Ubuntu xenial pasó lo mismo. Depués de instalar las primeras versiones disponibles del 4.4 en LM !7.3 y coincidiendo con el lanzamiento de LM 18 las siguientes versiones del kernel 4.4. fueron una caca (creo que lo comenté en un post por entonces y me parece recordar que el kernel del crack entonces fué la versión #20). Tuvieron que pasar varias versiones del 4.4. LTS hasta que volvió a funcionar igual o parecido que con las primeras de la fase HWE.

Entonces no había esta movida del spectre y meltdown ( o mejor dicho no se había hecho pública) y yo pude seguir iniciando con mis anteriores versiones del 4.4. aunque Ubuntu las hiciera desparecer. Intente lo mismo con LM 18.3 y como las versiones HWE del 4.15 que tenía instaladas, incluyendo el 4.15.0-24 iban bien, me decidí a actualizar por aquello de comprobar el Tutorial y nada que ver el comporatimiento del PC 4.15.0-24 de la HWE con el 4.15.0-24 de la LTS.

Luego aprendí que aunque las numeraciones del kernel de Ubuntu sean correlativas entre el HWE y el LTS tienen diferente base o kernel del mainline en el que se basan (este es del kernel.org , no está aún retocado por Ubuntu/canonical y es conocido como vanilla) de ahí el comportamiento tan desigual. Ya han desaparecido del HWE de xenial los primeros 4.15 que estaban basados en el 4.15.16 creo y sólo parecen los mas recientes (4.15.0.23 y 24) basados en 4.15.18 al igual que los del LTS de Ubuntu bionic.

Evidentemente entonces ni me plantee cambiar de edición, ahora tampoco debería haberlo hecho.

[mintxavi]

buenos dias,tardes y noches


bueno ahora si que lo cambie ya....y creo que lo comentaste atras jopeta...el automontaje de la unidad donde tengo manjaro, ese era el problema...todo bien ahora
lo desactive desde la herramienta de discos.


muchisimas gracias

[JOPETA]

Muchísimas de nadas.

Por favor, edita tu primer post (cic en el icono del lápiz) y añade [solucionado] al título.