Απορίες Windows :-)

[Apollon Oikonomopoulos]

On 13:28 Wed 24 Feb     , Antonis Christofides wrote:
> Μου έχει τύχει νομίζω όταν προσπαθεί να μπουτάρει ένα λίνουξ να βγάνει
> kernel panic επειδή π.χ. δεν έχει κάποιο SATA driver που θα του
> επιτρέψει να mount το root file system. Το ίδιο το έχω δει και σε
> Windows (όταν εγκαθιστώ Windows από image). Μιλάω για περιπτώσεις που
> το root file system είναι ένα απλό ext3 στον ίδιο δίσκο που είναι και
> το /boot (σε περιπτώσεις που είναι XFS over LVM over soft RAID
> καταλαβαίνω πολύ καλά το πρόβλημα).
> 
> Η απορία μου είναι: αφού ο boot loader έχει καταφέρει να φορτώσει τον
> kernel από το /boot, και ο kernel έχει καταφέρει να φορτώσει το
> initrd.img από το /boot, αυτό σημαίνει ότι ήδη ο kernel (πριν διαβάσει
> το initrd.img) είναι σε θέση να διαβάζει δεδομένα από το δίσκο (έστω
> και με κάποιον μη βέλτιστο generic driver). Γιατί λοιπόν για να
> συνεχίσει θέλει οπωσδήποτε έναν άλλο driver;

Το θέμα είναι ότι ο kernel όταν ξεκινάει, ξεκινάει από τη μνήμη και όχι από το
δίσκο. Η διαδικασία χοντρικά προβλέπει ότι ο bootloader (GRUB, Lilo,
isolinux, οτιδήποτε άλλο) ξέρει τα απολύτως απαραίτητα για να μπορέσει να βρει
το αρχείο του πυρήνα *και του initrd*, τα αντιγράφει στη μνήμης και μετά
κάνει jmp στη θέση μνήμης όπου είναι το entry point του πυρήνα. Επομένως, ο
πυρήνας «ξυπνώντας» δεν έχει ιδέα για το τι έχει προηγηθεί και πρέπει να κάτσει
μόνος του να ανακαλύψει το σύμπαν, τον τροχό και τον σκληρό δίσκο. Συγκεκριμένα
δε στο PC, όλη η διαδικασία του loader γίνεται σε real mode (σχεδόν, γιατί
υπάρχουν κάποια θέματα με τους σημερινούς μεγάλους πυρήνες και το addressing σε
real mode), όπου η εικόνα του κόσμου είναι τελείως διαφορετική, ενώ το Linux
και όλοι οι drivers του είναι σχεδιασμένα για να τρέχουν σε protected mode,
επομένως ό,τι έχει προηγηθεί του πυρήνα είναι διπλά άχρηστο.

> 
> Η άλλη απορία είναι πιο Windows, και τη σκέφτηκα όταν σύγκρινα το
> kernel panic σε Linux και Windows. Τα Windows μπορούν (και by default
> το κάνουν) σε περίπτωση μπλε οθόνης να γράψουν στο δίσκο ένα memory
> dump, που είναι χρήσιμο γιατί μετά το εξετάζεις και βρίσκεις stack
> trace κλπ. Το Linux απ' όσο ξέρω δεν το κάνει αυτό (αν και σου δίνει
> το stack trace στην οθόνη απ' ό,τι θυμάμαι). Αν όμως ο kernel είναι σε
> θέση να ανοίξει ένα αρχείο στο NTFS και να γράψει εκεί το memory dump,
> μια δηλαδή αρκετά μεγάλη διαδικασία που πρέπει να περιλαμβάνει ποιος
> ξέρει πόσους driver και πόσα επίπεδα λειτουργίας, τότε τι σόι panic
> είναι αυτό; Εφόσον βρισκόμαστε σε κατάσταση kernel panic, δεν είναι
> επικίνδυνο να γράφουμε αρχείο στο δίσκο;

Αφενός δεν είναι όλα τα panics ίδια, αφετέρου ούτε όλα τα λειτουργικά
συμπεριφέρονται με τον ίδιο τρόπο. Και στο Linux υπάρχει περίπτωση να πάνε
διάφορα πράματα στραβά και να εξακολουθήσει να λειτουργεί το σύστημα (τα
περήφιμα μηνύματα τύπου "Dazed and confused, but trying to continue" ή "Fixing
recursively, but a reboot is needed"). Τώρα για το πως το κάνουν τα windows
ακριβώς δε γνωρίζω, αλλά στο Linux γίνεται κάτι αντίστοιχο εκτελώντας έναν
"crash" kernel με kexec (kdump[1]). Με λίγα λόγια, μπορείς να πεις στον Linux
kernel σε περίπτωση kernel panic να κάνει kexec() έναν νέο πυρήνα,
προ-φορτωμένο στη μνήμη, ο οποίος θα έχει μετά στη διάθεσή του το core image
του kernel που αστόχησε.

/Απόλλων

[1] http://lse.sourceforge.net/kdump/