Si recuerdan, hace un tiempo expliqué cómo utilizar los backports en Debian. Más adelante demostré cómo dar prioridad a los backports, y en dicho artículo decía textualmente:
“…los backports son paquetes provenientes de testing compilados en un entorno estable… Esto significa que no son paquetes estables.”
“Habiendo aclarado nuevamente la naturaleza de los backports, la conclusión es que esta configuración no es 100% recomendable para servidores…”
Bueno, este es el caso típico de “haz lo que yo digo, mas no lo que yo hago”. Por dar prioridad a los backports y blacklistear “systemd*”, terminé con un buen problema de dependencias y el sistema imposible de actualizar. Crónica de una muerte anunciada…
En este artículo voy a demostrar cómo diagnosticar y resolver problemas de dependencias cuando se utilizan repositorios inestables de Debian y derivados.
La situación es la siguiente: tengo un servidor de testeo Debian 9 en el que decidí habilitar y dar prioridad a los backports (/etc/apt/sources.list.d/backports.list) para contar con software bleeding edge:
deb http://repo.linuxito.com:6666/debian/ stretch-backports main contrib
La configuración de pinning para los backports es la siguiente (/etc/apt/preferences.d/backports):
Package: * Pin: release a=stretch-backports Pin-Priority: 550
A su vez, el servidor utiliza el gestor de inicio sysv en lugar de systemd, y el mismo se encuentra en la lista negra de paquetes (/etc/apt/preferences.d/systemd):
Package: libsystemd0 Pin: release * Pin-Priority: 1 Package: systemd-sysv Pin: release * Pin-Priority: 1 Package: *systemd* Pin: release * Pin-Priority: -1
Cuestión que un buen día de estos me dispongo a actualizar el sistema, y resulta que es imposible actualizar el kernel 4.19 ya que ahora el paquete initramfs-tools para dicha versión (indispensable para crear las imágenes en RAM en cada actualización del kernel Linux) depende en cadena de systemd (vaya fiasco, Debian).
Para resolver este inconveniente sin instalar systemd, lamentablemente no queda otra alternativa que volver al kernel estable de stretch versión 4.9. Veamos entonces cómo resolví todo este embrollo de dependencias…
Para comenzar, desinstalar el paquete initramfs-tools proveniente desde lo backports:
# apt-get purge initramfs-tools
Durante este proceso, SE DESINSTALAN TODOS LOS KERNELS, pues es imposible instalar un kernel sin contar con initramfs-tools para crear la imagen en RAM (o alguna alternativa similar como tiny-initramfs). Se trata de una dependencia forzosa.
Luego es necesario quitar prioridad a los backports, así se evita volver a la versión más actualizada de dicho paquete:
# nano /etc/apt/preferences.d/backports
Cambiar la prioridad a -1:
Pin-Priority: -1
Adiós backports…
Ahora, intentar desinstalar systemd (sí, antes tuve que “desblacklistear” e instalar systemd en un intento por actualizar initramfs-tools y el kernel 4.19):
# apt-get purge systemd
Este comando falla pues no es posible instalar sysv:
init depende de systemd-sysv | sysvinit-core; sin embargo: El paquete `systemd-sysv' va a ser desinstalado. El paquete `sysvinit-core' no está instalado.
Entonces las opciones son éstas: me quedo con systemd; o me despido de los backports. Claramente opté por despedirme de los backports, tal como prueba la configuración de pinning anterior.
Sin embargo, a fin de eliminar systemd, no queda otra alternativa que eliminar el kernel 4.19 dependiente de una versión específica de initramfs-tools que ahora depende de systemd. El camino a seguir es desinstalar initramfs-tools, desinstalar el kernel 4.19 y volver al kernel 4.9 estable de stretch.
Veamos entonces si ahora es posible reinstalar initramfs-tools desde los repositorios estables:
# apt-get install initramfs-tools
También falla:
initramfs-tools : Depende: initramfs-tools-core (= 0.130) pero no va a instalarse
Veamos por qué no es posible instalar initramfs-tools-core:
# apt-get install initramfs-tools-core
¡udev no va a instalarse!
initramfs-tools-core : Depende: udev pero no va a instalarse
Ok, veamos por qué:
# apt-get install udev
Este es el error al intentar instalarlo:
udev : Depende: libudev1 (= 232-25+deb9u11) pero 241-3~bpo9+1 va a ser instalado
Bien, la raíz del problema de dependencias (en este punto) es que ha quedado una versión muy actualizada de libudev1. Está instalada la versión “241-3~bpo9+1” mientras que se requiere exactamente la versión “232-25+deb9u11”.
Este problema se debe a que tengo una versión de libudev1 proveniente desde los backports, y es demasiado nueva. Veamos si es posible eliminarla para instalarla nuevamente desde los repos estables.
# apt-get purge libudev1
Al intentar eliminar libudev1 falla porque es requerido tanto por systemd como por sysv:
init : PreDepende: systemd-sysv pero no va a instalarse o
sysvinit-core pero no va a instalarse
Entonces no queda otra opción que eliminar libudev1 por la fuerza utilizando directamente dpkg:
# dpkg --force-all -P libudev1
Ahora sí, reinstalar la versión estable:
# apt-get install libudev1
Luego sí es posible instalar initramfs-tools:
# apt-get install initramfs-tools
Volver a sysv eliminando systemd:
# apt-get install sysvinit-core
Finalmente instalar el kernel estable:
# apt-get install linux-image-4.9.0-8-amd64
Reiniciar con el kernel nuevo:
# reboot
Si todo salió bien, el sistema inicia perfectamente. De lo contrario, espero que hayan hecho un snapshot… 
root@debian9:~# uptime 09:20:16 up 0 min, 1 user, load average: 1,04, 0,29, 0,10 root@debian9:~# uname -a Linux debian9.linuxito.com 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux