Aiutoo !! I kernel non mi tornano !!!

Diciamo che potrebbe essere riassunto così: “Aiutoo !! I kernel non mi tornano !” sul fatto che installara risulta una versione mentre in esecuzione ce n’è un’altra (precedente). Ma andiamo con ordine.

Riunione con DaBoss. Alla fine chiede a VolpeDiFuoco:

DaBoss: “Come procede la migrazione di XXX a virtuale ?”

VolpeDiFuoco: “Abbiamo avuto un problema ! A causa di un errore nell’installazione del server (ed indica me) non possiamo usare i tools pertanto dobbiamo fare bla bla bla e bli blu blo: ci vorra molto più tempo !”

DaBoss: “Mmm…fammi sapere come procede”.

Ovviamente essendo stato chiamato in causa, quale persona che ha installato RedHat ES su tale macchina, chiedo subito a VolpeDiFuoco quale sarebbe stato questo “errore”. La risposta arriva veloce:

Allego estratto tradotto del supporto VMware:
_______
L’ mkinitrd che viene lanciato in fase di virtualizzazione (P2V), nonostante il kernel possa essere chiamato in qualsiasi modo all’interno del grub, fa girare un “uname -r” che verifica la versione del kernel che sta girando e si aspetta di trovare una direttorio chiamato allo stesso modo sotto la /lib/modules/.

Dai file che avete mandato probabilmente e’ stato cambiato il nome del kernel a 2.6.9-100.EL. Lo script lanciato dal tool di virtualizzazione va a cercare il direttorio /lib/modules/2.6.9-89.0.26.EL che non esiste, in quanto sembra essere stato rinominato in 2.6.9-100.EL, e questo ha generato l’errore.

Il server in questione non è virtualizzabile con questa situazione a meno che non si ripristinino le posizioni originali dei files e delle lib, cosa che può essere fatta solo con un downtime e dopo un cold-backup.

Consigliamo una nuova installazione del sistema in modo da rendere standard le posizioni e possibile l’avvio degli script post-copia.
_______

La risposta non mi convince affatto percui entro nel server incriminato e mi appresto a verificare. Se faccio “uname -r” ottengo, correttamente:

[root@xxx home]# uname -r
2.6.9-89.0.26.EL
[root@xxx home]#

ma se guardo i moduli del kernel, dentro /lib/modules, vedo che:

[root@xxx modules]# ls -l
totale 16
drwxr-xr-x 3 root root 4096 20 feb 13:39 2.6.9-100.EL
drwxr-xr-x 3 root root 4096 20 feb 13:39 2.6.9-100.ELsmp
drwxr-xr-x 2 root root 4096 1 feb 18:14 kabi-4.0-0
drwxr-xr-x 2 root root 4096 1 feb 18:31 kabi-4.0-0smp
[root@xxx modules]#

(tenete a mente la data di tali file)

Questa discrepanza da cosa dipende ? Beh, probabilmente dal fatto che è stato fatto un aggiornamento del sistema (up2date ?) che ha aggiornato il kernel all’ultima release disponibile (la 2.6.9-100EL, appunto) ma che poi NON SI E’ PROVVEDUTO AL REBOOT DELLA MACCHINA, come suggerisce ‘uptime‘:

[root@xxx modules]# uptime
12:47:58 up 116 days, 1:40, 6 users, load average: 1.63, 1.94, 2.27
[root@xxx modules]#

e come si vede dal kernel presente in /boot:

[root@xxx boot]# ls -l
-rw-r–r– 1 root root 1538260 1 feb 18:13 vmlinuz-2.6.9-100.EL
-rw-r–r– 1 root root 1476983 1 feb 18:30 vmlinuz-2.6.9-100.ELsmp
[root@xxx boot]#

Se poi vado a vedere i log di up2date trovo pure la conferma all’aggiornamento:

[root@xxx log]# cat up2date.1
…
[Sun Feb 20 13:39:12 2011] up2date installing packages: [‘kernel-2.6.9-100.EL’, ‘kernel-smp-2.6.9-100.EL’]
[Sun Feb 20 13:39:35 2011] up2date Removing packages from package profile: [‘kernel-2.6.9-89.35.1.EL’, ‘kernel-smp-2.6.9-89.35.1.EL’]

è evidente che il kernel che attualmente è in ESECUZIONE non è lo stesso presente sulla macchina.

Come si risolve ? Probabilmente è sufficente fare un REBOOT di xxx.