Mostrando las entradas con la etiqueta error. Mostrar todas las entradas
Mostrando las entradas con la etiqueta error. Mostrar todas las entradas

viernes, 27 de octubre de 2017

Equipo apagado a mitad de actualización


Como  de costumbre, me gusta estar buscando actualizaciones de paquetes todos los días, es un de los comandos que suelo ejecutar en cuando conecto el equipo a internet.

Esta ocasión no fue diferente, ejecuté mi alias "actualizar" y comenzó la actualización, había un listado de paquetes, kernel, gnutls, fontconfig, glibc, entre otros. Pero el más importante, el kernel. Salí por unos minutos por café, y cuando regresé mi laptop estaba apagada.

Y ahora qué cara$%&/()(/&%$#p, y gran cantidad de cosas que dije por eso. Qué fue lo que pasó, la noche anterior había dejado la laptop con poca carga y eso ocasionó que se descargará pronto.

El gestor de paquetes (dnf actualmente) de fedora, tiene una seriae de proceso por cada actualización, que son la comprobación, descarga, ejecución y eliminación/limpieza de los paquetes obsoletos, en caso de las versiones de kernel, se elimina una cada 4 versiones, para dejar siempre 3.


El caso es que el proceso de actualización en mi laptop, se quedó en la etapa de ejecución, y no terminó correctamente la limpieza de los paquetes de versiones previas, y esto ocasionó que hubiera dos versiones instaladas del mismo paquete, provocando esto la imposibilidad de actualizar o instalar cualquier otro paquete que dependiera de los librerías de los mimos paquetes.

Lo peor de esto, fue que el kernel no se cargó al grub, por lo que en la entrada del grub no fue actualizado. En este tipo de circunstancias es en las que uno quisiera gritar de desesperación al no saber qué raios hacer.

Afortunadamente, la versión del kernel previo funcionaba correctamente, por lo tanto sí pude entrar al SO.

Al iniciar, recompilé las base de datos de rpms, eliminar los paquetes en caché, limpiar las transacciones, pero nada. El problema era que incluso al eliminar el paquete en conflicto, no funcionaba.

Ahora, si eliminaba el paquete completo, se eliminaría más de la mitad del SO, y obviamente eso no era buena idea.

Y qué hice, bueno, con la herramienta de yumex, pude listar los paquetes, y efectivamente, ahí estaban listadas ambas versiones de los mimos paquetes que estaban causando los conflictos.


Entonces, por cada paquete en conflicto, desinstalé uno, la versión más baja de la lista, es la que se debe desinstalar. E hice eso con cada paquete en conflicto.

Una vez completado, actualicé y perfecto todo. Espero y esto sea de utilidad suponiendo que les pase algo similar, alguna de las fuentes que revisé son las siguientes.

martes, 18 de octubre de 2016

Error: Unsafe state al acceder a partición de Windows desde Linux


Con la llegada de Windows 8, 8.1 y 10, vino el famoso inicio rápido o instantáneo de Windows. Y para lograr esta función pues realmente no apagan todo el equipo de manera completa, dejando como suspendido algunas opciones del SO. Una de esas era dejar el disco duro en modo de Suspendido, lo cual hacía que iniciar una tanto más rápido el SO.

Si solo se tiene Windows en el equipo, esto no es mayor problema, pero si se tiene que acceder a la partición de Windows desde un SO linux, ahí se entra en un problema. Ya que como el disco está hibernado por así decirlo, Linux no es capaz de montar dicha partición.

Al no poder montar la partición de Windows, muestra el siguiente Error:
Quizá se pregunten como ¿Para qué es necesario acceder a una partición de Windows si se tiene instalado Linux?

Pueden haber varias razones, una de ellas es porque se tienen dos SO instalados en el equipo, un Linux y Windows, y resulta que se quiere un archivo que está en la partición de Windows.

Otra posibilidad puede ser que: un equipo con Windows perdió el inicio y no es posible repararlo y la única manera es formatear para reinstalar el SO. Pero con un LIVE CD de Linux, es posible recuperar los archivos.

En fin muchas posibles causas, para solucionar esto es sencillo, suponiendo que es posible iniciar en el SO de Windows de manera normal y acceder a la herramienta de Línea de comando (CMD).

Iniciar CMD con privilegios de administrador:


Una vez iniciada, se teclea la siguiente instrucción y se presiona enter.

powercfg -h off


Reiniciar el equipo y con eso ya es posible acceder a las particiones de Windows desde cualquier SO Linux.

jueves, 21 de julio de 2016

Solución Definitiva al error del Touchpad en Fedora 24


En mi post https://linuxgx.blogspot.mx/2016/07/solucion-al-error-del-touchpad-en.html propuse una solución que encontré en la red para el problema que no mostraba la configuración del touchpad en Fedora 24 (ver imagen 2), después de a ver realizado la actualización por internet o incluso haciendo una instalación limpia.
Imagen 2.- No muestra configuración de touchpad

AL parecer no a todos les pasó esto, sin embargo, sé que no fui el único, ya que varios foros también encontré que tenía el mismo problema.

Como ya mencioné la solución temporal la había descrito en mi post anterior, pero en  los comentarios de dicho post, alguién me dió el siguiente link, http://linux-unix-open-source.1053819.n5.nabble.com/f24-touchpad-quot-Tap-to-click-quot-amp-C-configuration-td5899516.html, en el cual explica que el controlador de synpatic es obsoleto, por lo tanto recomiendan eliminarlo y eliminar la configuración manual que se tenga utilizando dicho controlador:

Por lo tanto entonces, se procede a realizar lo siguiente:
sudo rm /etc/X11/xorg.conf.d/taptouch.conf

Desinstalar xorg-x11-drv-synaptics:
sudo dnf remove xorg-x11-drv-synaptics

Instalar xorg-x11-drv-libimput en caso de no contar con él:
sudo dnf install xorg-x11-drv-libinput

Reiniciar el equipo y listo:


Gracias al usuario que me dió el link.
Fuente:
http://linux-unix-open-source.1053819.n5.nabble.com/f24-touchpad-quot-Tap-to-click-quot-amp-C-configuration-td5899516.html

lunes, 18 de julio de 2016

Solución al error del Touchpad en Fedora 24



Las actualizaciones de SO traen actualizaciones excelentes, otras simplemente escapa de nuestra compresión cómo puede ser posible que consideren utilizar dos teclas como retroceso en lugar de solo una, en fin.

En Fedora 24 me topé con la sorpresa que había cambiado la configuración del touchpad, la imagen de arriba muestra cómo debería verse en Gnome 3.20, pero para mi mayor impresión, resulta que la sección del touchpad en mi laptop, no estaba.

La imagen de abajo, muestra cómo se visualiza el panel de configuración del touchpad en mi latop. Y como resultado no funcionaba el tap, lo peor es que no había forma de activarlo, pues simplemente no estaba dicha opción.



Después de hacer unos berrinches por eso, pues dije, quizá sea por haber actualizado de 23 a 24 y no una instalación fresca, pero qué creen, resulta que no era así. Después de formatear y reinstalar desde cero, dicha configuración tampoco funcionó.

Intenté con dconf editor, ya saben que es poderoso para entrara  a las configuraciones del sistema, pero nada, ahí sí estaba activado el tap para el touchpad, pero ni así.

La única solución que he encontrado hasta ahora, es agregar un archivo de configuración para el touchpad en la ruta /etc/X11/xorg.conf.d/taptouch.conf, dicho archivo se crea de la siguiente manera:

Abrir la terminal y escribir el siguiente comado:
sudo gedit /etc/X11/xorg.conf.d/taptouch.conf

Una vez que el editor inicie, agregar las siguientes instrucciones, guardar y cerrar. A continuación cerrar sesión y volver a entrar, en su defecto reiniciar el equipo.

Section "InputClass"
 Identifier "touchpad"
 Driver "synaptics"
 MatchIsTouchpad "on"
 Option "TapButton1" "1"
 Option "TapButton2" "3"
 Option "TapButton3" "2"
 Option "VertEdgeScroll" "on"
 Option "VertTwoFingerScroll" "on"
 Option "HorizEdgeScroll" "on"
 Option "HorizTwoFingerScroll" "on"
 Option "CircularScrolling" "on"
EndSection

Y con eso el touchpad ya funciona, sin embargo aún sigue sin aparecer la sección del touchpa en la configuración de Gnome, como se muestra en la primera imagen. Desconozco cuál es el motivo de esto, en el sitio oficial de ask.fedoraproject.org aparecen dos preguntas sobre este tema, pero tampoco hay una solución clara.

Si a alguno de ustedes les funciona, pues que bueno, igual y podrían ayudarme para resolver por completo el detallito.

sábado, 14 de noviembre de 2015

Solucionar error: ErrorTable 'performance_schema.session_variables' doesn't exist de MySQL mostrado en Netbeans

Recientemente instalé MySQL en Fedora 23 después de haber actualizado. Continuando con las instalaciones de los diferentes programas que utilizo y probando cada uno de ellos, me percaté del siguiente error que mostraba Netbeans al intentar ejecutar un aplicación desarrollada en java utilizando mysql como base de datos.

El mensaje del error es:
ErrorTable 'performance_schema.session_variables' doesn't exist



Al principio creí que se debía a las contraseñas del usuario de mysql, o que tal vez el jar estaba desactulizado, pero no era así. En internet encontré la siguiente instrucción de línea de comando para solucionar el error:
mysql_upgrade -u root -p --force
Luego reiniciar el servicio de mysql:
sudo /bin/systemctl restart  mysqld.service

Y con eso se soluciona el error:

Finalmente pude ejecutar mi programa:


Gracias por visitar. Si gustan descargar la aplicación lo tengo en mi sitio de github https://github.com/jesusferm/gestionbasedatos

Fuentes: 
http://stackoverflow.com/questions/31967527/table-performance-schema-session-variables-doesnt-exist
http://www.tecposter.com/fix-mysql-error-table-performance_schema-session_variables-doesnt-exist/

jueves, 24 de septiembre de 2015

Solución al error: Traceback (most recent call last): File "/bin/dnf", line 36, in de DNF


Pare ser exactos, el día 18 de septiembre 2015, intenté actualizar los paquetes de mi SO favorito con base linux, o sea Fedora, y al utilizar el comando:

sudo dnf -y update
Me arrojaba el error:
Traceback (most recent call last):
  File "/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 198, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 117, in _main
    cli.configure(map(ucd, args))
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1007, in configure
    self.optparser.usage = self.optparser.get_usage()
  File "/usr/lib/python2.7/site-packages/dnf/cli/option_parser.py", line 273, in get_usage
    usage += "%-25s %s\n" % (name, summary)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 40: ordinal not in range(128)

Simple y sencillamente me mostraba solo ese mensaje, la verdad no sabía a qué se debía ese error, sin embargo, estoy abscrito a https://ask.fedoraproject.org/es/ que es una página para postear respuestas o preguntas a errors o dudas sobre fedora en general. Una vez posteados mi pregunta, esperé un poco para ser respondido, el usuario https://ask.fedoraproject.org/es/users/16293/albertocsg/ fue quien me contestó la duda solucionando el problea.

EL problema, al menos en esta ocasión se debió a : "Hola. El problema está relacionado con la actualización del paquete dnf-plugin-system-upgrade. En la última actualización, este paquete trae un fichero de idiomas con errores."

La solución es Abrir la terminal y escribir:
sudo nautilus  /usr/share/locale/es/LC_MESSAGES
Buscar el archivo dnf-plugin-system-upgrade.mo y renombrarlo a  dnf-plugin-system-upgrade.mo.bak el punto aquí es, que el nombre cambie, para que el dnf no lo encentre y así no lo use generando errores.

Una vez realizado esto, DNF, funciona correctamente. Espero y les sea útil, sin embargo, no les aseguro que para todas las veces que marque este error DNF, esta sea la solución.

La fuente principal de esto es: https://ask.fedoraproject.org/es/question/75573/como-solucionar-este-error/

miércoles, 29 de julio de 2015

Error al iniciar VirtualBox en Fedora 22 Kernel

En las actualizaciones del Kernel de Fedora 22, resulta que VirtualBox no realiza automáticamente la recompilación del kernel. De tal modo que hay que hacerlo de manera manual.


Bueno, la solución es sencilla, solo hay que ejecutar los siguientes comandos:
sudo /etc/init.d/vboxdrv setup

Arrojará esta información:
Stopping VirtualBox kernel modules                         [  OK  ]
Uninstalling old VirtualBox DKMS kernel modulesError! Could not locate dkms.conf file.
File:  does not exist.
                                                           [  OK  ]
Trying to register the VirtualBox kernel modules using DKMSError! DKMS tree already contains: vboxhost-5.0.0
You cannot add the same module/version combo more than once.
                                                           [FALLÓ]
  (Failed, trying without DKMS)
Recompiling VirtualBox kernel modules                      [  OK  ]
Starting VirtualBox kernel modules                         [  OK  ]
Lo importante aquí, es que la parte siguiente esté en color verde:
  (Failed, trying without DKMS)
Recompiling VirtualBox kernel modules                      [  OK  ]
Starting VirtualBox kernel modules       
Y con eso VirtualBox deberá funcionar correctamente:
Ahora, si por alguna razón no funciona, lo que yo hago es cambiar a la versión del kernel que funcionaba, por ejemplo, en fedora, al momento de iniciar sesión presenta dos o tres versiones del kernel del cual seleccionar, yo selecciono la segunda, es decir, una versión antes, y con eso VirtualBox funciona perfectamente, y solo quedaría esperar a que VirtualBox lanze una actualización oficial.

La otra alternativa es esperar a que VirtualBox presente una actualización para la versión del Kernel, pero me parece que actualmente ya en cualquier distro el comando anterior funciona bien.

Una ultima y tediosa opción, es desinstalar todo lo de VirtualBox y volver a instalarlo, de ese modo se recompilará desde cero el kernel actual con VirtualBox.