uname está roto: ¿cómo determino el kernel actualmente en ejecución?


13
> uname -r
FATAL: kernel too old
> cat /proc/cmdline
FATAL: kernel too old

Hay 3 * .vmlinuz-linux archivos en / boot. ¿Cómo determino qué núcleo se está ejecutando actualmente?

Tenga en cuenta que estoy ejecutando en un entorno limitado con un shell mínimo. También he intentado:

> sh -c 'read l < /proc/version; echo $l'
FATAL: kernel too old
> dd if=/proc/version
FATAL: kernel too old

¿Alguna idea?


reiniciar. Si GRUB está instalado, tal vez pueda tener opciones para resolver su problema. O use un live-cd o usb ...
jcm69

2
Tengo curiosidad, ¿cómo arrancaste la cosa? ¿Y qué es eso? Parece que faltan algunos bits clave de información. ¿Es este un proyectil de rescate? puedes darme mas detalles?
Lizardx

Si tiene cromo instalado, consulte:chrome://system/
GAD3R

Sí, es un caparazón de rescate. Estaba actualizando muchos paquetes, incluido glibc. El demonio que ejecuta el shell de rescate todavía está vivo y escuchando en un puerto, así que pude entrar allí.
William Pursell

1
Parece que la máquina se ha reiniciado (por ejemplo, alguien presionó un botón) y esto se ha convertido en una cuestión académica. Era un estado interesante, y me hubiera gustado tener algunos datos concretos sobre qué buscar, pero supongo que la conclusión es: actualizar el kernel y reiniciar antes de actualizar glibc.
William Pursell

Respuestas:


19

Ha actualizado su libc (la biblioteca del sistema más básica) y ahora ningún programa funciona. Para ser precisos, ningún programa vinculado dinámicamente funciona.

En su escenario particular, reiniciar debería funcionar. La libc ahora instalada requiere un kernel más nuevo, y si reinicia, debería obtener ese kernel más nuevo.

Mientras todavía tenga un shell en ejecución, a menudo hay una manera de recuperarse, pero puede ser complicado si no lo planeó. Si no tiene un shell, generalmente no hay otra solución que reiniciar.

Aquí es posible que no pueda recuperarse sin reiniciar, pero al menos puede averiguar fácilmente qué núcleo se está ejecutando. Simplemente use una forma de leer /proc/versionque no requiera un comando externo.

read v </proc/version; echo $v
echo $(</proc/version)               # in zsh/bash/ksh

Si todavía tiene una copia de la vieja libc, puede ejecutar programas con ella. Por ejemplo, si la antigua biblioteca está en /old/liby tiene ejecutables que funcionan con esta antigua biblioteca /old/bin, puede ejecutar

LD_LIBRARY_PATH=/old/lib /old/lib/ld-linux.so.2 /old/bin/uname

Si tiene algunos archivos binarios enlazados estáticamente, seguirán funcionando. Recomiendo instalar utilidades de sistema vinculadas estadísticamente para este tipo de problema (pero debe hacerlo antes de que comience el problema). Por ejemplo, en Debian / Ubuntu / Mint / ..., instale uno o más de busybox-static (colección de herramientas básicas de línea de comandos de Linux, incluido un shell), sash (shell con algunos componentes adicionales), zsh-static (solo un shell pero con bastantes herramientas prácticas integradas).

busybox-static uname
sash -c '-cat /proc/version'
zsh-static -c '</proc/version'

si reinicia, debería obtener ese kernel más nuevo. o una pantalla negra que parece mucho más probable
gato

Asignar LD_LIBRARY_PATH es una gran sugerencia. Desafortunadamente, el shell de rescate no tiene una lectura interna, no permite redirecciones, ¡y ni siquiera permite la asignación de variables de entorno! Estoy presentando un error para obtener la asignación de env en el shell.
William Pursell

6

Ese parece ser el error que produce glibc si se ejecuta en un núcleo que es más antiguo de lo que la biblioteca está compilada para soportar. El mensaje de error está en la DL_SYSDEP_OSCHECK(FATAL)macro ensysdeps/unix/sysv/linux/dl-osinfo.h

Hay una opción de tiempo de compilación para esto:

--enable-kernel=version
Esta opción actualmente solo es útil en sistemas GNU / Linux. El parámetro de versión debe tener la forma XYZ y describe la versión más pequeña del kernel de Linux que se espera que la biblioteca generada admita. Cuanto mayor sea el número de versión, menos código de compatibilidad se agrega y más rápido se vuelve el código.

Parece que, por alguna razón, está ejecutando un sistema con un núcleo antiguo pero un glibc instalado que ya no es compatible con el núcleo antiguo. Es difícil saber cómo se obtuvo sin información sobre qué sistema es, pero se podría suponer que podría suceder si la biblioteca se actualiza pero el núcleo no.

file parece mostrar la versión mínima requerida por un ejecutable o una biblioteca (pero, por supuesto, necesita una biblioteca que funcione para ejecutarlo):

/lib/x86_64-linux-gnu/libc-2.23.so: ELF 64-bit LSB shared object, x86-64, ..., for GNU/Linux 2.6.32, stripped

En mis sistemas Debian semi-actuales, la versión de kernel requerida es la 2.6.32anterior en todos los archivos binarios que verifiqué, lo que haría muy poco probable que se produzca un problema con la versión de kernel.


5

Prueba con esto:

cat /proc/version

> cat /proc/version FATAL: kernel too old
William Pursell

Este es un buen pensamiento, pero con el incompatible glibc, catno está disponible.
William Pursell

Lo temía tanto, pero valió la pena intentarlo ...
Sven

¿Es solo porque el gato no está disponible? ¿Por qué no vim o nano / proc / version entonces?
jesse_b

¿Qué tal: head /proc/version|| tail /proc/version|| sed '1q;d' /proc/version
jesse_b

0

Use el stringscomando para extraer la información imprimible del vmlinuzarchivo.

strings vmlinuz | grep version

Salida de muestra:

4.9.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516
(Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.