uname è rotto: come posso determinare il kernel attualmente in esecuzione?

13

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

Ci sono file 3 * .vmlinuz-linux in / boot. Come determinare quale kernel è attualmente in esecuzione?

Nota che sto correndo in un ambiente limitato con una shell minima. Ho anche provato:

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

qualche idea?

linux glibc

— William Pursell
fonte

riavvio. Se GRUB è installato, forse puoi avere opzioni per risolvere il tuo problema. O usa un live-cd o usb ...

— jcm69

2

Sono curioso, come hai avviato la cosa? E che cos'è? Sembra che manchino alcune informazioni chiave. È un guscio di salvataggio? Potete fornire maggiori dettagli?

— Lizardx,

Se hai installato il cromo vedi:chrome://system/

— GAD3R

Sì, è una shell di salvataggio. Stavo aggiornando molti pacchetti, incluso glibc. Il demone che esegue la shell di salvataggio è ancora vivo e in ascolto su una porta, quindi sono stato in grado di entrare.

— William Pursell,

1

Sembra che la macchina sia stata riavviata a fondo (ad esempio, qualcuno ha premuto un pulsante) e questa è diventata una domanda accademica. Era uno stato interessante e mi sarebbero piaciuti alcuni dati concreti su cosa cercare, ma suppongo che il takeaway sia: aggiornare il kernel e riavviare prima di aggiornare glibc.

— William Pursell,

19

Hai aggiornato libc (la libreria di sistema più semplice) e ora nessun programma funziona. Per essere precisi, nessun programma collegato dinamicamente funziona.

Nel tuo particolare scenario, il riavvio dovrebbe funzionare. La libc ora installata richiede un kernel più recente e, al riavvio, dovresti ottenere quel kernel più recente.

Finché hai ancora una shell in esecuzione, c'è spesso un modo per recuperare, ma può essere complicato se non l'hai pianificato. Se non si dispone di una shell, di solito non esiste altra soluzione che riavviare.

Qui potresti non essere in grado di recuperare senza riavviare, ma puoi almeno scoprire facilmente quale kernel è in esecuzione. Basta usare un modo per leggere /proc/versionche non richiede un comando esterno.

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

Se hai ancora una copia della vecchia libc in giro, puoi eseguire i programmi con essa. Ad esempio, se è presente il vecchio libc /old/libe hai degli eseguibili che funzionano con questo vecchio libc /old/bin, puoi eseguirlo

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

Se hai dei binari collegati staticamente, funzioneranno comunque. Ti consiglio di installare utility di sistema collegate statisticamente per questo tipo di problema (ma devi farlo prima che il problema inizi). Ad esempio, su Debian / Ubuntu / Mint /…, installa uno o più di busybox-static (raccolta di strumenti di riga di comando Linux di base tra cui una shell), sash (shell con alcuni builtin extra), zsh-static (solo una shell ma con alcuni strumenti utili integrati).

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

— Gilles 'SO- smetti di essere malvagio'
fonte

se riavvii, dovresti ottenere quel kernel più recente. o uno schermo nero che sembra molto più probabile

— gatto

L'assegnazione di LD_LIBRARY_PATH è un ottimo suggerimento. Sfortunatamente, la shell di salvataggio non ha una lettura interna, non consente reindirizzamenti e non consente nemmeno l'assegnazione di variabili di ambiente! Sto presentando un bug per ottenere l'assegnazione env nella shell.

— William Pursell,

6

Questo sembra essere l'errore generato da glibc se è in esecuzione su un kernel più vecchio di quello che la libreria è stata compilata per supportare. Il messaggio di errore è nella DL_SYSDEP_OSCHECK(FATAL)macro insysdeps/unix/sysv/linux/dl-osinfo.h

C'è un'opzione di compilazione per questo:

--enable-kernel=version
Questa opzione è attualmente utile solo su sistemi GNU / Linux. Il parametro version dovrebbe avere il formato XYZ e descrive la versione più piccola del kernel Linux che la libreria generata dovrebbe supportare. Più alto è il numero di versione, meno codice di compatibilità viene aggiunto e più veloce diventa il codice.

Quindi, per qualche motivo, stai eseguendo un sistema con un vecchio kernel ma un glibc installato che non supporta più il vecchio kernel. È difficile capire come sia stato ottenuto senza informazioni su quale sia il sistema, ma si potrebbe presumere che ciò potrebbe accadere se la libreria fosse aggiornata ma il kernel no.

file sembra mostrare la versione minima richiesta da un eseguibile o da una libreria (ma ovviamente è necessaria una libreria funzionante per eseguirla):

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

Sui miei sistemi Debian semi-attuali, la versione del kernel richiesta è 2.6.32come sopra su tutti i binari che ho controllato, il che renderebbe molto improbabile che si verifichi un problema con la versione del kernel.

— ilkkachu
fonte

5

Prova con questo:

cat /proc/version

— Sven
fonte

> cat /proc/version FATAL: kernel too old

— William Pursell,

Questa è una buona idea, ma con glibc incompatibile, catnon è disponibile.

— William Pursell,

Temevo altrettanto, ma valeva la pena provarlo ...

— Sven

È solo perché il gatto non è disponibile? Perché non vim o nano / proc / version allora?

— jesse_b,

Che ne dici di: head /proc/version|| tail /proc/version|| sed '1q;d' /proc/version

— jesse_b,

0

Utilizzare il stringscomando per estrarre le informazioni stampabili dal vmlinuzfile.

strings vmlinuz | grep version

Uscita campione:

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
fonte