uname est cassé: comment déterminer le noyau en cours d'exécution?

13

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

Il y a 3 * fichiers .vmlinuz-linux dans / boot. Comment déterminer le noyau en cours d'exécution?

Notez que je cours dans un environnement limité avec un shell minimal. J'ai aussi essayé:

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

Des pensées?

linux glibc

— William Pursell
source

redémarrer. Si GRUB est installé, vous pouvez peut-être avoir des options pour résoudre votre problème. Ou utilisez un live-cd ou une clé usb ...

— jcm69

2

Je suis curieux, comment avez-vous démarré la chose? Et c'est quoi? Semble manquer de quelques informations clés. Est-ce un obus de sauvetage? Pouvez-vous fournir plus de détails?

— Lizardx

Si vous avez installé du chrome, voir:chrome://system/

— GAD3R

Oui, c'est une coquille de sauvetage. J'étais en train de mettre à jour de nombreux packages, dont glibc. Le démon exécutant le shell de sauvetage est toujours en vie et écoute sur un port, j'ai donc pu y entrer.

— William Pursell

1

Il semble que la machine ait été redémarrée (par exemple, quelqu'un a appuyé sur un bouton) et cela est devenu une question académique. C'était un état intéressant, et j'aurais aimé avoir des données solides sur ce qu'il faut rechercher, mais je suppose que le point à retenir est: mettre à niveau le noyau et redémarrer avant de mettre à niveau la glibc.

— William Pursell

19

Vous avez mis à jour votre libc (la bibliothèque système la plus basique) et maintenant aucun programme ne fonctionne. Pour être précis, aucun programme lié dynamiquement ne fonctionne.

Dans votre scénario particulier, le redémarrage devrait fonctionner. La libc maintenant installée nécessite un noyau plus récent, et si vous redémarrez, vous devriez obtenir ce noyau plus récent.

Tant que vous avez toujours un shell en cours d'exécution, il existe souvent un moyen de récupérer, mais cela peut être difficile si vous ne le planifiez pas. Si vous n'avez pas de shell, il n'y a généralement pas de solution autre que le redémarrage.

Ici, vous ne pourrez peut-être pas récupérer sans redémarrer, mais vous pouvez au moins facilement savoir quel noyau est en cours d'exécution. Utilisez simplement un moyen de lire /proc/versionqui ne nécessite pas de commande externe.

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

Si vous avez toujours une copie de l'ancienne libc, vous pouvez exécuter des programmes avec. Par exemple, si l'ancienne libc est dans /old/libet que vous avez des exécutables qui fonctionnent avec cette ancienne libc dans /old/bin, vous pouvez exécuter

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

Si vous avez des fichiers binaires liés statiquement, ils fonctionneront toujours. Je recommande d'installer des utilitaires système liés statistiquement pour ce type de problème (mais vous devez le faire avant que le problème ne commence). Par exemple, sur Debian / Ubuntu / Mint /…, installez un ou plusieurs de busybox-static (collection d'outils de ligne de commande Linux de base, y compris un shell), sash (shell avec quelques extensions supplémentaires), zsh-static (juste un shell mais avec pas mal d'outils pratiques intégrés).

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

— Gilles 'SO- arrête d'être méchant'
source

si vous redémarrez, vous devriez obtenir ce noyau plus récent. ou un écran noir qui semble beaucoup plus probable

— chat

Affecter LD_LIBRARY_PATH est une excellente suggestion. Malheureusement, le shell de sauvetage n'a pas de lecture interne, n'autorise pas les redirections et ne permet même pas l'attribution de variables d'environnement! Je dépose un bogue pour obtenir l'affectation env dans le shell.

— William Pursell

6

Cela semble être l'erreur lancée par la glibc si elle s'exécute sur un noyau plus ancien que ce que la bibliothèque est compilée pour prendre en charge. Le message d'erreur se trouve dans la DL_SYSDEP_OSCHECK(FATAL)macro danssysdeps/unix/sysv/linux/dl-osinfo.h

Il existe une option de compilation pour cela:

--enable-kernel=version
Cette option n'est actuellement utile que sur les systèmes GNU / Linux. Le paramètre de version doit avoir la forme XYZ et décrit la plus petite version du noyau Linux que la bibliothèque générée devrait prendre en charge. Plus le numéro de version est élevé, moins le code de compatibilité est ajouté et plus le code est rapide.

Il semble donc que pour une raison quelconque, vous exécutez un système avec un ancien noyau mais une glibc installée qui ne prend plus en charge l'ancien noyau. Il est difficile de dire comment vous l'avez obtenu sans informations sur le système, mais on pourrait supposer que cela pourrait se produire si la bibliothèque est mise à jour mais pas le noyau.

file semble montrer la version minimale requise par un exécutable ou une bibliothèque (mais bien sûr, vous avez besoin d'une bibliothèque de travail pour l'exécuter):

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

Sur mes systèmes Debian semi-actuels, la version du noyau requise est 2.6.32comme ci-dessus sur tous les binaires que j'ai vérifiés, ce qui rendrait très peu probable un problème avec la version du noyau.

— ilkkachu
source

5

Essayez avec ceci:

cat /proc/version

— Sven
source

> cat /proc/version FATAL: kernel too old

— William Pursell

C'est une bonne idée, mais avec la glibc incompatible, catn'est pas disponible.

— William Pursell

J'en craignais autant, mais ça valait le coup d'essayer ...

— Sven

Est-ce juste parce que le chat n'est pas disponible? Pourquoi pas vim ou nano / proc / version alors?

— jesse_b

Que diriez-vous: head /proc/version|| tail /proc/version|| sed '1q;d' /proc/version

— jesse_b

0

Utilisez la stringscommande pour extraire les informations imprimables du vmlinuzfichier.

strings vmlinuz | grep version

Exemple de sortie:

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)

— GAD3R
source