Aunque una distribución Linux podría elegir instalar el software como más le conviniera, lo más habitual es que, como mínimo, puedan instalarlo desde sus repositorios oficiales. Estos repositorios pueden estar mantenidos directamente por la distribución y/o basarse en otros, como pasa con Debian->Ubuntu->Linux Mint, por ejemplo. En estos casos, el gestor de paquetes es APT, y en ocasiones podemos ver el mensaje «no se pudo bloquear /var/lib/dpkg/lock» en el terminal o incluso en alguna herramienta con interfaz gráfica.

Este artículo intentará arrojar algo de luz sobre qué es y cómo se puede solucionar el fallo que provoca que veamos el mensaje «no se pudo bloquear /var/lib/dpkg/lock», pero ya os adelanto que hay una solución muy sencilla que puede arreglar este y muchos otros problemas, ya sea en una distribución basada en Linux o cualquier otro sistema operativo, incluidos los móviles.

Qué significa el error «no se pudo bloquear /var/lib/dpkg/lock»

Por lo general, cuando vemos el error «no se pudo bloquear /var/lib/dpkg/lock», el terminal o el software que nos lo muestre nos está indicando que otro proceso de APT está en ejecución y utiliza la misma base de datos a la que estamos intentando acceder. Dicho de otro modo, el nuevo proceso APT intenta bloquear el archivo /var/lib/dpkg/lock, no lo consigue porque está ocupado y nos informa de ello.

Lo más habitual es que otro proceso de APT, como puede ser el de actualización, ya esté en marcha y ha bloqueado el archivo de bloqueo, por lo que no puede dar el primer paso, que es justamente bloquear dicho archivo.

Cómo solucionar el error

Lo primero que tenemos que hacer, sobre todo si no nos gusta tirar de terminal, es comprobar si hay alguna aplicación de software ejecutándose. Por ejemplo, en Ubuntu podemos ver si Ubuntu Software (fork de GNOME Software) está haciendo algo, y también Actualización de Software, la aplicación que se encarga, como su nombre indica, de actualizar el software. Si no vemos ninguna de esas aplicaciones abiertas, también podemos iniciar el monitor del sistema y buscarlas, para ver si se están ejecutando en segundo plano.

Las aplicaciones que tenemos que buscar dependerán de la distribución que estemos usando, ya que Ubuntu Software no está en Kubuntu, ni Discover en la versión principal de Debian. Cada distribución gestiona el software con las herramientas que decide añadir, y pueden bloquear el archivo GNOME Software, Discover, cualquier otra tienda de software o la herramienta de actualizaciones.

Sea que están en primer plano o en segundo, una opción es tener paciencia y esperar para ver si finaliza el trabajo que está realizando. A veces vemos un mensaje de error y queremos que se solucione al instante, cuando la solución es esperar un momento.

Un reinicio o cierre de sesión debería ser suficiente

Hace muchos años, un amigo siempre me estaba preguntando cómo solucionar sus fallos en Windows. Llegó un momento en el que ya casi ni le preguntaba, y le recomendaba reiniciar porque casi siempre era la mejor solución para él. En el caso del error »no se pudo bloquear /var/lib/dpkg/lock» también es una posible solución. Al iniciar desde cero, puede que empiece con el archivo bloqueado por la herramienta de actualizaciones, pero lo desbloqueará pronto, cuando compruebe que no hay nada nuevo para instalar o sí lo haya, pero ya nos haya informado sobre ello.

Claro está que no es la solución más elegante, pero es la menos costosa y puede ser la mejor y más rápida si no tenemos ningún motivo para mantener la sesión iniciada.

Cuando el mensaje »no se pudo bloquear /var/lib/dpkg/lock» no se va

Cuando hemos reiniciado o esperado un rato y seguimos viendo el mensaje, lo que nos está pasando no es algo habitual. El bloqueo se ha quedado «colgado» o, valga la redundancia, bloqueado, por lo que ya merece la pena tirar de terminal.

1. Lo primero que haremos será abrir un terminal e identificar el proceso APT en ejecución con este comando:

sudo lsof /var/lib/dpkg/lock

2. Con el proceso identificado, lo matamos con este comando, sustituyendo PID por el número del proceso que habremos averiguado con el comando del paso 1:

sudo kill PID

3. Por último, volvemos a intentar realizar la gestión APT que nos estaba devolviendo el fallo. Debería permitirnos seguir adelante.

Si esto no lo soluciona, podemos realizar algo más drástico, por lo que habrá que tomar precauciones o dar pasos extra. Esto es hacerlo «a las bravas»: eliminando el archivo /var/lib/dpkg/lock. Los pasos a seguir para hacerlo con total seguridad serían estos:

1. Hacemos una copia de seguridad del archivo /var/lib/dpkg/lock. Como lo que haremos será copiarlo, podemos usar el gestor de archivos, ya que no se requieren permisos de super usuario. Desde el terminal se podría hacer con cp /var/lib/dpkg/lock nueva-ruta, cambiando «nueva-ruta» por la ruta en la que queremos hacer la copia de seguridad.
2. Eliminamos el archivo. Para esto sí será necesario tirar de privilegios. Si nuestro gestor de archivos nos lo permite, podemos escribir, por ejemplo, «sudo nautilus» sin las comillas para eliminarlo con interfaz gráfica, pero creo que será más rápido y sencillo abrir el terminal y escribir:

sudo rm /var/lib/dpkg/lock

3. Con el archivo eliminado ya podemos volver a intentar lo que no se nos permitía. Si escribimos sudo apt update y no vemos el error, el fallo está solucionado.

El reinicio y la paciencia suelen ser lo mejor

Aunque hay maneras de solucionarlo, como las explicadas en el punto anterior, el error »no se pudo bloquear /var/lib/dpkg/lock» no es nada realmente grave y se puede solucionar esperando un momento o reiniciando. Es algo que por lo general se arregla por sí mismo, y si no lo hace, el reinicio es lo menos agresivo y más efectivo. Ahora bien, esto es Linux, y todo o casi todo tiene solución desde el terminal, por no hablar de que podemos «cargarnos» todo lo que nos venga en gana.

Sea por el motivo que sea, espero que lo expuesto aquí haya podido ayudarte, o bien para hacer desaparecer el mensaje con un proceso más agresivo o para que tengas un poco de paciencia.

from Linux Adictos https://ift.tt/wc0f4xi
via IFTTT

Vaya «susto» (entre comillas, que os conozco) me he llevado, y he de reconocer que aún no se me ha pasado. Y es que de Canonical te puedes esperar lo mejor y lo peor, aunque creo que somos más los usuarios que llevamos años en Linux los que pensamos que sus últimos movimientos no son los más acertados o, al menos, los que más nos interesa a sus usuarios. Y es que, mientras escribía un artículo de esos destinados a responder preguntas en uno de nuestros blogs hermanos, he visto lo que muestra la captura de cabecera: ¿qué hacía ahí la Snap Store?

La situación ha sido así: para explicar algunas cosas, he tratado de hacerlo en una máquina virtual de Ubuntu, y la que tengo es de 23.04, la Daily Build en donde puedo ver los progresos que se van haciendo, como el del fondo de pantalla. Trataba de explicar que la manera más sencilla de instalar un paquete DEB en Ubuntu es sencillamente haciendo doble clic sobre él, esperar a que se abra el instalador y luego hacer clic en Instalar. Pero al hacerlo no he visto el icono de Instalar Software ni se me ha abierto Ubuntu Software, si no la Snap Store. La palabra que tenía en la cabeza, además de otras de dudas, era «flipo».

La Snap Store está oculta bajo la alfombra en Ubuntu

La Snap Store no se puede abrir desde el cajón de aplicaciones. No aparece en la búsqueda, pero sí aparece como opción si hacemos clic derecho en un paquete DEB. También aparece ejecutándose en segundo plano constantemente, y en ocasiones consumiendo más de lo que se podría asumir. Pero casi nunca nos damos cuenta de que está ahí. Entonces, ¿qué es lo que ha pasado?

Siendo mal pensado, y los últimos movimientos nos invitan a serlo, podemos pensar que Canonical va a hacer algo extraño que veremos en Ubuntu 23.04. El qué concretamente, no lo sé. Quizá quieran darle más protagonismo a la Snap Store y en el futuro sea la que se encargue de instalar los paquetes DEB locales, pero es que en la actualidad (22.10) falla al intentar instalarlos. Pensando bien, no habría que darle importancia, ya que estamos en la fase del desarrollo y ésta está para usarse como campo de pruebas. Además, me extrañaría mucho que hicieran otro movimiento criticable tan pronto. A quien le vendría bien es al equipo de Linux Mint, que es donde suelen mirar los que se sienten decepcionados con los sabores oficiales de Ubuntu.

Esperemos que se quede en una anécdota más o menos divertida, y que sea sólo eso.

from Linux Adictos https://ift.tt/XoAebU7
via IFTTT