Αυτή η ανάρτηση είναι να δείξει πώς να "διορθώσετε" σχεδόν το πρόβλημα των εκκινήσεων με σφάλματα Arch Linux. Κάτι σαν την ακόλουθη εικόνα:
Όπως φαίνεται, βλέπουμε ότι αυτός είναι ένας από τους πολλούς "συνδυασμούς" σφαλμάτων που εμφανίζονται τυχαία κατά την εκκίνηση ενός λειτουργικού συστήματος με αυτό το πρόβλημα. Όπως λέει σε αυτό το σφάλμα, υποδηλώνει ότι μπορεί να υπάρχει πρόβλημα στο "Hardware", ωστόσο, όπως όλοι γνωρίζουμε σε αυτό το λειτουργικό σύστημα, ακόμη και τα κακά κόλπα αυτού που δεν ανήκει στο λειτουργικό σύστημα μπορούν να λυθούν.
Έτσι, θα περιγράψω την εμπειρία μου για αυτό το πρόβλημα. Από αυτό που μπορούσα να βιώσω, το πρόβλημα ήταν μόνο με Arch Linux ή μια άλλη διανομή που δοκίμασα εξωτερικά, καθώς με οποιοδήποτε Ubuntu που είχα εγκαταστήσει ή δοκιμάσει, ξεκίνησε χωρίς προβλήματα. Αλλά αν προσπαθούσα να σχίσει το Arch Linux Εγκατεστημένο στον σκληρό δίσκο, είχα ένα πρόβλημα που έπρεπε να επανεκκινήσω περίπου 50 φορές για να μπορέσει το OS να εκκινήσει κανονικά και να το χρησιμοποιήσει.
Αυτό είχε ήδη κάτι λάθος μαζί μου γιατί μπορούσα να χρησιμοποιήσω το ubuntu που είχα εγκαταστήσει για να το δοκιμάσω και δεν μπορούσα να κάνω ούτε τα μισά από τα πράγματα που μπορούσα να κάνω Arch Linux. Αποφάσισα λοιπόν να λύσω αυτό το πρόβλημα και άρχισα να ερευνώ, ψάχνοντας για νήματα φόρουμ που είχαν το ίδιο πρόβλημα, ανέφεραν επίσης ότι ήταν σφάλμα υλικού και ότι ήταν ακριβώς η CPU, οπότε άρχισε να με ανησυχεί, οπότε πήρα ανοίξτε τον υπολογιστή και επιβεβαιώστε τι συνέβαινε, ωστόσο, δεν βοήθησε.
Αλλά κάτι που μου έδειξε ότι δεν πρέπει να τα παρατήσω ήταν αν Ubuntu Θα μπορούσα γιατί Arch Linux όχι (ίσως Ubuntu είναι καλύτερο από αψίδα…;). Άρχισα λοιπόν να γράφω παραμέτρους εκκίνησης στον πυρήνα του Arch Linux, πράγματα όπως: lapic, nomce, intel_idle.max_cstate=0, disable_cpu_apic, acpi_skip_timer_override, acpi=stric, clk, apm, noapic, acpi=oldboot, acpi-cpufreq, intel_pstate=απενεργοποίηση, i8042.noacpy_n=α, i1.noacpy_n= r,p. hgb, acpi=δύναμη, pnpacpi=0ff και άλλα περισσότερα ... Όλα αυτά προτάθηκαν στα φόρουμ που διάβασα.
Μέχρι να έπρεπε να εισαγάγω την τεκμηρίωση των παραμέτρων του πυρήνα, την οποία προτείνω παρεμπιπτόντως: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Και βρήκα μια αρκετά ενδιαφέρουσα παράμετρο που προς το παρόν κατάφερα να εκκινήσω Arch Linux Κανένα πρόβλημα:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Όπως υποδεικνύεται εκεί, αυτό που κάνει αυτή η παράμετρος είναι να περιορίσει τη χρήση σε ένα cpu χωρίς να ενεργοποιηθεί ο συμμετρικός τρόπος επεξεργασίας. Στην αρχή λειτούργησε αρκετά καλά μέχρι που χρησιμοποίησα την εντολή pacman-Syyu; με πέταξε ένα ο πυρήνας απορρίφθηκε o σφάλμα κατάτμησης.
Έτσι, παρατήρησα αυτόματα ότι κάτι περίεργο συνέβαινε, έτσι άρχισα να τρέχω άλλες διαδικασίες μέχρι ξαφνικά το σύστημα να παγώσει εντελώς και να μην λειτουργεί πια, μέχρι να το επανεκκινήσω. Έτσι έκανα την ίδια λειτουργία, αλλά αυτή τη φορά κατάφερα να εκτελέσω htop και μου έδειξε τα εξής:
Όπως ήταν αναμενόμενο, έδειξε μόνο μια CPU, καθώς η άλλη την είχε απενεργοποιήσει, ωστόσο, μου φαινόταν πολύ παράξενο γιατί τα προγράμματα έριξαν προεπιλογή, και δεν μπορούσα καν να ξεκινήσω το γραφικό περιβάλλον. οπότε ήταν κάτι που μου έδωσε τουλάχιστον περισσότερη ελπίδα ότι αν ορίσω τις παραμέτρους του πυρήνα με έναν τρόπο θα εκκινήσει το δικό μου Arch Linux ως συνήθως.
Γι 'αυτό συνέχισα να δοκιμάζω τις άλλες παραμέτρους που έγραψα στη λίστα μέχρι που συνάντησα αυτήν, που είναι η καλύτερη λύση αυτή τη στιγμή:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Αυτή η παράμετρος κάνει κάτι τόσο απλό όσο η απομόνωση (όχι απενεργοποίηση) του δεύτερου πυρήνα της CPU στη συμμετρική επεξεργασία, δηλαδή, το φορτίο επεξεργασίας δίνεται σε έναν μόνο πυρήνα ενώ ο άλλος είναι μόνο συμπληρωματικός. Αυτό, αν και φαίνεται αντιφατικό, δεν επηρεάζει τόσο την απόδοση, αφού αυτό το υπέροχο λειτουργικό σύστημα ήταν σε θέση να εκτελεί εφαρμογές με αυτόν τον τρόπο:
Έτσι με αυτό, το μόνο πρόβλημα που παρατήρησα που εμφανίζεται κατά την εκκίνηση, είναι ένας ή δύο πυρήνες πανικού ή ουπς. αλλά σε σύγκριση με τις 50 φορές που έπρεπε να επανεκκινήσω προηγουμένως, μπορώ να το θεωρήσω "λύση". Για τα υπόλοιπα, μέχρι τώρα μου επέτρεψε να χρησιμοποιήσω το λειτουργικό σύστημα και να γράψω αυτήν την ανάρτηση που διαβάζετε τώρα :-).
Ελπίζω να σας βοηθήσουν και να μην ξεφύγετε GNU / Linux, το οποίο είναι το καλύτερο λειτουργικό σύστημα που έχουν εφεύρει ποτέ. Το λέω σίγουρα.
Πολύ ενδιαφέρουσες πληροφορίες. Ποτέ δεν είχα αυτούς τους πανικούς πυρήνα στο ArchLinux τα χρόνια που το χρησιμοποιώ, αλλά είναι καλό να γνωρίζουμε τι να κάνω εάν σε οποιοδήποτε σημείο παρουσιαστεί το πρόβλημα. Ευχαριστώ!
Τέλος πάντων, χρησιμοποιώ Arch για μεγάλο χρονικό διάστημα (ήμουν σαν 1 έτος χωρίς Arch) και χωρίς πανικό πυρήνα.
Ευχαριστώ για την συμβουλή.
Πιθανότατα, όπως ανέφερα στην ανάρτηση, το πρόβλημα συμβαίνει λόγω του υλικού, γιατί σε αυτό που χρησιμοποιώ αψίδα, δεν μου είχε δώσει κανένα πρόβλημα αυτού του τύπου.
Ένα άλλο με εξαιρετικά αποτελέσματα στο Arch. Δεν είχα ποτέ έναν Πυρήνα Πυρήνα
Περισσότερα από 2 χρόνια με το GNU / Linux ... 2 χρόνια ήδη με το ArchLinux, ποτέ δεν υπάρχει πανικός πυρήνα .. 😉
Νομίζω ότι οι πανικοί του πυρήνα οφείλονται περισσότερο στο υλικό παρά στο ίδιο το distro. Δεν έχω δει ποτέ έναν πυρήνα πανικού στο φορητό υπολογιστή που χρησιμοποιώ τώρα, εκτός από τη στιγμή που έβαλα ένα Ubuntu άλφα σε αυτό (και το Arch Linux ήταν εδώ και για δύο χρόνια). Από την άλλη πλευρά, σε έναν άλλο φορητό υπολογιστή που έχω, κάθε διανομή που έβαλα πάντα δίνει πανικό στον πυρήνα και μεγάλη ποικιλία σφαλμάτων για όλα τα γούστα.
Με τον πυρήνα 3.14 στο Debian, έχω αντιμετωπίσει το πρόβλημα πανικού πυρήνα, εκτός από αυτό κάθε φορά που ενεργοποιώ τον υπολογιστή μου, λαμβάνω ένα μήνυμα "σύνδεση / αποσύνδεση χρονικού ορίου" (και επίσης όταν το απενεργοποιώ).
Μου έχει συμβεί τόσο πολύ στο Fedora όσο και στο Arch, αλλά δεν ξέρω γιατί και πώς δεν βλέπω μια διαφορά αφού δεν έχω περάσει χρόνο να το διερευνήσω ή να το λύσω (αν πρόκειται για πρόβλημα).
Νομίζω ότι ο λόγος είναι ότι συντάσσονται με gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Ευχαριστώ πολύ για τις πληροφορίες. Μερικά από τα πολλά πράγματα για τα οποία μπορούμε να καυχηθούμε είναι αυτός ο τύπος φόρουμ
Γιατί συμβαίνει αυτό στο Arch Linux; Ίσως δεν αρκεί με τα προβλήματα που εμφανίζονται συχνά με τη βραδύτητα ή την ανάρτηση του συστήματος που φτάνει στο σημείο της ρίψης του συστήματος στο ταραχή.
Γεια; Για τι πράγμα μιλάς? ο_Ο
Το Arch είναι μια διανομή KISS διαμορφώσιμη από τη βάση του ίδιου του λειτουργικού συστήματος, με λίγα λόγια, εάν το σύστημα είναι βαρύ είναι επειδή το φτιάξατε έτσι, εάν το σύστημα έχει σφάλματα είναι επειδή τα δημιουργήσατε ή επειδή δεν το κάνατε διαμορφώστε σωστά κάτι Το Arch wiki είναι αρκετά ολοκληρωμένο, πριν από μερικά χρόνια δεν υπήρχαν πολλά σημαντικά θέματα στα Ισπανικά, αυτό και η διαδικασία εγκατάστασης ήταν πολύ πιο δύσκολη και κάπως δύσκολη, τώρα όλα είναι λίγο πιο αυτοματοποιημένα.
Το να κατηγορείτε τη διανομή για σφάλματα χρήστη είναι τόσο… Windows (?).
Το να κατηγορείτε τη διανομή για σφάλματα είναι συνεπές, απλώς και μόνο επειδή είναι η αλήθεια. Αφού είχα ένα παρόμοιο πρόβλημα με τον Manjaro, δοκίμασα τον Arch, τον Antergos και μια άλλη άγνωστη διανομή (δεν θυμάμαι τώρα το όνομα, συγγνώμη) που κάποιος μου πρότεινε να μου διαβεβαιώσει ότι δεν έδωσε προβλήματα, αλλά τίποτα. το δίνουν όλοι. Σε OpenSuse, Fedora, Mint, Mageia και όλα αυτά που έχω δοκιμάσει μετά, αυτό δεν συμβαίνει. Οπότε, για μένα, δεν έχω άλλη επιλογή από το να πιστεύω ότι είναι λάθος του διανομέα. Όμως, δεν το δαιμονοποιώ ούτε οτιδήποτε άλλο, με ενοχλεί που δεν μπορώ να χρησιμοποιήσω τίποτα βάσει του Arch, γιατί μου αρέσει πολύ, αλλά αυτό το καταραμένο πρόβλημα με εμποδίζει. Ούτε νομίζω ότι αφορά το υλικό, γιατί πολλοί από εμάς που συμβαίνουν σε εμάς δεν συνέβησαν πριν χρησιμοποιήσουν το ίδιο γαμημένο. Λοιπόν, στην πραγματικότητα πρέπει να είναι κάτι που σχετίζεται με το υλικό, αλλά, επιστρέφοντας στο ίδιο πράγμα, εάν δεν έχω κάνει αλλαγές και έχω προβλήματα με τον ίδιο εξοπλισμό με τον οποίο δεν τις είχα πριν, προφανώς θα οφείλεται σε μια αλλαγή που έκανε ο Arch που με βρήκε.
"Το να κατηγορούμε τη διανομή για σφάλματα χρήστη είναι τόσο ... Windows (?)."
Θα σας έλεγα ότι η ευθύνη των χρηστών για σφάλματα προϊόντων είναι τόσο Apple. Έχω ειλικρινά το σκεφτεί χιλιάδες φορές, αλλά δεν βλέπω το πλεονέκτημα να χρησιμοποιώ κάτι του οποίου οι συντηρητές βασικά πλένουν τα χέρια τους, για οποιοδήποτε σοβαρό σκοπό. Και λέω ότι λαμβάνοντας υπόψη ότι το λογισμικό GPL παρέχεται χωρίς εγγύηση.
Μπορείτε να πείτε όπως θέλετε, αλλά αν είναι η ίδια περίπτωση των αναφορών έλλειψης σήματος στο iPhone και η απάντηση της Apple "είναι ότι το παίρνετε λάθος" πριν από αρκετά χρόνια. Εάν κάνετε μια διανομή, συνήθως θέλετε να παρέχετε κάποια ποιότητα και ελάχιστη υποστήριξη, και η αλήθεια είναι ότι το Arch είναι βασικά ένα σύστημα χόμπι, όπου βλέπετε ότι οι προγραμματιστές της έχουν διασκεδαστική συσκευασία νέων πραγμάτων, αλλά έχουν μικρό ενδιαφέρον να προσφέρουν μια πραγματική υποστήριξη . Κάθε φορά που βλέπω αυτόν τον τύπο ανάρτησης, εκτιμώ περισσότερο τη δουλειά πίσω από τη διανομή που χρησιμοποιώ.
Και ναι, είναι πρόβλημα λογισμικού εάν δεν λειτουργεί, εάν σταματήσει να λειτουργεί σε μια ενημέρωση ή εάν σπάσει κάτι από το υλικό. Ότι ένας διανομέας πανικού πυρήνα ενώ ένας άλλος δεν… καλά, ναι, σαφώς υπάρχει μια διανομή που κάνει τα πράγματα σωστά και ένα άλλο λάθος. Τώρα αν είναι χαρά σας να χρησιμοποιήσετε το Linux με το στυλ της δεκαετίας του '90 όπου έπρεπε να μεταγλωττίσουμε ξανά τον πυρήνα κάθε φορά που συνδέσαμε έναν νέο εκτυπωτή ... εκεί εσείς.
Ο πυρήνας συντάχθηκε από τους προγραμματιστές; ή το δικό σας;
Οι πανικοί του πυρήνα δημιουργούνται επειδή δεν έχουν επιλέξει (AND) ορισμένα στοιχεία κατά τη μεταγλώττιση, ή επειδή δεν έχουν ενεργοποιήσει ορισμένες μονάδες για την υποστήριξη συγκεκριμένου υλικού. Με την πρακτική και τη γνώση του υλικού σας (πρέπει να ανοίξετε τον υπολογιστή και να δείτε ποιες μάρκες μαρκών διαθέτει), μπορείτε να δημιουργήσετε έναν προσαρμοσμένο πυρήνα (με chrooting). Εάν το Ubuntu και το CD εγκατάστασης Arch ήταν στον υπολογιστή σας, υπάρχει κάτι στη συλλογή που δεν είναι ενεργοποιημένη.
Ήταν ο πυρήνας του αποθέματος από το ίδιο το archlinux, από τα αποθετήρια.
Ο πυρήνας που χρησιμοποιείτε, έχει απομείνει κάτι που δεν του αρέσει το υλικό σας, πρέπει να έχετε μια σπάνια έκδοση ενός τσιπ στη μητρική σας πλακέτα ή ακόμη και ένα σφάλμα σε ένα τσιπ (συνήθως συμβαίνει).
Μπορεί να είναι ένας κατεστραμμένος πίνακας στο bios acpi σας, είναι φυσιολογικό ότι οι Κινέζοι που είναι εν ενεργεία δεν υπολογίζουν καν καλά το άθροισμα ελέγχου κάθε πίνακα, αυτά τα μηνύματα εμφανίζονται συνήθως με $ dmesg -human στην αρχή της εκκίνησης.
Θα πρέπει επίσης να δοκιμάσετε ένα άλλο τροφοδοτικό, όταν το φιλτράρισμα αποτύχει, ο κυματισμός τείνει να κάνει τέτοιες αστοχίες.
Αρχικά, δοκιμάστε να αλλάξετε την πηγή και δείτε τι θα συμβεί, εάν παραμείνει το ίδιο, δοκιμάστε να διαμορφώσετε έναν πυρήνα προσαρμοσμένο στο υλικό σας, με τον τρόπο που θα γνωρίζετε τον υπολογιστή σας καλύτερα στη διαδικασία.
Ευχαριστώ για τις συμβουλές. Παρεμπιπτόντως, είναι φορητός υπολογιστής, νομίζω ότι πρέπει να αλλάξω την μπαταρία. Αλλά βλέπω ότι αυτό που μου είπες μπορεί να με βοηθήσει.
Ο μοναδικός πανικός του πυρήνα που με κάνει ακόμα τρελό είναι εν μέρει το σφάλμα των νουβό και της παλιάς, ξεπερασμένης και πολύ σκονισμένης ενσωματωμένης κάρτας nVidia 6150 SE (εννοώ εν μέρει γιατί, έχουν κάνει μια εξαιρετική δουλειά υποστηρίζοντας ένα σύμπαν τσιπ γραφικών όπως αυτά που έχει το nVidia, και όλα αυτά, χρησιμοποιώντας μόνο αντίστροφη μηχανική, συν το πρόβλημα εμφανίζεται μόνο για ορισμένες κάρτες με το chipset NV4E).
Απλώς ξεκινήστε το Openbox + Firefox και τις καταστροφές από καταστροφές (τίποτα πιο όμορφο από το να δείτε ένα εντελώς τυχαίο ασπρόμαυρο μωσαϊκό στην οθόνη σας). Και το έχω τραγουδήσει από τον πυρήνα 3.6 στο Debian, το Fedora, το Archlinux, το Slackware και τώρα επαληθεύτηκα ξανά στο Gentoo (μόλις εγκαταστάθηκε με τον πυρήνα 3.12), δεν ενοχλώ πλέον να πάρω ένα αρχείο καταγραφής, στον πυρήνα ή να του δώσω χρόνο να γράψτε κάτι που δεν είναι επιβλητικοί χαρακτήρες ανοησίας.
Σας δίνω τη λύση, ένας υπολογιστής που έχω με το gentoo και το ενσωματωμένο βίντεο nvidia συμβαίνει το ίδιο με το πρόγραμμα οδήγησης nouveau, οπότε δεν είχα άλλη επιλογή παρά να χρησιμοποιήσω το κλειστό πρόγραμμα οδήγησης nvidia, το τσιπ μου πρέπει να χρησιμοποιεί το πρόγραμμα οδήγησης 304.123
00: 0d.0 VGA συμβατό χειριστήριο [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA controller])
Πρέπει να διορθώσετε ένα αρχείο πυρήνα πριν το μεταγλωττίσετε, εάν δεν διορθωθεί η λειτουργία γραφικών θα αρνηθεί να ξεκινήσει.
Τα βήματα είναι:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Αναζήτηση με ctrl + w εντός nano για αυτό το κείμενο, το acpi_os_wait_events_complete και το nano σας μεταφέρει σε αυτό το μέρος:
void acpi_os_wait_events_complete (άκυρο)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Το έμπλαστρο που πρέπει να προσθέσετε είναι αυτή η τελευταία γραμμή που ξεκινά με EXPORT, ctrl + ή ctrl + x
Στη συνέχεια, μεταγλωττίζετε τον πυρήνα, εγκαταστήστε τις μονάδες, εγκαταστήστε τον πυρήνα, δημιουργήστε τα initramfs εάν το χρειάζεστε, προσθέστε το splash στα initramfs εάν χρησιμοποιείτε splash, αναδημιουργήστε τις καταχωρήσεις για grub και τέλος και πολύ σημαντικό, πρέπει να ξαναχτίσετε τις ενότητες που δεν προέρχονται από τον πυρήνα ή την ιδιόκτητη μονάδα nvidia, χωρίς να γίνει αυτό η λειτουργία γραφικών δεν θα λειτουργήσει.
# eselect λίστα πυρήνων
# eselect σύνολο πυρήνα x
# cd / usr / src / linux
# φτιαχνω, κανω
# make modules_install
# mount / boot
# make install
# dracut –hostonly »3.15.7-gentoo –force
# splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
# grub -mkconfig -o /boot/grub/grub.cfg
# emerge @ module-rebuild
# umount / εκκίνηση
# shutdown -r τώρα
Εάν χρησιμοποιείτε το genkernel απλώς διορθώστε αυτό το αρχείο και καταλαβαίνω ότι το genkernel διορθώνεται.
Επιπλέον, πρέπει να καταργήσετε την υποστήριξη drm και τα προγράμματα οδήγησης nvidia και άλλα τσιπ βίντεο από τον πυρήνα, έτσι ώστε να μην συγκρούονται με το κλειστό πρόγραμμα οδήγησης nvidia που είναι εγκατεστημένο ως μονάδα nvidia.
Σε περίπτωση χρήσης bootsplash, πρέπει να συμπεριλάβετε το πρόγραμμα οδήγησης uvesa στον πυρήνα έτσι ώστε να υποστηρίζει υψηλές αναλύσεις οθόνης, καθώς το κλειστό πρόγραμμα οδήγησης nvidia (αν θυμάμαι σωστά) δεν υποστηρίζει περισσότερα από 800 × 600 στο τερματικό tty1 «F1» του η μπότα.
Δεν ξέρω για άλλες διανομές, αλλά υποθέτω ότι θα έπρεπε να λειτουργεί σε οποιαδήποτε διανομή, αν γίνουν αυτά τα βήματα, αποθηκεύοντας την αναδυόμενη αλλαγή για οτιδήποτε άλλο.
Αυτές είναι οι οδηγίες που πρέπει να ακολουθήσετε, για το nvidia και το uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Ευχαριστώ για τις πληροφορίες, αλλά έλυσα το πρόβλημα ακριβώς αλλάζοντας σε ιδιόκτητο. Θυμάμαι ότι το προηγούμενο πρόγραμμα οδήγησης nVidia (304.121) έπρεπε επίσης να διορθωθεί κατά τη μετάβαση στο 3.13, επειδή είχε πρόβλημα κατά τη σύνταξη της μονάδας (δεν υπήρχαν σφάλματα, αλλά η μονάδα αρνήθηκε να λειτουργήσει) και όλα επίσης λόγω του ACPI χειριστής εκδηλώσεων. Στο Debian πήρα το πρόβλημα και βρήκα επίσης τη λύση.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Έχω χρησιμοποιήσει το Manjaro ως παράδειγμα, αλλά έχω αναφέρει προηγουμένως ότι το ίδιο συνέβη και με το Arch και άλλα παράγωγα. Επομένως, πιστεύω ότι το πρόβλημα είναι περισσότερο δικό τους από εκείνα που επηρεάζονται.
Pd: Δεν μπόρεσα να απαντήσω απευθείας στο σχετικό μήνυμα επειδή δεν εμφανίζεται η επιλογή απάντησης ...
Μόλις πήγα από το Manjaro στο Linux Mint επειδή θα παγώσει κατά την εκκίνηση μετά την ενημέρωση σε μια έκδοση μετά το 0.8.9 (δεν θυμάμαι ποια). Από ό, τι διάβασα, αυτό συμβαίνει συνήθως σε φορητούς υπολογιστές. Το εν λόγω πρόβλημά μου δεν ήταν το ίδιο με αυτό της ανάρτησης, νομίζω ότι κατέληξα στο συμπέρασμα ότι θα μπορούσε να σχετίζεται με τη διαχείριση ενέργειας. Υπήρχαν άνθρωποι που δεν κατάψυξαν εάν ξεκίνησαν το φορητό υπολογιστή ενώ αποσυνδέθηκαν. Αυτή τη στιγμή δεν θυμάμαι αν αυτό μου επέτρεπε να ξεκινήσω πάντα χωρίς προβλήματα, αλλά φυσικά ήμουν σε θέση να το κάνω περισσότερες φορές με κόστος να πάρει περισσότερο χρόνο για να το κάνω.
Τέλος πάντων, στο τέλος εγκατέλειψα και άλλαξα το Fedora και το Linux Mint.
Συμπτωματικά, χθες προσπάθησα να το αναστείλω χωρίς το φορτιστή και όταν το συνέχισα κρέμασε και έπρεπε να κάνω επανεκκίνηση.
Είναι αρκετά αστείο, έχω πάει με τον Arch για μερικούς μήνες και δεν έχω ούτε έναν πυρήνα πυρήνα! Μου συνέβη με τον Antergos (Arch με ένα πρόσθετο αποθετήριο) από το ζωντανό περιβάλλον, αλλά εκεί το θεωρώ πιο κατανοητό. Θα μπορούσε να είναι ένα πρόβλημα με τη μητρική πλακέτα ή μια ελαττωματική μονάδα RAM; Θυμάμαι πριν από περίπου 2 χρόνια μια μονάδα RAM μου προκάλεσε πολλές μπλε οθόνες στα Windows και επίσης αρκετούς Πυρήνες Πυρήνα! στο Mandriva. Έπρεπε να δοκιμάσω κάθε μνήμη κάθε φορά μεταξύ επανεκκίνησης και επανεκκίνησης.
Πρόκειται για ένα πρόβλημα Arch (που σέρνει όλα τα παράγωγά του), επειδή σε άλλες διανομές δεν υπάρχουν προβλήματα αυτού του τύπου. Αυτό που θεωρώ ενοχλητικό είναι ότι σε αυτό το σημείο δεν το έχουν λύσει. Είναι μόνο για χρόνια! Έχω διαβάσει παρόμοια προβλήματα από το 2011. Είμαι σαφής ότι πρόκειται για κάτι που έρχεται και πηγαίνει καθώς ενημερώνεται, επειδή χρησιμοποιώντας τις εκδόσεις 0.8.7, 0.8.8 και 0.8.9 χωρίς να τα ενημερώσετε, τίποτα δεν συμβαίνει. Από τότε και στο εξής όλα είναι σκατά, και σίγουρα σε παλιές εκδόσεις συνέβη επίσης. Γιατί συμβαίνει μόνο σε μερικούς από εμάς; Δεν ξέρω, αλλά δεν νομίζω ότι είναι το πρόβλημά μας, αλλά το Arch, γιατί, όπως ήδη ειπώθηκε, άλλες διανομές λειτουργούν τέλεια. Έχω ήδη σπάσει τα κέρατα στην ημέρα του για να βρω μια λύση, αλλά κουράστηκα. Λοιπόν, λυπάμαι, δεν πρόκειται να χρησιμοποιήσω το Arch.
Αψίδα 0.8.7, 0.8.8 και 0.8.9; Ανακαλύπτω ότι η Arch χρησιμοποιεί αυτήν την ονοματολογία έκδοσης.
Μήπως χρησιμοποιείτε το Manjaro;
Εντάξει, απαντώ στον εαυτό μου διαβάζοντας το προηγούμενο σχόλιό σας, και το ένα είναι το Manjaro και το άλλο είναι το Arch.
Το να κατηγορώ κανείς ένα distro για ένα συγκεκριμένο πρόβλημα δεν είναι ούτε συνεπές (δεν είναι πραγματικά συνεπές), τουλάχιστον στην περίπτωσή μου δεν μπορώ να κατηγορήσω πόσα distro προσπαθώ για το πρόβλημα με το nouveau και την κάρτα nVidia 6150SE, επειδή το πρόβλημα είναι το MMIO χειρισμός του προγράμματος οδήγησης και της κάρτας (το nVidia θα ξέρει τι να διορθώσει και τρελά πράγματα που θα πρέπει να διορθώσουν αυτή τη λεπτομέρεια). Το υλικό μπορεί επίσης να είναι το πρόβλημα και μπορείτε να δείτε ότι σε οποιοδήποτε λειτουργικό σύστημα χρησιμοποιείτε (Windows, Linux, BSD) και στην εμπειρία μου την επισκευή υπολογιστών, έχω δει πολύ περίεργα προβλήματα υλικού (όπως έναν υπολογιστή που αρνείται να εκκινήσει, εκτός εάν αλλάξτε τη θέση της μνήμης και όταν κλείσετε πρέπει να επαναλάβετε τη διαδικασία) και δεν μπορώ να κατηγορήσω τα Windows και το Debian για αυτό.
Είχα έναν πανικό πυρήνα με ένα ζωντανό ubuntu 12.04
Έχω φρενήρεις τον ασφαλή υπολογιστή μου HP pavilion dm4 Notebook PC, 8 GB RAM, 500 σκληρό δίσκο, έχει περισσότερα από 5 χρόνια χρήσης. Δεν θυμάμαι την ταχύτητα του μικροεπεξεργαστή, Intel core i5, νομίζω πάνω από 2 mhz.
Δεν μπορώ να γράψω τίποτα στην οθόνη του τερματικού. Θα συνεχίσω να ψάχνω περισσότερες πληροφορίες, για να λύσω αυτό το πρόβλημα.