Το Linux λαμβάνει διπλή γρήγορη διπλή ενημέρωση για να διορθώσει τον πυρήνα Ωχ!

Το Linux λαμβάνει διπλή γρήγορη διπλή ενημέρωση για να διορθώσει τον πυρήνα Ωχ!

Χρονική σήμανση: 13 Μαρτίου 2023 3:59 μ.μ.
Το Linux λαμβάνει διπλή γρήγορη διπλή ενημέρωση για να διορθώσει τον πυρήνα Ωχ! Ευφυΐα Δεδομένων PlatoBlockchain. Κάθετη αναζήτηση. Ολα συμπεριλαμβάνονται.
by Πολ Ντόκλιν

Το Linux δεν υπέφερε ποτέ από το διαβόητο BSoD, συντομογραφία του Μπλε οθόνη του θανάτου, το όνομα που δόθηκε στο επίφοβο μήνυμα "κάτι πήγε τρομερά λάθος" που σχετίζεται με ένα σφάλμα συστήματος των Windows.

Η Microsoft έχει δοκιμάσει πολλά πράγματα όλα αυτά τα χρόνια για να κουνήσει αυτό το ψευδώνυμο "BSoD", συμπεριλαμβανομένης της αλλαγής του χρώματος φόντου που χρησιμοποιείται όταν εμφανίζονται μηνύματα σύγκρουσης, προσθέτοντας ένα εικονίδιο λυπητερού προσώπου για να κάνει το μήνυμα πιο συμπονετικό, εμφανίζοντας κωδικούς QR που μπορείτε κουμπώστε με το τηλέφωνό σας για να σας βοηθήσει να διαγνώσετε το πρόβλημα και να μην γεμίσετε την οθόνη με μια λίστα technobabble αντικειμένων κώδικα πυρήνα που μόλις έτυχε να φορτωθούν εκείνη τη στιγμή.

(Αυτές οι λίστες απόρριψης σφαλμάτων συχνά οδηγούσαν στο λογισμικό προστασίας από ιούς και πρόληψης απειλών να κατηγορείται για κάθε σφάλμα συστήματος, απλώς επειδή τα ονόματά τους έτειναν να εμφανίζονται στην κορυφή ή κοντά στην κορυφή της λίστας των φορτωμένων λειτουργικών μονάδων – όχι επειδή είχαν κάτι να κάνουν με τη συντριβή, αλλά επειδή γενικά φόρτωσαν νωρίς και απλώς έτυχε να βρίσκονται στην κορυφή της λίστας, δημιουργώντας έτσι έναν βολικό αποδιοπομπαίο τράγο.)

Ακόμα καλύτερα, το "BSoD" δεν είναι πλέον ο καθημερινός, πετυχημένος υποτιμητικός όρος που ήταν, επειδή τα Windows κολλάνε πολύ λιγότερο συχνά από ό,τι παλιά.

Δεν προτείνουμε ότι τα Windows δεν διακόπτονται ποτέ, ούτε υπονοούμε ότι είναι πλέον χωρίς σφάλματα ως δια μαγείας. Σημειώνοντας απλώς ότι γενικά δεν χρειάζεστε τη λέξη BSoD τόσο συχνά όσο παλιά.

Ειδοποιήσεις σφαλμάτων Linux

Φυσικά, το Linux δεν είχε ποτέ BSoD, ούτε καν όταν τα Windows φαινόταν να τα έχουν συνεχώς, αλλά αυτό δεν συμβαίνει επειδή το Linux δεν κολλάει ποτέ ή είναι ως δια μαγείας χωρίς σφάλματα.

Απλώς, το Linux δεν κάνει BSoD (ναι, ο όρος μπορεί να χρησιμοποιηθεί ως αμετάβατο ρήμα, όπως στο "ο φορητός μου υπολογιστής BSoDded στα μισά του email"), γιατί – σε μια ευχάριστη συγκατάθεση – υποφέρει ουπς, ή εάν το ουπς είναι αρκετά σοβαρό ώστε το σύστημα να μην μπορεί να παραμείνει αξιόπιστα ακόμα και με υποβαθμισμένη απόδοση, πανικοβάλλονται.

(Είναι επίσης δυνατό να διαμορφώσετε έναν πυρήνα Linux έτσι ώστε ένα ουπς πάντα «προβιβάζεσαι» σε α πανικός, για περιβάλλοντα όπου οι λόγοι ασφαλείας καθιστούν καλύτερο να υπάρχει ένα σύστημα που κλείνει απότομα, αν και ορισμένα δεδομένα δεν αποθηκεύονται εγκαίρως, παρά ένα σύστημα που καταλήγει σε αβέβαιη κατάσταση που θα μπορούσε να οδηγήσει σε διαρροή δεδομένων ή καταστροφή δεδομένων.)

An ουπς συνήθως παράγει έξοδο κονσόλας κάτι σαν αυτό (παρέχουμε τον πηγαίο κώδικα παρακάτω αν θέλετε να εξερευνήσετε ουπς και πανικοβάλλονται για τον εαυτό σου):

[12710.153112] ωχ init (επίπεδο = 1) [12710.153115] ενεργοποίηση oops μέσω BUG() [12710.153127] -------------[ κόψτε εδώ ]------------- [12710.153128] ΣΦΑΛΜΑ πυρήνα στο /home/duck/Articles/linuxoops/oops.c:17! [12710.153132] μη έγκυρος κωδικός ενεργοποίησης: 0000 [#1] PREEMPT SMP PTI [12710.153748] CPU: 0 PID: 5531 Comm: insmod . . . [12710.154322] Όνομα υλικού: XXXX [12710.154940] RIP: 0010:oopsinit+0x3a/0xfc0 [oops] [12710.155548] Κωδικός: . . . . . [12710.156191] RSP: . . . ΕΣΗΜΑΙΑ: . . . [12710.156849] RAX: . . . RBX: . . . RCX: . . . [12710.157513] RDX: . . . RSI: . . . RDI: . . . [12710.158171] RBP: . . . R08: . . . R09: . . . [12710.158826] R10: . . . R11: . . . R12: . . . [12710.159483] R13: . . . R14: . . . R15: . . . [12710.160143] FS: . . . ΓΣ: . . . knlGS: . . . . . . . . [12710.163474] Call Trace: [12710.164129] [12710.164779] do_one_initcall+0x56/0x230 [12710.165424] do_init_module+0x4a/0x210 [12710.166050] __do_sys_finit_module+0x9e/0xf0 [12710.166711] do_syscall_64+0x37/0x90 [12710.167320] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 12710.167958] RIP: 0033:0x7f6c28b15e39 [12710.168578] Κωδικός: . . . . . [. . . . . [12710.173349] [12710.174032] Ενότητες συνδεδεμένες σε: . . . . . [12710.180294] ---[ ίχνος τέλους 0000000000000000 ]---

Δυστυχώς, όταν κυκλοφόρησε η έκδοση 6.2.3 του πυρήνα στα τέλη της περασμένης εβδομάδας, αποδείχθηκαν γρήγορα δύο μικρές αλλαγές προβληματικός, με τους χρήστες να αναφέρουν όψεις του πυρήνα κατά τη διαχείριση της αποθήκευσης δίσκου.

Ο πυρήνας 6.1.16 προφανώς υπόκειται στις ίδιες αλλαγές, και επομένως επιρρεπής στην ίδια αδυναμία.

Για παράδειγμα, η σύνδεση μιας αφαιρούμενης μονάδας και η τοποθέτησή της λειτούργησε μια χαρά, αλλά η αποσυναρμολόγηση της μονάδας όταν τελειώσατε με αυτήν θα μπορούσε να προκαλέσει ουπς.

Παρόλο που ένα ωχ δεν παγώνει αμέσως ολόκληρο τον υπολογιστή, ο κώδικας σε επίπεδο πυρήνα διακόπτεται κατά την αφαίρεση του αποθηκευτικού χώρου του δίσκου είναι αρκετά ανησυχητικό που ένας καλά ενημερωμένος χρήστης θα ήθελε πιθανώς να τερματίσει τη λειτουργία του το συντομότερο δυνατό, σε περίπτωση συνεχούς προβλήματος που οδηγεί σε καταστροφή δεδομένων …

…αλλά μερικοί χρήστες ανέφεραν ότι το ουπς απέτρεψε αυτό που στην ορολογία είναι γνωστό ως an τακτική διακοπή λειτουργίας, που απαιτεί αναγκαστική ανακύκλωση της τροφοδοσίας, κρατώντας πατημένο το κουμπί λειτουργίας για αρκετά δευτερόλεπτα ή διακόπτοντας προσωρινά την παροχή ρεύματος σε έναν διακομιστή.

Τα καλά νέα είναι ότι οι πυρήνες 6.2.4 και 6.1.17 αφέθηκαν αμέσως ελεύθεροι το Σαββατοκύριακο για να αποκαταστήσουν τα προβλήματα.

Δεδομένης της ταχύτητας των εκδόσεων του πυρήνα Linux, αυτές οι ενημερώσεις έχουν ήδη ακολουθηθεί 6.2.5 και 6.1.18, τα οποία ενημερώθηκαν οι ίδιοι (σήμερα, 2023-03-13) από 6.2.6 και 6.1.19.

Τι να κάνω;

Εάν χρησιμοποιείτε πυρήνα Linux έκδοσης 6.x και δεν είστε ήδη ενημερωμένοι, φροντίστε να μην εγκαταστήσετε την 6.2.3 ή την 6.1.16 στην πορεία.

Εάν έχετε ήδη μία από αυτές τις εκδόσεις (είχαμε 6.2.3 για μερικές μέρες και δεν καταφέραμε να προκαλέσουμε σύγκρουση προγράμματος οδήγησης, πιθανώς επειδή η διαμόρφωση του πυρήνα μας προστατεύει κατά λάθος από την ενεργοποίηση του σφάλματος), σκεφτείτε να ενημερώσετε το συντομότερο δυνατό…

…επειδή ακόμα κι αν δεν έχετε αντιμετωπίσει κανένα πρόβλημα με βάση τον όγκο δίσκου μέχρι στιγμής, μπορεί να έχετε ανοσία από καλή τύχη, αλλά αναβαθμίζοντας ξανά τον πυρήνα σας θα γίνετε άνοσοι από το σχεδιασμό.

ΕΞΕΡΕΥΝΗΣΕΙΣ ΜΟΝΟΙ ΣΟΥ ΟΥΠΣ ΚΑΙ ΓΕΓΟΝΟΤΑ ΠΑΝΙΚΟΥ

Θα χρειαστείτε έναν πυρήνα κατασκευασμένο από πηγαίο κώδικα που είναι ήδη εγκατεστημένος στον δοκιμαστικό υπολογιστή σας.

Δημιουργήστε έναν κατάλογο, ας τον ονομάσουμε /test/oopsκαι αποθηκεύστε αυτόν τον πηγαίο κώδικα ως oops.c:

#include <linux/kernel.h> #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/init.h> MODULE_LICENSE("GPL"); static int level = 0;
module_param(level,int,0660); static int oopsinit(void) { printk("oops init (level = %d)n",level); // level: 0->just load; 1->oops; 2->panic switch (level) { case 1: printk("triggering oops via BUG()n"); BUG(); break; case 2: printk("forcing a full-on panic()n"); panic("oops module"); break; } return 0; } static void oopsexit(void) { printk("oops exitn"); } module_init(oopsinit); module_exit(oopsexit);

Δημιουργήστε ένα αρχείο στον ίδιο κατάλογο που ονομάζεται Kbuild για να ελέγξετε τις παραμέτρους κατασκευής, ως εξής:

 EXTRA_CFLAGS = -Wall -g obj-m = oops.o

Στη συνέχεια, δημιουργήστε τη μονάδα όπως φαίνεται παρακάτω.

Η -C η επιλογή λέει make πού να αρχίσετε να ψάχνετε Makefiles, δείχνοντας έτσι τη διαδικασία κατασκευής στο δεξί δέντρο πηγαίου κώδικα του πυρήνα και το M= η ρύθμιση λέει make πού να βρείτε τον πραγματικό κώδικα της ενότητας που θα δημιουργήσετε σε αυτήν την περίπτωση.

Πρέπει να παρέχετε την πλήρη, απόλυτη διαδρομή για M=, επομένως μην προσπαθήσετε να αποθηκεύσετε την πληκτρολόγηση χρησιμοποιώντας ./ (ο τρέχων κατάλογος μετακινείται κατά τη διάρκεια της διαδικασίας κατασκευής):

/test/oops$ make -C /where/you/built/the/kernel M=/test/oops CC [M] /home/duck/Articles/linuxoops/oops.o MODPOST /home/duck/Articles/linuxoops/ Module.symvers CC [M] /home/duck/Articles/linuxoops/oops.mod.o LD [M] /home/duck/Articles/linuxoops/oops.ko

Μπορείτε να φορτώσετε και να ξεφορτώσετε το νέο oops.ko μονάδα πυρήνα με την παράμετρο level=0 απλά για να ελέγξω ότι λειτουργεί.

Κοιτάξτε μέσα dmesg για ένα ημερολόγιο του init και exit κλήσεις:

/test/oops# insmod oops.ko level=0 /test/oops# rmmod oops /test/oops# dmesg . . . [12690.998373] ωχ: φόρτωση της μονάδας εκτός δέντρου αλλοιώνει τον πυρήνα. [12690.999113] ουπς init (επίπεδο = 0) [12704.198814] ωχ έξοδος

Να προκαλέσει ένα ουπς (ανακτήσιμο) ή α πανικός (θα κρεμάσει τον υπολογιστή σας), χρησιμοποιήστε level=1 or level=2 αντίστοιχα.

Μην ξεχάσετε να αποθηκεύσετε όλη την εργασία σας πριν ενεργοποιήσετε οποιαδήποτε συνθήκη (θα χρειαστεί να κάνετε επανεκκίνηση στη συνέχεια) και μην το κάνετε στον υπολογιστή κάποιου άλλου χωρίς επίσημη άδεια.

Σφραγίδα ώρας:

Περισσότερα από Γυμνή ασφάλεια