Posting ini adalah untuk menunjukkan bagaimana untuk "memperbaiki" hampir masalah startup dengan kesalahan Arch Linux. Sesuatu seperti gambar berikut:
Seperti yang dapat dilihat, kami melihat bahwa ini adalah salah satu dari banyak "kombinasi" kesalahan yang muncul secara acak saat memulai sistem operasi dengan masalah ini. Seperti yang dikatakan dalam kesalahan itu, ini menunjukkan bahwa mungkin ada masalah di "Perangkat Keras", namun, seperti yang kita semua ketahui dalam sistem operasi ini, bahkan trik buruk dari apa yang bukan milik OS dapat diselesaikan.
Jadi, saya akan menjelaskan pengalaman saya tentang masalah ini. Dari apa yang bisa saya alami, masalahnya hanya dengan Arch Linux atau distro lain yang saya uji secara eksternal, karena dengan ubuntu apa pun yang telah saya instal atau uji, itu dimulai tanpa masalah. Tetapi jika saya mencoba merobek file Arch Linux diinstal pada hard drive, ada masalah yang harus di-boot ulang sekitar 50 kali agar OS dapat boot secara normal dan dapat menggunakannya.
Ini sudah ada yang salah dengan saya karena saya hanya dapat menggunakan ubuntu yang telah saya instal untuk mengujinya dan saya tidak dapat melakukan bahkan setengah dari hal-hal yang dapat saya lakukan. Arch Linux. Jadi saya memutuskan untuk menyelesaikan masalah ini dan mulai menyelidiki, mencari utas forum yang memiliki masalah yang sama, mereka juga menyebutkan bahwa itu adalah kesalahan perangkat keras dan justru itu CPU, jadi itu mulai membuat saya khawatir, jadi Saya harus membuka PC dan memverifikasi apa yang terjadi, namun itu tidak membantu.
Tetapi sesuatu yang menunjukkan kepada saya, bahwa saya tidak boleh menyerah adalah jika Ubuntu Saya bisa karena Arch Linux tidak (mungkin Ubuntu lebih baik dari Lengkungan…?). Jadi saya mulai menulis parameter boot ke kernel Arch Linux, hal-hal seperti: lapic, nomce, intel_idle.max_cstate = 0, nonaktifkan_cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufreq, intel_pstate = nonaktifkan, i8042.noacpi = 1, apm = copyds, acdm = copyds, acdm = copyds, acdm = copyds pci = nocrs, rhgb, acpi = force, pnpacpi = 0ff dan lainnya lebih ... Semua ini direkomendasikan di forum yang saya baca.
Sampai saya harus masuk ke dokumentasi parameter kernel yang saya rekomendasikan dengan cara: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Dan saya menemukan parameter yang cukup menarik yang untuk saat ini saya berhasil boot Arch Linux Tidak masalah:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Seperti yang ditunjukkan di sana, yang dilakukan parameter ini adalah membatasi penggunaan ke cpu tanpa mengaktifkan mode pemrosesan simetris. Awalnya itu bekerja dengan cukup baik sampai saya menggunakan perintah pacman-Syyu; melemparkan saya a inti dibuang o kesalahan segmentasi.
Jadi saya secara otomatis memperhatikan bahwa sesuatu yang aneh sedang terjadi, jadi saya mulai menjalankan proses lain sampai tiba-tiba sistem benar-benar berhenti dan tidak berfungsi lagi, sampai saya mem-boot ulang. Jadi saya melakukan operasi yang sama, tetapi kali ini saya berhasil mengeksekusi htop dan itu menunjukkan kepada saya yang berikut:
Seperti yang diharapkan, itu hanya menunjukkan satu CPU, karena yang lain telah menonaktifkannya, bagaimanapun, tampak sangat aneh bagi saya mengapa program melemparkan kesalahan segmen, dan bahkan tidak bisa memulai lingkungan grafis; jadi itu adalah sesuatu yang setidaknya memberi saya lebih banyak harapan bahwa jika saya menetapkan parameter kernel satu cara, itu akan mem-boot saya Arch Linux seperti biasa.
Jadi saya terus mencoba parameter lain yang saya tulis dalam daftar sampai saya menemukan yang ini, yang merupakan solusi terbaik saat ini:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Parameter ini melakukan sesuatu yang sederhana seperti mengisolasi (tidak menonaktifkan) inti kedua dari CPU dalam pemrosesan simetris, yaitu, beban pemrosesan diberikan ke satu inti sedangkan yang lain hanya sebagai pelengkap. Ini, meskipun tampak kontradiktif, tidak terlalu memengaruhi kinerja, karena OS hebat ini dapat menjalankan aplikasi dengan cara ini:
Jadi dengan ini, satu-satunya masalah yang saya amati yang terjadi saat boot, adalah satu atau dua kepanikan kernel atau oops; tetapi dibandingkan dengan 50 kali saya harus melakukan boot ulang sebelumnya, saya dapat menganggapnya sebagai "solusi". Selebihnya, sejauh ini saya telah mengizinkan saya untuk menggunakan OS dan menulis posting ini yang sedang Anda baca sekarang :-).
Saya berharap mereka membantu Anda, dan jangan keluar dari GNU / Linux, yang merupakan sistem operasi terbaik yang pernah mereka temukan. Saya mengatakannya dengan pasti.
Info yang sangat menarik. Saya tidak pernah mengalami kepanikan kernel di ArchLinux selama bertahun-tahun saya menggunakannya, tetapi ada baiknya mengetahui apa yang harus dilakukan jika suatu saat masalah terjadi. Terima kasih!
Bagaimanapun, saya telah menggunakan Arch untuk waktu yang lama (saya seperti 1 tahun tanpa Arch) dan tanpa kepanikan kernel.
Terima kasih atas tipnya.
Kemungkinan besar, seperti yang saya sebutkan di posting, masalah terjadi karena perangkat keras, karena dalam apa yang saya gunakan arch, itu juga tidak memberi saya masalah jenis ini.
Satu lagi dengan hasil yang luar biasa di Arch. Saya tidak pernah mengalami Kernel Panic
Lebih dari 2 tahun dengan GNU / Linux ... 2 tahun sudah dengan ArchLinux, tidak pernah panik kernel .. 😉
Saya pikir kepanikan kernel lebih disebabkan oleh perangkat keras daripada distro itu sendiri. Saya belum pernah melihat kernel panik di laptop yang saya gunakan sekarang kecuali setelah saya memasukkan Ubuntu alpha ke dalamnya (dan Arch Linux juga ada di sini selama dua tahun). Di sisi lain, di laptop lain yang saya miliki, setiap distro yang saya masukkan selalu menimbulkan kepanikan kernel dan berbagai macam error untuk semua selera.
Dengan kernel 3.14 di Debian, saya mengalami masalah kernel panic, selain itu setiap kali saya menyalakan PC saya, saya mendapatkan pesan "hubungkan / putuskan waktu habis" (dan juga ketika saya mematikannya).
Itu telah terjadi pada saya begitu banyak di Fedora seperti di Arch, tetapi saya tidak tahu mengapa, dan bagaimana saya tidak melihat perbedaan karena saya belum menghabiskan waktu untuk menyelidiki atau menyelesaikannya (jika itu adalah masalah).
Saya pikir alasannya adalah karena mereka dikompilasi dengan gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Terimakasih banyak untuk infonya. Beberapa dari banyak hal yang dapat kami banggakan adalah jenis forum ini
Mengapa ini terjadi pada Arch Linux? Mungkin tidak cukup dengan permasalahan yang sering muncul dengan kelambanan atau menggantungnya sistem hingga sampai pada titik melempar sistem ke fret.
Hei? Apa yang sedang Anda bicarakan? o_O
Arch adalah distribusi KISS yang dapat dikonfigurasi dari dasar sistem operasi itu sendiri, dalam beberapa kata, jika sistemnya berat itu karena Anda membangunnya dengan cara itu, jika sistem memiliki kesalahan itu karena Anda membuatnya atau karena Anda tidak mengkonfigurasi sesuatu dengan benar. Arch wiki cukup lengkap, beberapa tahun yang lalu tidak ada banyak topik penting dalam bahasa Spanyol, dan proses instalasinya jauh lebih kasar dan agak sulit, sekarang semuanya sedikit lebih otomatis.
Menyalahkan distro untuk kesalahan pengguna begitu… Windows (?).
Menyalahkan distro untuk kesalahan sedang konsisten, hanya karena itu adalah kebenaran. Setelah mengalami masalah yang sama dengan Manjaro, saya mencoba Arch, Antergos dan distribusi lain yang tidak diketahui (saya tidak dapat mengingat namanya sekarang, maaf) bahwa seseorang merekomendasikan kepada saya untuk meyakinkan saya bahwa itu tidak menimbulkan masalah, tetapi tidak ada; mereka semua memberikannya. Di OpenSuse, Fedora, Mint, Mageia dan semua yang saya coba setelah itu tidak lulus. Jadi, sejauh yang saya ketahui, saya tidak punya pilihan selain berpikir itu adalah kesalahan distro. Tapi, hei, saya tidak menjelekkannya atau apa pun, terlebih lagi, sangat mengganggu saya karena saya tidak dapat menggunakan apa pun berdasarkan Arch, karena saya sangat menyukainya, tetapi masalah sialan itu menghalangi saya. Saya juga tidak berpikir bahwa ini tentang perangkat keras, karena banyak dari kita yang terjadi pada kita tidak terjadi sebelum menggunakan sialan yang sama. Yah, sebenarnya itu pasti sesuatu yang berhubungan dengan perangkat keras, tapi, kembali ke hal yang sama, jika saya belum membuat perubahan dan saya memiliki masalah dengan peralatan yang sama yang tidak saya miliki sebelumnya, jelas itu akan terjadi karena perubahan yang dilakukan oleh Arch yang mengacaukanku.
"Menyalahkan distro untuk kesalahan pengguna begitu ... Windows (?)."
Saya akan memberi tahu Anda bahwa menyalahkan pengguna atas kesalahan produk adalah hal yang sangat penting bagi Apple. Sejujurnya saya telah memikirkannya ribuan kali, tetapi saya tidak melihat keuntungan menggunakan sesuatu yang pengelolanya pada dasarnya mencuci tangan, untuk tujuan serius apa pun. Dan saya katakan itu mengingat perangkat lunak GPL datang tanpa jaminan.
Anda dapat mengatakan seperti yang Anda inginkan tetapi jika itu adalah kasus yang sama dengan laporan kurangnya sinyal ke iPhone dan tanggapan Apple "adalah Anda salah" dari beberapa tahun yang lalu. Jika Anda membuat distro, Anda biasanya ingin memberikan kualitas, dan dukungan minimal, dan kenyataannya Arch pada dasarnya adalah sistem hobi, di mana Anda melihat bahwa pengembangnya bersenang-senang mengemas hal-hal baru, tetapi memiliki sedikit minat untuk menawarkan dukungan sejati. Setiap kali saya melihat jenis posting ini, saya lebih menghargai pekerjaan di belakang distro yang saya gunakan.
Dan ya, ini adalah masalah perangkat lunak jika tidak berfungsi, jika berhenti berfungsi saat pembaruan, atau jika perangkat keras rusak. Distro panik kernel yang satu sementara yang lain tidak… ya, jelas ada satu distro yang melakukan hal yang benar dan yang lainnya salah. Sekarang jika Anda senang menggunakan Linux dengan gaya tahun 90-an di mana kami harus mengkompilasi ulang kernel setiap kali kami memasang printer baru ... itu dia.
Apakah kernel dikompilasi oleh pengembang? atau milikmu sendiri?
Kepanikan kernel muncul ketika komponen tertentu belum dipilih (AND) saat kompilasi, atau beberapa modul belum diaktifkan untuk mendukung perangkat keras tertentu. Dengan latihan dan pengetahuan tentang perangkat keras Anda (Anda harus membuka pc dan melihat merek chip apa yang dimilikinya), Anda dapat membangun kernel khusus (dengan chrooting). Jika ubuntu dan CD instalasi Arch ada di komputer Anda, ada sesuatu di kompilasi yang tidak diaktifkan.
Itu adalah kernel stok dari archlinux itu sendiri, dari repositori.
Kernel yang Anda gunakan, ada sesuatu yang tersisa yang tidak disukai oleh perangkat keras Anda, Anda harus memiliki versi chip yang langka pada motherboard Anda atau bahkan bug dalam sebuah chip (biasanya terjadi).
Mungkin ada tabel yang rusak di bios acpi Anda, itu normal bahwa orang Cina yang bertugas bahkan tidak menghitung checksum dari setiap tabel dengan baik, pesan ini biasanya muncul dengan $ dmesg -human pada awal boot.
Anda juga harus mencoba catu daya lain, ketika penyaringan gagal, riak cenderung membuat kegagalan seperti itu.
Pertama, coba ubah sumbernya dan lihat apa yang terjadi, jika tetap sama, coba konfigurasikan kernel agar sesuai dengan perangkat keras Anda, dengan cara ini Anda akan lebih mengenal pc Anda dalam prosesnya.
Terima kasih atas tipnya. Ngomong-ngomong ini adalah laptop, saya rasa saya harus mengganti baterainya. Tapi saya melihat apa yang Anda katakan dapat membantu saya.
Satu kepanikan kernel yang masih membuat saya gila sebagian adalah kesalahan orang-orang nouveau dan kartu terintegrasi nVidia 6150 SE saya yang lama, usang dan sangat berdebu (maksud saya sebagian karena; mereka telah melakukan pekerjaan luar biasa yang mendukung semesta chip grafis seperti yang dimiliki nVidia, dan semua ini, hanya menggunakan rekayasa balik, ditambah masalah hanya terjadi pada beberapa kartu dengan chipset NV4E).
Yang harus Anda lakukan adalah memulai Openbox + Firefox dan serangan bencana (tidak ada yang lebih indah daripada melihat mosaik hitam dan putih yang benar-benar acak di layar Anda). Dan saya telah menyanyikannya sejak kernel 3.6 di Debian, Fedora, Archlinux, Slackware dan sekarang diverifikasi kembali di Gentoo (baru diinstal dengan kernel 3.12), saya tidak perlu lagi mengambil log, ke kernel atau memberikan waktu untuk menulis sesuatu yang jangan menjadi karakter yang tidak masuk akal.
Saya memberikan solusinya, pc yang saya miliki dengan gentoo dan video nvidia terintegrasi terjadi sama dengan driver nouveau, jadi saya tidak punya pilihan selain menggunakan driver nvidia tertutup, chip saya harus menggunakan driver 304.123
00: 0d.0 Pengontrol yang kompatibel dengan VGA [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [Pengontrol VGA])
Anda harus menambal file kernel sebelum mengkompilasinya, jika tidak ditambal, mode grafis akan menolak untuk memulai.
Langkah-langkahnya adalah:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Telusuri dengan ctrl + w dalam nano teks ini, acpi_os_wait_events_complete dan nano akan membawa Anda ke bagian ini:
batal acpi_os_wait_events_complete (batal)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Tambalan yang harus Anda tambahkan adalah baris terakhir ini yang dimulai dengan EKSPOR, ctrl + atau ctrl + x
Kemudian Anda mengkompilasi kernel, menginstal modul, menginstal kernel, menghasilkan initramfs jika Anda membutuhkannya, menambahkan splash ke initramfs jika Anda menggunakan splash, membuat ulang entri untuk grub dan terakhir dan yang paling penting Anda harus membangun kembali modul yang bukan dari kernel atau modul nvidia berpemilik, tanpa melakukan ini mode grafis tidak akan berfungsi.
# eselect daftar kernel
# eselect kumpulan kernel x
# cd / usr / src / linux
# make
# buat modules_install
# pasang / 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 / boot
# shutdown -r sekarang
Jika Anda menggunakan genkernel, Anda cukup menambal file itu dan saya mengerti bahwa genkernel memperbaiki dirinya sendiri.
Selain itu, Anda harus menghapus dukungan drm dan driver nvidia serta chip video lainnya dari kernel agar tidak bertabrakan dengan driver nvidia tertutup yang diinstal sebagai modul nvidia.
Dalam kasus menggunakan bootsplash, Anda harus menyertakan driver uvesa di kernel agar mendukung resolusi layar tinggi karena driver nvidia tertutup (jika saya ingat dengan benar) tidak mendukung lebih dari 800 × 600 di terminal tty1 «F1» boot.
Saya tidak tahu tentang distro lain, tapi saya rasa ini harus bekerja pada distro mana pun jika langkah-langkah ini dilakukan, menyimpan perubahan emerge untuk apa pun.
Ini adalah pedoman yang harus Anda ikuti, untuk nvidia dan uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Terima kasih atas infonya, tetapi saya memecahkan masalah dengan tepat dengan mengubah ke yang berpemilik. Saya ingat bahwa driver nVidia sebelumnya (304.121) juga harus ditambal ketika pergi ke 3.13 karena ada masalah dalam kompilasi modul (tidak ada kesalahan, tetapi modul menolak untuk bekerja) dan semuanya juga karena pengendali acara ACPI . Di Debian saya mendapat masalah dan menemukan solusinya juga.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Saya telah menggunakan Manjaro sebagai contoh, tetapi saya telah menyebutkan sebelumnya bahwa hal yang sama terjadi pada saya dengan Arch dan turunan lainnya. Oleh karena itu saya percaya bahwa masalahnya lebih pada mereka daripada mereka yang terpengaruh.
Pd: Saya belum bisa merespon langsung pesan yang bersangkutan karena opsi untuk merespon tidak muncul ...
Saya justru beralih dari Manjaro ke Linux Mint karena akan macet ketika boot setelah memperbarui ke versi yang lebih baru dari 0.8.9 (saya tidak ingat yang mana). Dari yang saya baca, biasanya ini terjadi di laptop. Masalah saya yang dimaksud tidak sama dengan yang ada di posting ini, saya rasa saya sampai pada kesimpulan bahwa itu bisa terkait dengan manajemen daya. Ada orang yang tidak membeku jika mereka menyalakan laptop saat dicabut. Saat ini saya tidak ingat apakah hal itu memungkinkan saya untuk selalu memulai tanpa masalah, tetapi tentu saja saya dapat melakukannya lebih banyak dengan biaya waktu yang lebih lama untuk melakukannya.
Bagaimanapun, pada akhirnya saya menyerah dan beralih ke Fedora dan Linux Mint.
Secara kebetulan, kemarin saya mencoba untuk menangguhkannya tanpa charger dan saat melanjutkannya hang dan saya harus restart.
Ini cukup lucu, saya telah bersama Arch selama beberapa bulan dan saya belum pernah mengalami satu pun Kernel Panic! Itu telah terjadi pada saya dengan Antergos (Arch dengan repositori tambahan) dari lingkungan hidup, tetapi di sana saya menganggapnya lebih bisa dimengerti. Mungkinkah ada masalah dengan motherboard atau modul RAM yang salah? Saya ingat sekitar 2 tahun yang lalu modul RAM menyebabkan saya beberapa layar biru di Windows dan juga beberapa Kernel Panics! di Mandriva. Saya harus menguji setiap memori pada waktu antara reboot dan reboot.
Ini adalah masalah Arch (yang menyeret semua turunannya), karena di distro lain tidak ada masalah sejenis itu. Yang saya anggap memalukan adalah saat ini mereka belum menyelesaikannya. Itu hanya mereka selama bertahun-tahun! Saya telah membaca masalah serupa dari tahun 2011. Saya jelas bahwa itu adalah sesuatu yang datang dan pergi saat mereka memperbarui, karena menggunakan versi 0.8.7, 0.8.8 dan 0.8.9 tanpa memperbaruinya, tidak ada yang terjadi. Sejak saat itu semuanya menjadi omong kosong, dan tentunya di versi lama itu juga terjadi. Mengapa itu hanya terjadi pada sedikit dari kita? Saya tidak tahu, tapi saya rasa itu bukan masalah kita, tapi Arch, karena, seperti yang sudah dikatakan, distribusi lain bekerja dengan sempurna. Saya sudah mematahkan tanduk saya pada zamannya untuk mencari solusi, tetapi saya lelah. Jadi, saya minta maaf, saya tidak akan menggunakan Arch.
Arch 0.8.7, 0.8.8 dan 0.8.9? Saya menemukan bahwa Arch menggunakan nomenklatur versi itu.
Mungkinkah Anda menggunakan Manjaro?
Oke, saya menjawab sendiri dengan membaca komentar Anda sebelumnya, dan satu hal adalah Manjaro dan yang lainnya adalah Arch.
Bahwa menyalahkan distro untuk masalah tertentu juga tidak konsisten (tidak benar-benar konsisten), setidaknya dalam kasus saya, saya tidak dapat menyalahkan berapa banyak distro yang saya coba untuk masalah dengan nouveau dan kartu nVidia 6150SE saya, karena masalahnya adalah MMIO menangani pengemudi dan kartu (nVidia akan tahu apa yang harus diperbaiki dan hal-hal gila yang harus mereka perbaiki detail itu). Perangkat keras juga bisa menjadi masalah, dan Anda dapat melihat bahwa di setiap OS yang Anda gunakan (Windows, Linux, BSD), dan dalam pengalaman saya memperbaiki komputer, saya telah melihat masalah perangkat keras yang sangat aneh (seperti PC yang menolak untuk boot kecuali Anda mengubah lokasi memori, dan saat mematikan Anda harus mengulangi prosesnya), dan saya tidak bisa menyalahkan Windows dan Debian untuk itu.
Saya mengalami kepanikan kernel dengan ubuntu 12.04 langsung
Saya memiliki hingar bingar Notebook PC Secure HP pavilion dm4 saya, RAM 8 GB, hard drive 500, penggunaan lebih dari 5 tahun. Saya tidak ingat kecepatan mikroprosesor, sebuah inti Intel i5, saya kira lebih dari 2 mhz.
Saya tidak bisa menulis apa pun di layar terminal. Saya akan terus mencari informasi lebih lanjut, untuk mengatasi masalah ini.