פוסט זה נועד להראות כיצד "לתקן" כמעט את בעיית הסטארט-אפים עם שגיאות Arch Linux. משהו כמו התמונה הבאה:
כפי שניתן לראות, אנו רואים שמדובר באחד מ"שילובי "השגיאות הרבים המופיעים באופן אקראי בעת הפעלת מערכת הפעלה עם בעיה זו. כפי שנאמר בשגיאה זו, זה מצביע על כך שקיימת בעיה ב"חומרה ", אולם, כפי שכולנו מכירים במערכת הפעלה זו, ניתן לפתור אפילו את הטריקים הגרועים של מה שאינו שייך למערכת ההפעלה.
אז אתאר את החוויה שלי בבעיה זו. ממה שהצלחתי לחוות, הבעיה הייתה רק ב Arch Linux או הפצה אחרת שבדקתי חיצונית, שכן עם כל אובונטו שהתקנתי או בדקתי, זה התחיל בלי בעיות. אבל אם ניסיתי לקרוע את Arch Linux שהותקנתי בכונן הקשיח, הייתה לי בעיה שהייתי צריך לאתחל מחדש בערך 50 פעמים כדי שהמערכת האתחול תתחיל כרגיל ותשתמש בה.
זה כבר היה לא בסדר איתי כי יכולתי להשתמש רק באובונטו שהתקנתי כדי לבדוק את זה ולא יכולתי לעשות אפילו מחצית מהדברים שיכולתי לעשות איתם. Arch Linux. אז החלטתי לפתור את הבעיה והתחלתי לחקור, בחיפוש אחר נושאי פורום שהייתה להם אותה בעיה, הם גם ציינו שזו שגיאת חומרה ושהוא בדיוק המעבד, אז זה התחיל להדאיג אותי, אז יצא לי לפתוח את המחשב ולוודא מה קורה, אולם זה לא עזר.
אבל משהו שהראה לי, שאני לא צריך לוותר עליו היה שאם אובונטו יכולתי בגלל Arch Linux לא (אולי אובונטו טוב יותר מ קשת...?). אז התחלתי לכתוב פרמטרי אתחול לליבה של Arch Linux, דברים כמו: lapic, nomce, intel_idle.max_cstate = 0, disable_cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufrere, intel_pstate = disable, i8042.noacpi = 1, acm = copd pci = nocrs, rhgb, 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
כפי שצוין שם, מה שפרמטר זה עושה הוא להגביל את השימוש למעבד מבלי להפעיל את מצב העיבוד הסימטרי. בהתחלה זה עבד די טוב עד מתי השתמשתי בפקודה פקמן -סיו; זרק לי א הליבה זרקה o תקלה בפילוח.
אז שמתי לב אוטומטית שמשהו מוזר קורה, אז התחלתי להריץ תהליכים אחרים עד שלפתע המערכת קפאה לחלוטין ולא עבדה יותר, עד שהפעלתי אותה מחדש. אז עשיתי את אותה פעולה, אבל הפעם הצלחתי לבצע Htop וזה הראה לי את הדברים הבאים:
כצפוי, הוא הראה רק מעבד אחד, מכיוון שהשני השבית אותו, עם זאת, נראה לי מאוד מוזר מדוע התוכניות זרקו Segfault, ואפילו לא יכול היה להתחיל את הסביבה הגרפית; אז זה היה משהו שלפחות נתן לי יותר תקווה שאם אגדיר את פרמטרי הליבה בכיוון אחד זה יאתחל את שלי Arch Linux כרגיל.
אז המשכתי לנסות את שאר הפרמטרים שכתבתי ברשימה עד שנתקלתי בזה, שהוא הפיתרון הטוב ביותר כרגע:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
פרמטר זה עושה משהו פשוט כמו לבודד (לא לבטל) את הליבה השנייה של המעבד בעיבוד סימטרי, כלומר עומס העיבוד ניתן לליבה אחת ואילו השני רק משלים. זה, למרות שזה נראה סותר, אבל לא משפיע כל כך על הביצועים, מכיוון שמערכת ההפעלה הנהדרת הזו הצליחה להריץ יישומים בצורה כזו:
אז עם זאת, הבעיה היחידה שראיתי שמתרחשת בזמן האתחול, היא פאניקה גרעינית אחת או שתיים או אופס; אך בהשוואה ל- 50 הפעמים שהייתי צריך לאתחל בעבר, אני יכול להחשיב את זה כ"פתרון דרך ". עבור השאר, עד כה זה איפשר לי להשתמש במערכת ההפעלה ולכתוב את הפוסט הזה שאתה קורא כרגע :-).
אני מקווה שהם יעזרו לך, ולא ייצאו גנו / לינוקס, שהיא מערכת ההפעלה הטובה ביותר שהמציאו אי פעם. אני אומר את זה בוודאות.
מידע מעניין מאוד. מעולם לא היו לי פאניקות גרעין אלה ב- ArchLinux בשנים שאני משתמש בה, אך טוב לדעת מה לעשות אם בשלב כלשהו הבעיה תתרחש. תודה!
בכל מקרה, אני משתמש ב- Arch זמן רב (הייתי כמו שנה ללא Arch) ובלי פאניקה גרעינית.
תודה על הטיפ.
סביר להניח, כפי שציינתי בפוסט, הבעיה מתרחשת בגלל החומרה, כי במה שאני משתמש ב- arch, זה גם לא נתן לי שום בעיה מסוג זה.
אחת נוספת עם תוצאות מצוינות בארכיון. מעולם לא הייתה לי פאניקה ליבה
יותר משנתיים עם GNU / Linux ... שנתיים כבר עם ArchLinux, אף פעם לא פאניקה ליבה .. 😉
אני חושב שפניקת גרעינים נובעת יותר מחומרה מאשר מההפצה עצמה. מעולם לא ראיתי גרעין פאניקה במחשב הנייד בו אני משתמש כעת, למעט שפעם אחת הכנסתי לתוכו אלפא של אובונטו (וגם Arch Linux היה כאן שנתיים). מצד שני, במחשב נייד אחר שיש לי, כל הפצה שאני שמה תמיד נותנת פאניקה ליבה ומגוון רחב של שגיאות לכל הטעמים.
עם הליבה 3.14 ב- Debian, נתקלתי בבעיית פאניקה ליבה, חוץ מזה שבכל פעם שאני מפעיל את המחשב האישי שלי, אני מקבל את ההודעה "פסק זמן לחיבור / ניתוק" (וגם כשאני מכבה אותו).
זה קרה לי כל כך הרבה בפדורה כמו בארץ ', אבל אני לא יודע למה, ואיך אני לא רואה שום הבדל מכיוון שלא ביליתי זמן בחקירה או בפתרון זה (אם זו בעיה).
אני חושב שהסיבה היא שהם מורכבים עם gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
תודה רבה על המידע. חלק מהדברים הרבים שאנחנו יכולים להתפאר בהם הוא סוג זה של פורום
מדוע זה קורה ל- Arch Linux? אולי לא די בכך שהבעיות המופיעות לעיתים קרובות עם האטיות או תליית המערכת מגיעים עד לזריקת המערכת עד הסוף.
היי? על מה אתה מדבר? o_O
Arch הוא הפצה של KISS הניתנת להגדרה מבסיס מערכת ההפעלה עצמה, בכמה מילים, אם המערכת כבדה זה בגלל שבנית אותה ככה, אם יש שגיאות במערכת זה בגלל שיצרת אותן או בגלל שלא הגדרת תצורה נכונה. Arch wiki שלם למדי, לפני כמה שנים לא היו הרבה נושאים חשובים בספרדית, ותהליך ההתקנה היה הרבה יותר מחוספס וקשה מעט, עכשיו הכל קצת יותר אוטומטי.
האשמת ההפצה בשגיאות משתמש היא כך ... Windows (?).
האשמת ההפצה בשגיאות היא להיות עקבית, פשוט כי זו האמת. אחרי שיש לי בעיה דומה עם מנג'רו ניסיתי את Arch, Antergos ועוד הפצה לא ידועה (אני לא זוכר את השם עכשיו, מצטער) שמישהו המליץ לי להבטיח לי שזה לא נותן בעיות, אבל כלום; כולם נותנים את זה. ב- OpenSuse, Fedora, Mintia, Mageia וכל אלה שניסיתי אחר כך, זה לא קורה. לכן, מבחינתי, לא נותרה לי ברירה אלא לחשוב שזו אשמתו של הדיסטרו. אבל, היי, אני לא עושה דמוניזציה או שום דבר, מה גם שזה מעצבן אותי שלא אוכל להשתמש בשום דבר על בסיס Arch, כי אני אוהב את זה מאוד, אבל הבעיה הארורה הזו מונעת ממני. אני גם לא חושב שזה קשור לחומרה, מכיוון שרבים מאיתנו שקורים לנו לא התרחשו לפני שהשתמשנו באותה פאקינג. ובכן, למעשה זה חייב להיות משהו שקשור לחומרה, אבל אם נחזור לאותו דבר, אם לא ביצעתי שינויים ויש לי בעיות עם אותו ציוד איתו לא היה לי אותם קודם, ברור שזה יהיה בגלל שינוי שנעשה מאת קשת שדפק אותי.
"האשמת ההפצה בשגיאות משתמש היא כך ... Windows (?)."
הייתי אומר לך שהאשמת המשתמשים בשגיאות מוצר היא כל כך אפל. באמת חשבתי על זה אלף פעמים אבל אני לא רואה יתרון להשתמש במשהו שהתחזיקים שלו בעצם שוטפים את הידיים, לכל מטרה רצינית. ואני אומר שבהתחשב בכך שתוכנת GPL מגיעה ללא אחריות.
אתה יכול להגיד כמו שאתה רוצה, אבל אם זה אותו מקרה של הדיווחים על חוסר איתות לאייפון והתגובה של אפל "היא שאתה מבין את זה לא נכון" מלפני מספר שנים. אם אתה מבצע דיסטרו אתה בדרך כלל רוצה לספק קצת איכות ותמיכה מינימלית, והאמת היא ש- Arch היא בעצם מערכת תחביבים, שבה אתה רואה שלמפתחים שלה יש כיף לארוז דברים חדשים, אבל אין להם עניין רב להציע תמיכה אמיתית. בכל פעם שאני רואה פוסטים מסוג זה אני מעריך יותר את העבודה שמאחורי ההפצה בה אני משתמש.
וכן, זוהי בעיית תוכנה אם היא לא עובדת, אם היא מפסיקה לעבוד בעדכון, או אם משהו מהחומרה מתקלקל. שגרעין נבהל מהבהבה בעוד שאחר אינו ... טוב, כן, ברור שיש דיסטרו שעושה דברים נכון ועוד לא בסדר. עכשיו אם זה התענוג שלך להשתמש בלינוקס בסגנון שנות ה -90, שם היינו צריכים לקמפל את הגרעין בכל פעם שהתחברנו למדפסת חדשה ... שם אתה.
האם הגרעין נערך על ידי היזמים? או משלך?
פאניקות ליבה נוצרות על ידי כך שלא בחרתם (AND) רכיבים מסוימים בעת הקומפילציה, או על ידי אי הפעלת מודולים מסוימים לתמיכה בחומרה מסוימת. בעזרת תרגול וידע של החומרה שלך (אתה צריך לפתוח את המחשב ולראות אילו מותגי שבבים יש לו), אתה יכול לבנות גרעין מותאם אישית (באמצעות chrooting). אם אובונטו ותקליטור ההתקנה של Arch היו במחשב שלך, יש משהו באוסף שלא מופעל.
זה היה גרעין המניות מהארכלינוקס עצמו, מהמאגרים.
הליבה בה אתה משתמש, נותר משהו שנותר לחומרה שלך, אתה חייב להיות גרסה נדירה של שבב על לוח האם שלך או אפילו באג שבב (זה בדרך כלל קורה).
זה יכול להיות טבלה פגומה של ה- bios acpi שלך, זה נורמלי שהסינים התורניים אפילו לא מחשבים היטב את סכום הבדיקה של כל טבלה, הודעות אלה מופיעות בדרך כלל עם $ dmesg - אנושי בתחילת האתחול.
כדאי לנסות גם ספק כוח אחר, כאשר הסינון נכשל, האדווה נוטה לעשות בדיוק סוג כזה של כשל.
ראשית, נסה לשנות את המקור ולראות מה קורה, אם הוא נשאר זהה, נסה להגדיר ליבת המותאמת לחומרה שלך, אגב שתכיר את המחשב שלך טוב יותר תוך כדי.
תודה על הטיפים. אגב זה מחשב נייד, אני חושב שאני צריך להחליף את הסוללה. אבל אני מבין מה שאמרת לי יכול לעזור לי.
הפאניקה הגרעינית האחת שעדיין משגעת אותי היא בחלקם באשמתם של החבר'ה הנובו ושל כרטיס ה- NVIDIA 6150 SE הישן, המיושן והמאובק מאוד (כלומר, משום שהם עשו עבודה מצוינת בתמיכה ביקום של שבבי גרפיקה כמו אלה שיש ל- nVidia, וכל זה, תוך שימוש בהנדסה לאחור בלבד, בנוסף הבעיה מתרחשת רק בכמה כרטיסים עם ערכת השבבים NV4E).
פשוט התחל את Openbox + Firefox ושביתות אסון (שום דבר יפה יותר מלראות פסיפס אקראי בשחור-לבן על המסך שלך). ואני שר אותו מאז הליבה 3.6 בדביאן, פדורה, ארצ'לינוקס, Slackware ועכשיו אומת שוב בג'נטו (רק מותקן עם ליבת 3.12), אני כבר לא טורח לקחת יומן, לליבה או לתת לו זמן לכתוב משהו ש אל תהיה דמויות שטויות עצומות.
אני נותן לך את הפיתרון, מחשב שיש לי עם ג'נטו וידיאו משולב של nvidia זהה עם מנהל ההתקן של הנובו, כך שלא הייתה לי ברירה אלא להשתמש במנהל התקן ה- NVIDIA הסגור, השבב שלי חייב להשתמש במנהל ההתקן 304.123
בקר תואם VGA 00: 0d.0 [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [בקר VGA])
עליך לתקן קובץ גרעין לפני הידורו, אם לא מתוקן, מצב הגרפיקה יסרב להתחיל.
השלבים הם:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
חפש עם ctrl + w בתוך ננו אחר הטקסט הזה, acpi_os_wait_events_complete ו- nano לוקח אותך לחלק זה:
בטל 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 הקנייני, מבלי לעשות זאת המצב הגרפי לא יעבוד.
# בחר את רשימת הגרעינים
# בחר את ערכת הליבה x
# cd / usr / src / linux
# עשה
# בצע מודולים_התקנה
# הר / אתחול
# בצע התקנה
# דרקוט - בהוסטל »3.15.7-gentoo – כוח
# splash_geninitramfs –verbose –res 1400 × 1050 – append /boot/initramfs-3.15.7-gentoo.img emerge-world
# grub -mkconfig -o /boot/grub/grub.cfg
# להופיע @ לבנות מחדש את המודול
# umount / boot
# כיבוי -ר עכשיו
אם אתה משתמש ב- 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 . בדביאן קיבלתי את הבעיה ומצאתי גם את הפיתרון.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
השתמשתי במנג'רו כדוגמה, אך הזכרתי בעבר שאותו דבר קרה לי עם Arch ונגזרות אחרות. לכן אני מאמין שהבעיה יותר שלהם מאלה שנפגעו.
Pd: לא הצלחתי להגיב ישירות להודעה הרלוונטית מכיוון שאפשרות התשובה לא מופיעה ...
פשוט עברתי ממנג'רו למנטה לינוקס כי זה יקפא בעת אתחול לאחר עדכון לגרסה אחרי 0.8.9 (אני לא זוכר איזה). ממה שקראתי זה בדרך כלל קורה במחשבים ניידים. הבעיה המדוברת שלי לא הייתה זהה לזו בהודעה זו, אני חושב שהגעתי למסקנה שהיא יכולה להיות קשורה לניהול אנרגיה. היו אנשים שלא קפאו אם הם התחילו את המחשב הנייד כשהם מנותקים מהחשמל. כרגע אני לא זוכר אם זה איפשר לי להתחיל תמיד בלי בעיות, אבל כמובן שהצלחתי לעשות את זה יותר פעמים במחיר של זמן רב יותר לעשות את זה.
בכל מקרה, בסוף ויתרתי ועברתי לפדורה וללינוקס מנטה.
בצירוף מקרים, אתמול ניסיתי להשעות אותו ללא המטען וכשחזרתי הוא נתלה והייתי צריך להתחיל מחדש.
זה די מצחיק, הייתי עם ארצ 'כבר כמה חודשים ולא הייתה לי אף חרדת פאנל! זה קרה לי עם אנטרגוס (Arch עם מאגר נוסף) מהסביבה החיה, אבל שם אני רואה את זה מובן יותר. האם זו יכולה להיות בעיה בלוח האם או במודול זיכרון RAM פגום? אני זוכר שלפני כשנתיים מודול RAM גרם לי לכמה מסכים כחולים ב- Windows וגם לכמה Panics Kernel! על מנדריבה. הייתי צריך לבדוק כל זיכרון בכל פעם שבין אתחול מחדש לאתחול.
זוהי בעיה של Arch (גוררת את כל הנגזרות שלה), מכיוון שבהפצות אחרות אין בעיות מהסוג הזה. מה שנראה לי מביך הוא שבשלב זה הם לא פתרו את זה. זה רק הם כבר שנים! קראתי בעיות דומות משנת 2011. ברור לי שזה משהו שבא והולך כשהם מתעדכנים, מכיוון שמשתמשים בגרסאות 0.8.7, 0.8.8 ו- 0.8.9 מבלי לעדכן אותן, שום דבר לא קורה. מכאן והלאה הכל הולך לעזאזל, ובוודאי שבגרסאות ישנות זה גם קרה. מדוע זה קורה רק למעטים מאיתנו? אני לא יודע, אבל אני לא חושב שזו הבעיה שלנו, אבל של ארצ ', כי, כאמור, הפצות אחרות עובדות בצורה מושלמת. כבר שברתי את קרני בימיו כדי למצוא פיתרון, אבל התעייפתי. אז ככל שאני מצטער, אני לא אשתמש בקשת.
קשת 0.8.7, 0.8.8 ו- 0.8.9? אני מגלה שארץ 'משתמשת במינוח הגירסה הזה.
יכול להיות שאתה משתמש במנג'רו?
אוקי, אני עונה לעצמי בקריאת התגובה הקודמת שלך, דבר אחד הוא מנג'רו ודבר אחר הוא Arch.
גם האשמת דיסטרו בבעיה מסוימת אינה עקבית (לא ממש עקבית), לפחות במקרה שלי אני לא יכולה להאשים כמה דיסטרו אני מנסה לבעיה עם נובו וכרטיס nVidia 6150SE שלי, כי הבעיה היא טיפול ב- MMIO בנהג ובכרטיס (ה- nVidia יידע מה לתקן ודברים מטורפים שיהיו להם כדי לתקן את הפרט הזה). חומרה יכולה להיות גם הבעיה, ואתה יכול לראות שבכל מערכת הפעלה בה אתה משתמש (Windows, Linux, BSD), ומנסיוני בתיקון מחשבים ראיתי בעיות חומרה מוזרות מאוד (כגון מחשב שמסרב אתחול אלא אם כן אתה משנה את מיקום הזיכרון, וכאשר אתה מכבה אתה צריך לחזור על התהליך), ואני לא יכול להאשים את Windows ו- Debian בכך.
הייתה לי פאניקה גרעין עם אובונטו בשידור חי 12.04
יש לי תזזית למחשב הנייד שלי Secure HP pavilion dm4, 8 GB של זיכרון RAM, 500 של הכונן הקשיח, יש לו יותר מ -5 שנים של שימוש. אני לא זוכר את המהירות של המיקרו-מעבד, Core i5 של אינטל, אני חושב שיותר מ -2 מגה-הרץ.
אני לא יכול לכתוב שום דבר על מסך המסוף. אני אמשיך לחפש מידע נוסף כדי לפתור בעיה זו.