Тази публикация е да покаже как да „поправите“ почти проблема със стартиращите фирми с грешки Arch Linux. Нещо като следното изображение:
Както се вижда, виждаме, че това е една от многото „комбинации“ от грешки, които се появяват произволно при стартиране на операционна система с този проблем. Както се казва в тази грешка, това показва, че може да има проблем в „Хардуер“, но както всички знаем в тази операционна система, дори лошите трикове на това, което не принадлежи на операционната система, могат да бъдат решени.
И така, ще опиша моя опит с този проблем. От това, което успях да преживея, проблемът беше само с Arch Linux или друг дистрибутор, който тествах външно, тъй като с всеки ubuntu, който бях инсталирал или тествал, той стартира без проблеми. Но ако се опитах да изтръгна Arch Linux инсталиран на твърдия диск, имаше проблем, че трябваше да се рестартира около 50 пъти, за да може ОС да стартира нормално и да може да го използва.
Това вече имаше нещо нередно с мен, защото можех да използвам само 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 = disable, i8042.noacpi = 1, apm = apds = apds = apds = apds = apds = apds = apds = acds = apds = apds = apds = apds = apds = apds = 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
Както е посочено там, това, което този параметър прави, е да ограничи използването до процесора, без да активира симетричния режим на обработка. Отначало работеше доста добре, докато не използвах командата pacman-Syyu; ме хвърли ядро изхвърлено o грешка в сегментацията.
Така че автоматично забелязах, че се случва нещо странно, затова започнах да изпълнявам други процеси, докато изведнъж системата напълно замръзна и вече не работи, докато не я рестартирах. Така че направих същата операция, но този път успях да изпълня htop и ми показа следното:
Както се очакваше, той показа само един процесор, тъй като другият го беше деактивирал, обаче ми се стори много странно защо програмите хвърлят по подразбиране, и дори не можа да стартира графичната среда; така че това беше нещо, което поне ми даде повече надежда, че ако задам параметрите на ядрото по един начин, той ще стартира моя Arch Linux както обикновено.
Така че продължих да опитвам другите параметри, които написах в списъка, докато не попаднах на този, който е най-доброто решение в момента:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Този параметър прави нещо толкова просто като изолиране (не деактивиране) на второто ядро на процесора при симетрична обработка, т.е. натоварването на обработката се дава на едно ядро, докато другото е само допълващо. Това, макар и да изглежда противоречиво, не влияе толкова много на производителността, тъй като тази страхотна ОС успя да стартира приложения по този начин:
Така че с това, единственият проблем, който забелязах, който се появява по време на зареждане, е една или две паники или ядове на ядрото; но в сравнение с 50 пъти, когато трябваше да се рестартирам преди това, мога да го считам за "заобикаляне". За останалото досега ми позволява да използвам ОС и да напиша този пост, който четете в момента :-).
Надявам се да ви помогнат и да не се измъкнете GNU / Linux, което е най-добрата операционна система, която някога са измисляли. Казвам го със сигурност.
Много интересна информация. Никога не съм имал тези паники на ядрото в ArchLinux през годините, в които го използвам, но е хубаво да знам какво да правя, ако проблемът ми се появи някога. Благодаря ти!
Както и да е, използвам Arch от дълго време (бях като 1 година без Arch) и без паника в ядрото.
Благодаря за бакшиша.
Най-вероятно, както споменах в публикацията, проблемът се случва заради хардуера, тъй като в това, което използвам arch, също не ми беше създал проблем от този тип.
Още един с отлични резултати в Arch. Никога не съм имал Kernel Panic
Повече от 2 години с GNU / Linux ... 2 години вече с ArchLinux, никога паника на ядрото ... 😉
Мисля, че паниката в ядрото се дължи повече на хардуера, отколкото на самия дистрибутор. Никога не съм виждал ядро за паника на лаптопа, който използвам сега, освен веднъж, когато сложих албум на 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? Може би не е достатъчно с проблемите, които често се появяват с бавността или увисването на системата, стигайки до точката на хвърляне на системата до тревата.
Хей? За какво говориш? o_O
Arch е разпределение на KISS, което може да се конфигурира от основата на самата операционна система, с няколко думи, ако системата е тежка, това е защото сте я изградили по този начин, ако системата има грешки, това е защото сте ги генерирали или защото не сте конфигурирали нещо правилно. Arch wiki е доста завършен, преди няколко години нямаше много важни теми на испански, това и инсталационният процес беше много по-груб и донякъде труден, сега всичко е малко по-автоматизирано.
Обвиняването на дистрибуцията за потребителски грешки е толкова ... Windows (?).
Обвиняването на дистрибуцията за грешки е последователно, просто защото това е истината. След като имах подобен проблем с Манджаро, опитах Arch, Antergos и друга неизвестна дистрибуция (не мога да си спомня името сега, съжалявам), че някой ми препоръча да ме увери, че не създава проблеми, но нищо; всички го дават. В OpenSuse, Fedora, Mint, Mageia и всички, които съм пробвал след това, не преминава. Така че, що се отнася до мен, не ми остава друг избор, освен да мисля, че вината е на дистрибуцията. Но, хей, не го демонизирам или нещо подобно, нещо повече, дразни ме, че не мога да използвам нищо на базата на Arch, защото много ми харесва, но този проклет проблем ми пречи. Нито мисля, че става въпрос за хардуера, защото много от нас, които ни се случват, не са се случвали преди да използват същия шибан. Е, всъщност трябва да е нещо свързано с хардуера, но, връщайки се към същото нещо, ако не съм направил никакви промени и имам проблеми със същото оборудване, с което не съм ги имал преди, очевидно това ще се дължи на направена промяна от Арч, който ме прецака.
„Обвиняването на дистрибуцията за потребителски грешки е толкова ... Windows (?).“
Бих ви казал, че обвиняването на потребителите за продуктови грешки е толкова Apple. Честно мислех хиляди пъти за това, но не виждам предимството да използвам нещо, чиито поддържащи основно мият ръцете си, за някаква сериозна цел. И казвам, че като се има предвид, че софтуерът GPL идва без гаранция.
Можете да кажете както искате, но ако това е същият случай на съобщенията за липса на сигнал към iPhone и отговорът на Apple "е, че грешите" отпреди няколко години. Ако правите дистрибуция, обикновено искате да осигурите някакво качество и минимална поддръжка, а истината е, че Arch е основно хобистка система, където виждате, че разработчиците му се забавляват да опаковат нови неща, но нямат голям интерес да предлагат истинска поддръжка . Всеки път, когато видя този тип публикации, оценявам повече работата зад дистрибуцията, която използвам.
И да, това е софтуерен проблем, ако не работи, ако спре да работи при актуализация или ако нещо от хардуера се счупи. Това дистрибуция на ядрото за паника, докато друго не ... е, да, очевидно има дистрибуция, която прави нещата правилно и друга грешно. Сега, ако ви е удоволствие да използвате Linux в стила на 90-те, където трябваше да прекомпилираме ядрото всеки път, когато включим нов принтер ... ето ви.
Ядрото компилирано ли е от разработчиците? или твоя собствена?
Паниката на ядрото се генерира, когато някои компоненти не са избрани (И) при компилиране или някои модули не са активирани, за да поддържат определен хардуер. С практиката и познанията на вашия хардуер (трябва да отворите компютъра и да видите какви марки чипове има), можете да създадете персонализирано ядро (чрез chrooting). Ако ubuntu и CD за инсталиране на Arch са били на вашия компютър, има нещо в компилацията, което не е активирано.
Това беше ядрото на запасите от самия архив Linux, от хранилищата.
Ядрото, което използвате, остава нещо, което вашият хардуер не харесва, трябва да имате рядка версия на чип на дънната платка или дори грешка в чип (обикновено се случва).
Може да е повредена таблица във вашия bios acpi, нормално е дежурните китайци дори да не изчисляват добре контролната сума на всяка таблица, обикновено тези съобщения се появяват с $ dmesg -human в началото на зареждането.
Също така трябва да опитате друго захранване, когато филтрирането се провали, пулсациите са склонни да правят точно такива повреди.
Първо, опитайте да промените източника и вижте какво се случва, ако той остане същият, опитайте да конфигурирате ядро, съобразено с вашия хардуер, по начина, по който ще опознаете компютъра си по-добре в процеса.
Благодаря за съветите. Между другото това е лаптоп, мисля, че трябва да сменя батерията. Но виждам, че това, което ми каза, може да ми помогне.
Паниката от едно ядро, която все още ме влудява, отчасти е по вина на модниците и на моята стара, остаряла и много прашна интегрирана карта nVidia 6150 SE (имам предвид отчасти защото; те са свършили отлична работа, поддържайки вселена от графични чипове като тези, които има nVidia, и всичко това, използвайки само обратен инженеринг, плюс проблемът възниква само при някои карти с чипсет 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 контролер])
Трябва да поправите файл на ядрото, преди да го компилирате, ако не е закърпен, графичният режим ще откаже да стартира.
Стъпките са:
# 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 (void)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Кръпката, която трябва да добавите, е този последен ред, който започва с EXPORT, ctrl + или ctrl + x
След това компилирате ядрото, инсталирате модулите, инсталирате ядрото, генерирате initramfs, ако имате нужда от него, добавяте изпръскването към initramfs, ако използвате изпръскване, регенерирате записите за grub и накрая и много важно, трябва да възстановите модулите, които не са от ядрото или собствения модул nvidia, без това графичният режим няма да работи.
# eselect списък на ядрото
# eselect набор от ядро x
# cd / usr / src / linux
# make
# направи модули_инсталиране
# монтиране / зареждане
# 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 / boot
# shutdown -r сега
Ако използвате genkernel, просто закърпвате този файл и разбирам, че genkernel се поправя сам.
Освен това трябва да премахнете драйверите за поддръжка на drm и nvidia и други видеочипове от ядрото, за да не се сблъскат челно със затворения драйвер на nvidia, който е инсталиран като nvidia модул.
В случай на използване на bootplash, трябва да включите увеса драйвера в ядрото, така че да поддържа високи резолюции на екрана, тъй като затвореният драйвер на 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
Използвал съм Манджаро като пример, но вече споменах преди това, че същото нещо ми се случи с Arch и други производни. Затова вярвам, че проблемът е по-скоро техен, отколкото засегнатите.
Pd: Не успях да отговоря директно на съответното съобщение, защото опцията за отговор не се появява ...
Преминах точно от Manjaro към Linux Mint, защото той ще замръзне при зареждане след актуализиране до версия след 0.8.9 (не мога да си спомня коя). От това, което прочетох, това обикновено се случва на лаптопи. Въпросният ми проблем не беше същият като този в този пост, мисля, че стигнах до извода, че може да е свързан с управлението на захранването. Имаше хора, които не замръзваха, ако стартираха лаптопа, докато бяха изключени. В момента не си спомням дали това ми позволяваше винаги да стартирам без проблеми, но разбира се успях да го направя повече пъти с цената на по-дълго време, за да го направя.
Както и да е, в крайна сметка се отказах и преминах към Fedora и Linux Mint.
По стечение на обстоятелствата вчера се опитах да го спра без зарядното устройство и при възобновяването му увисна и трябваше да рестартирам.
Доста смешно е, аз съм с Arch от няколко месеца и не съм имал нито една Kernel Panic! Случвало ми се е с Antergos (Arch с добавено хранилище) от живата среда, но там го смятам за по-разбираемо. Може ли да е проблем с дънната платка или дефектен RAM модул? Спомням си, че преди около 2 години RAM модул ми причини няколко сини екрана в Windows, а също и няколко ядки Panics! на Мандрива. Трябваше да тествам всяка памет в даден момент между рестартиране и рестартиране.
Това е проблем с Arch (който носи всичките му производни), тъй като в други дистрибуции няма такива проблеми. Това, което намирам за смущаващо, е, че към този момент те не са го решили. Това са само те от години! Чел съм подобни проблеми от 2011 г. Ясно съм, че това е нещо, което идва и си отива, когато се актуализират, защото при използване на версии 0.8.7, 0.8.8 и 0.8.9, без да ги актуализирате, нищо не се случва. Оттам насетне всичко отива на лайна и със сигурност в старите версии също се е случвало. Защо се случва само на няколко от нас? Не знам, но не мисля, че това е нашият проблем, а на Arch, защото, както вече казахме, други дистрибуции работят перфектно. Вече си счупих рогата, за да намеря решение, но се уморих. Така че, колкото и да съжалявам, няма да използвам Arch.
Арка 0.8.7, 0.8.8 и 0.8.9? Разбрах, че Arch използва тази номенклатура на версиите.
Възможно ли е да използвате Manjaro?
Добре, отговарям си, четейки предишния ви коментар и едно е Манджаро, а друго е Арх.
Това, че обвиняването на дистрибуция за даден проблем също не е последователно (всъщност не е последователно), поне в моя случай не мога да обвиня колко дистрибуция се опитвам за проблема с nouveau и моята nVidia 6150SE карта, защото проблемът е в MMIO обработка на драйвера и картата (nVidia ще знае какво да поправи и луди неща, които ще трябва да поправят тази подробност). Хардуерът също може да е проблемът и можете да видите, че в каквато и операционна система да използвате (Windows, Linux, BSD) и в моя опит при ремонта на компютри съм виждал много странни хардуерни проблеми (като компютър, който отказва да стартирайте, освен ако не промените местоположението в паметта и при изключване трябва да повторите процеса) и не мога да обвинявам Windows и Debian за това.
Имах паника в ядрото с жива ubuntu 12.04
Имам френет към моя преносим компютър Secure HP pavilion dm4, 8 GB RAM, 500 твърд диск, той има повече от 5 години употреба. Не помня скоростта на микропроцесора, Intel core i5, мисля, че повече от 2 MHz.
Не мога да напиша нищо на екрана на терминала. Ще продължа да търся повече информация, за да разреша този проблем.