Problema actualización glibc: múltiples versiones de una misma librería

Desde hace un par de días en una portátil se da un problema extraño que en la otra no ha sucedido. Tanto el applet de actualización como la actualización en línea de YaST2 dicen que hay una actualización de seguridad para glibc, pero al intentar instalarla da error.

Mirando, veo que en la portátil con el problema hay 4 (¡!) versiones instaladas de los siguientes paquetes:

glibc-devel
glibc-lang
glibc-locale
glibc-locale-base

están las versiones 71.1, 74.1 y la versión justa, la 83.1. La portátil que no da problemas tiene solo la última versión, por lo que no tengo idea de cómo se han acumulado todas esas versiones en la problemática. ¿Cómo puedo hacer para «limpiar» el lío y que solo quede la última versión de esas librerías?

Hola:
Quizás te pueda interesar esto : Zypper y los paquetes de dependencias
Saludos

Creo que sabes todo lo que diré pero te lo digo igual.

Imagino que podrás desde Yast desde la pestaña de Versiones. Ejemplo con kernel-default:


Siempre tengo 2 versiones instaladas del kernel. Si tienes varias de glibc (u otro paquete) desmarca las casillas que no necesites, aceptar y se desinstalan.

Mira también en paquetes huérfanos que son los que no necesita nadie (se incluyen paquetes de repositorios desactivados o que ya no tengas. En mi pantallazo, los 5 primeros se instalaron con sudo rpm -ivh y el 6º es de un repo que ahora mismo tengo desactivado por problemas de actualización del mismo):

Saludos

Sí, allí es donde vi que había cuatro versiones de cada paquete. El problema es que con estos paquetes no me deja quitar los más viejos: la marca está en gris, no en verde, y no la puedo quitar, lo cual es muy extraño. En huérfanos no tengo nada.

Tienes el devel. ¿Has compilado alguna cosa?

EDIT: Yo también lo tengo… (y no he compilado nada).

Prueba un sudo zypper rm glibc-lang (el paquete de lenguaje) a ver que te dice zypper.

Saludos

La máquina está en uso, por lo que probaré mañana. ¿Existe una forma de indicar a zypper la versión exacta a desinstalar? ¿Algo del tipo «zypper remove paquete-versión»? Donde versión sería algo del tipo 2.31-150300.74.1

Para ver el número exacto de la versión:

sudo zypper se -iv kernel-default                                          ✔  00:03:00 
Cargando datos del repositorio...
Leyendo los paquetes instalados...

S  | Name                 | Type    | Version   | Arch   | Repository
---+----------------------+---------+-----------+--------+-----------------------
i+ | kernel-default       | paquete | 6.8.7-1.1 | x86_64 | (Paquetes del sistema)
    name: kernel-default
i+ | kernel-default       | paquete | 6.9.3-1.1 | x86_64 | (Paquetes del sistema)
    name: kernel-default
i+ | kernel-default-devel | paquete | 6.8.7-1.1 | x86_64 | (Paquetes del sistema)
    name: kernel-default-devel
i+ | kernel-default-devel | paquete | 6.9.3-1.1 | x86_64 | (Paquetes del sistema)
    name: kernel-default-devel

Para desinstalar una versión en concreto:

sudo zypper rm kernel-default-6.8.7-1.1                                    ✔  00:04:51 
Leyendo los paquetes instalados...
Resolviendo dependencias de paquete...

El siguiente paquete va a ser ELIMINADO:
  kernel-default-6.8.7-1.1

1 paquete a quitar.
Después de la operación, se liberarán 241,3 MiB.

Backend:  classic_rpmtrans
Continue? [s/n/v/...? mostrar todas las opciones] (s):

Ahora cambia kernel-default por el paquete que necesites en ambos comandos y tendría que ir.

Saludos

Echa un ojo:

En el pasado he instalado versiones concretas, pero nunca desinstalado. Si no, echa un ojo a rpm.

Salud!!

Hola:
Desde yast, en instalar y desinstalar ,hay que marcar las2opciones que quedan (cambio de proveedor y el de la limpieza) ; También tenía una utilidad que la quitaron (hace tiempo) .

Cuando hay distintas versiones, es porque hay dependencias ; ya sea por distintas aplicaciones que usen distintas versiones, o bien tienen dependencias con snapshots.
Se tendría que limpiar aquellas que estén asociadas (en caso que no deje, se puede cambiar el algoritmo (es porque está ligada a los kernel, etccc del arranque) .

Puedes hacer limpieza y dejar las primeras, de ahí conservan do esas , ya puedes limpiar.
En yast en gestión y servicio, activa el purgue kernel , reinicia y comprueba ,como que al arrancar de nuevo ( se aprecia queda dura mas tiempo tiempo ,por hacer esas operaciones .
Eso lo ves con systemd-analyze.
Saludos

Que yo sepa no es necesario que cada vez que tengas un kernel-default instalado tengas que tener un glibc de diferente versión.

zypper verify no hace milagros pero puede servir para detectar incoherencias.

Echa un vistazo, fijaros en las versiones que tengo instaladas de glibc y kernel-default en mi Leao 15.5:

sudo zypper se -iv glibc kernel-default
Cargando datos del repositorio...
Leyendo los paquetes instalados...

S  | Name                    | Type    | Version                | Arch   | Repository
---+-------------------------+---------+------------------------+--------+------------------
i+ | glibc                   | paquete | 2.31-150300.83.1       | x86_64 | SLE-Update-Leap
    name: glibc
i+ | glibc                   | paquete | 2.31-150300.83.1       | x86_64 | update-sle (15.5)
    name: glibc
i  | glibc-32bit             | paquete | 2.31-150300.83.1       | x86_64 | SLE-Update-Leap
    name: glibc-32bit
i  | glibc-32bit             | paquete | 2.31-150300.83.1       | x86_64 | update-sle (15.5)
    name: glibc-32bit
i  | glibc-devel             | paquete | 2.31-150300.83.1       | x86_64 | SLE-Update-Leap
    name: glibc-devel
i  | glibc-devel             | paquete | 2.31-150300.83.1       | x86_64 | update-sle (15.5)
    name: glibc-devel
i  | glibc-extra             | paquete | 2.31-150300.83.1       | x86_64 | SLE-Update-Leap
    name: glibc-extra
i  | glibc-extra             | paquete | 2.31-150300.83.1       | x86_64 | update-sle (15.5)
    name: glibc-extra
i  | glibc-lang              | paquete | 2.31-150300.83.1       | noarch | SLE-Update-Leap
    name: glibc-lang
i  | glibc-lang              | paquete | 2.31-150300.83.1       | noarch | update-sle (15.5)
    name: glibc-lang
i  | glibc-locale            | paquete | 2.31-150300.83.1       | x86_64 | SLE-Update-Leap
    name: glibc-locale
i  | glibc-locale            | paquete | 2.31-150300.83.1       | x86_64 | update-sle (15.5)
    name: glibc-locale
i  | glibc-locale-base       | paquete | 2.31-150300.83.1       | x86_64 | SLE-Update-Leap
    name: glibc-locale-base
i  | glibc-locale-base       | paquete | 2.31-150300.83.1       | x86_64 | update-sle (15.5)
    name: glibc-locale-base
i+ | kernel-default          | paquete | 5.14.21-150500.55.62.2 | x86_64 | SLE-Update-Leap
    name: kernel-default
i+ | kernel-default          | paquete | 5.14.21-150500.55.65.1 | x86_64 | SLE-Update-Leap
    name: kernel-default
i+ | kernel-default          | paquete | 5.14.21-150500.55.62.2 | x86_64 | update-sle (15.5)
    name: kernel-default
i+ | kernel-default          | paquete | 5.14.21-150500.55.65.1 | x86_64 | update-sle (15.5)
    name: kernel-default
i  | kernel-default-devel    | paquete | 5.14.21-150500.55.62.2 | x86_64 | SLE-Update-Leap
    name: kernel-default-devel
i  | kernel-default-devel    | paquete | 5.14.21-150500.55.65.1 | x86_64 | SLE-Update-Leap
    name: kernel-default-devel
i  | kernel-default-devel    | paquete | 5.14.21-150500.55.62.2 | x86_64 | update-sle (15.5)
    name: kernel-default-devel
i  | kernel-default-devel    | paquete | 5.14.21-150500.55.65.1 | x86_64 | update-sle (15.5)
    name: kernel-default-devel
i  | kernel-default-extra    | paquete | 5.14.21-150500.55.62.2 | x86_64 | SLE-Update-Leap
    name: kernel-default-extra
i  | kernel-default-extra    | paquete | 5.14.21-150500.55.65.1 | x86_64 | SLE-Update-Leap
    name: kernel-default-extra
i  | kernel-default-extra    | paquete | 5.14.21-150500.55.62.2 | x86_64 | update-sle (15.5)
    name: kernel-default-extra
i  | kernel-default-extra    | paquete | 5.14.21-150500.55.65.1 | x86_64 | update-sle (15.5)
    name: kernel-default-extra
i  | kernel-default-optional | paquete | 5.14.21-150500.55.62.2 | x86_64 | SLE-Update-Leap
    name: kernel-default-optional
i  | kernel-default-optional | paquete | 5.14.21-150500.55.65.1 | x86_64 | SLE-Update-Leap
    name: kernel-default-optional
i  | kernel-default-optional | paquete | 5.14.21-150500.55.62.2 | x86_64 | update-sle (15.5)
    name: kernel-default-optional
i  | kernel-default-optional | paquete | 5.14.21-150500.55.65.1 | x86_64 | update-sle (15.5)
    name: kernel-default-optional
i  | linux-glibc-devel       | paquete | 5.14-150500.12.3.2     | x86_64 | SLE-Update-Leap
    name: linux-glibc-devel
i  | linux-glibc-devel       | paquete | 5.14-150500.12.3.2     | x86_64 | update-sle (15.5)
    name: linux-glibc-devel

Otra cosa, no has dicho de que forma instalas las aplicaciones y sus librerías: zypper, opi, flatpak, discover, snap, yast…
Como ves, hay muchas formas de instalación con sus ventajas e inconvenientes…

El problema es que no he hecho nada: la máquina con problemas se usa mayormente para navegar, los paquetes son de los repos normales + packman, no usa flatpacks ni nada por el estilo, no tiene programas extraños… no tengo ni idea de cómo se construyó esta situación.

Intenté quitar la versión 74.1 de glibc-lang, para empezar con algo, con

sudo zypper rm glibc-lang-2.31-150300.74.1

empezó el proceso, pero se detuvo con un

error al eliminar (358)glibc-lang-2.31-150300.74.1.noarch(@system): Error: Subprocess failed. Error: RPM fallido: el comando ha terminado con el estado 1

Esto es lo que se ve en «actualización en línea»

Como se ve, en realidad está tres veces la misma versión (¡!) además de la versión antigua.

Puestos a probar cosas, toqué la versión 74.1 y luego otra vez la versión 83.1, con lo que la marca roja pasó a la marca verde, le di a Aceptar… y el sistema me dice que la versión 74.1 no está instalada… no tengo idea de qué esté pasando. ¿Estará arruinada la base de datos de rpm?

Ese pantallazo a mi me dice que quiere borrarte los paquetes antiguos de la 74.1. Nada más.

Si tienes snapper, acepta ese pantallazo tal y como se ve. Te desharás del 74.1 y veremos que te dice.

Saludos

Es que ese es el problema: acepto, empieza y luego me da error y no hace nada.

Hola.

Has probado a eliminarlo con rpm?

Salud!!

Con
rpm -qa | grep glibc-devel
(sucede lo mismo con -lang, -locale y -locale-base) me da

glibc-devel-2.31-150300.83.1.x86_64
glibc-devel-2.31-150300.83.1.x86_64
glibc-devel-2.31-150300.83.1.x86_64
glibc-devel-2.31-150300.83.1.x86_64

Es decir, cuatro veces la versión 83.1 y la versión 74.1 que aparece como «instalada» en la captura de arriba, para rpm no existe… aquí hay algo que no está bien o en rpm o en YaST/zypper. pero no tengo idea de qué pueda ser.

Probando el mismo comando en la otra portátil solo da una entrada de la librería, que es lo que tiene que ser.

Quiero decir si has probado a desinstalarlo.

sudo rpm -e paquete-latoso-version

Salud!!

Con la 74.1 da error y me dice que versión no está instalada… En fin, que en unas semanas pasaré a 15.6, quizás así se arregle todo, mientras tanto seguiré ignorando el aviso de actualización a glibc.

Hola:
Lang, suele estar asociado a uno de ellos (glibc) , con zypper if (info) , se podría mirar si el vendor (proveedor es el mismo, o pueda ser distinto) .

Que un glibc no se deje borrar, es por que está en uso, por algún programa, y no tiene que estar ejecutando se ( es decir se uso para copilar determinado drive, está instalado y asociado a ese, aunque no se use) .

Un ejemplo son los glibc-32 bits, ¿ que hacen en un equipo de 64bit? , pues algún drive, viene en 32bit, es necesario un runtime a 32bit y se compila a 32bit, un ejemplo puede ser los drives de la brother (suelen venir en 32bits) al ser los drives privativos, no se pueden meter en el kernel, tiene que compilarse a parte y para ello necesitan ese archivo, una vez instalado, ya no pinta nada, pero sigue asociado al drive. .

Los que aparecen en azul, indican que hay una actualización, si al actualizar, no deja o da error, es por que se sigue manteniendo esa asociación (dependencia) o bien la actualización le falta un archivo (no está completo) .
Si en live también da error, es porque se uso por algo, y si no afecta a nada lo dejaría estar (también me supongo que si reinstalas todo de nuevo, pueda pasar lo mismo, en el caso que, el error este en origen) .
Glibc no se usa para compilar y después ya no se utiliza una vez hecho ? .

Saludos