Depanarea kernel panic în Linux

Introducere

Termenul „kernel panic” nu este deloc înspăimântător pentru niciun administrator de sistem. O panică a kernel-ului este o măsură de siguranță, în ultimă fază, exercitată de kernelul sistemului de operare în momentul detectării unei erori fatale interne pe care nu o poate recupera în siguranță sau acesta nu poate continua să funcționeze fără a avea un risc mult mai mare de pierdere a datelor importante. Rutinele de kernel care se ocupă de panică, cunoscute sub numele de panic () în codul sursă derivat de la AT & T și BSD Unix, sunt în general concepute pentru a transmite un mesaj de eroare consolei, și de a arunca o imagine a memoriei kernel-ului pe disc pentru depanare post-mortem, în acest caz fie așteptați ca sistemul să fie repornit manual, fie inițiați o repornire automată. Informațiile furnizate sunt de natură extrem de tehnică și au scopul de a asista un administrator de sistem sau mai precis un inginer de kernel în diagnosticarea problemei. Deși nu este foarte comun, panica kernel-ului poate fi de asemenea cauzată de erori care provin din afara spațiului acestuia.

O panică a kernelului ar putea fi cauzată din numeroase motive diferite. În acest articol, vom demonstra pașii pe care i-am efectuat pentru depanarea unui scenariu de kernel panic care a apărut după ce am repornit un sistem într-o activitate de patch-uri / actualizări de sistem.

Scenariu

Sistemul pe care a apărut panica kernel-ului rula RHEL 6.9, iar panica a fost provocată după ce am restartat sistemul, astfel încât acesta să pornească pe noul kernel instalat pe sistem printr-o activitate de actualizare „yum update”.

Mai jos este o captură de ecran a mesajului de kernel panic afișat pe consolă

Pași de diagnosticare și depanare

Mesajul de panică în kernel în sine nu era foarte descriptiv, așa cum probabil ați înțeles din screenshot-ul afișat mai sus. Dar, după câteva investigații, am reușit să identificăm cauza singură și să o rezolvăm. Vom descrie acum secvența de pași pe care i-am urmat.

De la ce etapă a procesului de bootare sistemul intră în panică?

Am restartat sistemul cu noul kernel de câteva ori pentru a realiza că sistemul a fost panicat de îndată ce sistemul a încercat încărcarea kernel-ului după afișarea secțiunii grub.

S-a încercat boot-area cu vechiul kernel

Am reușit să pornesc cu succes sistemul pentru a rula nivelul 3, fără a întâmpina neplăceri atunci când am încercat să bootez cu vechiul kernel.

Trebuiesc diferențiate liniile pentru kernel-ul vechi și cel nou

Am verificat fișierul /boot/grub/grub.conf și am examinat liniile de kernel la promptul grub pentru a constata că fișierul initramfs lipsea pentru noul kernel. Am restartat sistemul prin kernelul vechi din nou și am observat că nu a fost creat niciun fișier initramfs pentru noul kernel în directorul / boot.

[ssuri@linuxnix:/boot] $ ls -ltr | grep -i initramfs
-rw––- 1 root root 26654700 Dec 11 2016 initramfs-2.6.32-642.6.2.el6.x86_64.img
-rw––- 1 root root 26088799 Jan 8 2017 initramfs-2.6.32-573.1.1.el6.x86_64.tmp
-rw––- 1 root root 26781018 Jun 11 2017 initramfs-2.6.32-642.13.1.el6.x86_64.img
-rw––- 1 root root 26088606 Dec 17 03:11 initramfs-2.6.32-573.18.1.el6.x86_64.tmp
-rw––- 1 root root 26785659 Dec 17 03:12 initramfs-2.6.32-642.6.2.el6.x86_64.tmp

După cum puteți observa din output-ul de mai sus, avem câteva fișiere initramfs pentru kernel-urile mai vechi, dar lipsește fișierul pentru cel mai nou kernel 2.6.32-696.6.3.el6.x86_64.

S-a încercat crearea manuală a fișierului initramfs

Când am încercat să creez manual fișierul initramfs pentru noul kernel, comanda „dracut” a eșuat.

[ssuri@linuxnix:/boot] $ sudo dracut -f /boot/initramfs-2.6.32-696.6.3.el6.x86_64.img 2.6.32-696.6.3.el6.x86_64

mktemp: failed to create directory via template `/tmp/initramfs.XXXXXX’: No space left on device
chmod: cannot access `’: No such file or directory
usage: plymouth [ –verbose | -v ] { –targetdir | -t }

cp: `/etc/ld.so.conf’ and `/etc/ld.so.conf’ are the same file
cp: `/etc/ld.so.conf.d’ and `/etc/ld.so.conf.d’ are the same file
find: cannot search `’: No such file or directory
cpio: File ./initramfs-2.6.32-696.6.3.el6.x86_64.img grew, 19316736 new bytes not copied

S-a căutat cauza lipsei fișierului initramfs

Eroarea în comanda „dracut” menționată anterior m-a determinat să verific starea sistemului de fișiere / tmp. Deși sistemul de fișiere a avut o mulțime de spațiu de stocare disponibil, a ieșit din inode-uri ceea ce a cauzat imposibilitatea creerii de noi fișiere temporare care ar fi putut fi necesare către comanda „dracut”.

[ssuri@linuxnix:/boot] $ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/os_pvp1 493M 159M 309M 34% /boot
[ssuri@linuxnix:/boot] $
[ssuri@linuxnix:~] $ df -hi /tmp
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/os_vg-tmp_lv
128K 128K 0 100% /tmp

Eliberați inodes în / tmp și creați fișierul initramfs

Imediat după vizualizarea stării inode pentru sistemul de fișiere / tmp, am continuat să îl curăț.

[ssuri@linuxnix:~] $ df -hi /tmp
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/os_vg-tmp_lv
128K 232 128K 1% /tmp
[ssuri@linuxnix:~] $

Odată ce s-au eliberat inode-urile, am creat fișierul initramfs așa cum se arată în comanda de mai jos.

[ssuri@linuxnix:/boot] $ sudo dracut -f /boot/initramfs-2.6.32-696.6.3.el6.x86_64.img 2.6.32-696.6.3.el6.x86_64
[ssuri@linuxnix:/boot] $ ls -ltr | grep -i initramfs
-rw––- 1 root root 26654700 Dec 11 2016 initramfs-2.6.32-642.6.2.el6.x86_64.img
-rw––- 1 root root 26088799 Jan 8 2017 initramfs-2.6.32-573.1.1.el6.x86_64.tmp
-rw––- 1 root root 26781018 Jun 11 2017 initramfs-2.6.32-642.13.1.el6.x86_64.img
-rw––- 1 root root 26088606 Dec 17 03:11 initramfs-2.6.32-573.18.1.el6.x86_64.tmp
-rw––- 1 root root 26785659 Dec 17 03:12 initramfs-2.6.32-642.6.2.el6.x86_64.tmp
-rw––- 1 root root 25606929 Jan 14 06:51 initramfs-2.6.32-696.6.3.el6.x86_64.img

Comanda dracut a adăugat automat intrarea pentru fișierul initramfs pentru noul kernel din fișierul /boot/grub/grub.conf care mai lipsea mai devreme.

[ssuri@linuxnix:~] $ sudo cat /etc/grub.conf

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd3,0)
# kernel /vmlinuz-version ro root=/dev/mapper/os_vg-root_lv
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=50
#splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu

initrd /initramfs-2.6.32-573.1.1.el6.x86_64.img
[ssuri@linuxnix:~] $

Am pornit sistemul cu noul kernel

Am restartat sistemul din nou și de această dată serverul a reușit să ruleze cu succes pe noul kernel.

Concluzie

Scenariul pe care l-am discutat în acest articol poate părea neobișnuit, dar cu siguranță nu este improbabil. S-ar putea să existe o serie de scenarii care ar putea necesita reconstruirea fișierului initramfs și am demonstrat un astfel de scenariu în acest articol. Sperăm că ați găsit explicația și demonstrația utile și așteptăm cu nerăbdare feedback-ul dvs.