Linux önyükleme sorunlarının ve donanım arızalarının teşhisi

Informatec Dijital » Ücretsiz Destekler » Linux önyükleme sorunlarının ve donanım arızalarının teşhisi

Bir Linux sistemi önyükleme yapmadığında veya düzensiz davranmaya başladığında, doğal tepki "Linux bozuldu" diye düşünmektir. Ancak pratikte, çoğu zaman altta yatan sorunlar yapılandırma hataları, dolu diskler, dosya sistemi bozulması veya biraz metodolojiyle bulunabilen donanım sorunlarıdır. Bu makalenin amacı tam olarak budur: hem fiziksel hem de sanal makinelerde Linux'taki en yaygın önyükleme ve donanım sorunlarını teşhis etmek ve onarmak için belirli komutlarla desteklenen net bir prosedür göstermek.

“Kök dosya sistemi bulunamadı,” “Aygıt üzerinde yer kalmadı,” “EXT4-fs hatası,” “XFS: Metadata CRC hatası” gibi mesajlarla veya korkulan bir Çekirdek Panik hatasıyla karşılaşırsanız , burada bunları nasıl yorumlayacağınızı, hangi komutları kullanacağınızı ve hangi sırayla hareket edeceğinizi öğreneceksiniz. Ayrıca, sorunun gerçekten yazılımla mı ilgili yoksa donanımın (RAM, SSD/HDD, ağ kartı vb.) ömrünün sonuna mı geldiğini nasıl belirleyeceğinizi ve sorun giderme sırasında veri kaybı riskini nasıl en aza indireceğinizi de göreceğiz.

Linux'ta önyükleme sorunlarının tipik nedenleri

Rastgele müdahalelere başlamadan önce, Linux'un neden başlamayabileceği veya yanlış başlayabileceğiyle ilgili en yaygın nedenleri anlamak iyi bir fikirdir . Temel nedeni anlamak, saatlerce sürecek sorun giderme ve sonuçsuz çözümler deneme zahmetinden sizi kurtaracaktır.

Sorunların ilk kümesi önyükleme yöneticisi ve BIOS/UEFI yapılandırmasından kaynaklanır : yanlış oluşturulmuş GRUB girdileri, çift önyükleme kurulumunda Windows yüklendikten sonra MBR'nin üzerine yazılması , dağıtımınızla uyumsuz Güvenli Önyükleme veya BIOS'un yanlış diskten önyükleme yapmaya çalışması. Bu durumlarda, genellikle GRUB menüsünü bile göremezsiniz veya Linux dağıtımınızı seçtiğinizde donar veya aygıt yazılımına geri döner.

Bir diğer önemli blok ise şunlarla ilgilidir: disk ve dosya sistemiHasarlı bölümler, bozuk sektörler, EXT4 veya XFS bozulması, dolu sistem diskleri veya LVM hataları. Bu genellikle önyükleme sırasında şu gibi mesajlar olarak kendini gösterir:/… bağlantısı kurulamadı.""EXT4-fs hatası""XFS: Bağlantıyı kesin ve xfs_repair komutunu çalıştırın."Hatta acil durum moduna geçip sizden komut vermenizi isteyebilir." journalctl -xb.

Çekirdek güncellemesi veya kötü uygulanmış bir yama sonrasında da sorunlar çok yaygındır . Eksik indirmeler, yüklenmemiş modüller, donanımınızla artık uyumlu olmayan sürücüler veya initramfs'deki değişiklikler, sistemin önyükleme sırasında donmasına veya başlangıçta Çekirdek Panik hatası vermesine neden olabilir.

Sistemin kendisinin yapılandırmasıyla ilgili bölümü de unutmamalıyız : aşırı katı güvenli önyükleme kuralları (örneğin, /var/log/audit dolduğunda HALT ile yapılandırılmış auditd), yer yetersizliği nedeniyle başarısız olan kritik hizmetler veya temel servislerin (ağ, systemd, Azure gibi bulutlarda cloud-init vb.) başlatılmasını engelleyen yapılandırma dosyalarındaki değişiklikler.

Son olarak, donanım katmanı var : kırmızı SMART bayraklarına sahip diskler, ECC hatalı RAM'ler, paket kaybeden ağ kartları veya aşırı ısınan SSD'ler . Genellikle ipucu çekirdek mesajlarında (dmesg) veya SMART ve EDAC sayaçlarında bulunur, bu nedenle bunları nasıl dikkatlice okuyacağımızı göreceğiz.

Çalıştırma arızasının kaynağını nasıl tespit edebiliriz?

Kör başlatmaları önlemenin anahtarı, ayrıntılı önyükleme modunu etkinleştirmek ve günlükleri incelemektir . Varsayılan olarak, birçok dağıtım mesajları gizleyen güzel bir açılış ekranı görüntüler; bu iyi görünür ancak bir şeyler ters gittiğinde hiçbir faydası olmaz.

GRUB kullanan sistemlerde, /etc/default/grub dosyasını düzenleyerek sessiz modu devre dışı bırakabilirsiniz . Şu satırı arayın:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

ve şununla değiştirin:

GRUB_CMDLINE_LINUX_DEFAULT=""

Ardından, yapılandırmayı yeniden oluşturmak için `update-grub` komutunu (veya dağıtımınızdaki eşdeğer komutu) çalıştırın . Bir sonraki önyüklemede, tüm çekirdek ve systemd mesajlarını göreceksiniz; bu da sistemin çökmesine neden olan hatayı tam olarak belirlemenizi sağlayacaktır.

Sistem kısmen başlatılırsa veya canlı ortamdan erişim sağlayabilirseniz, /var/log dizininde çeşitli önemli günlük dosyalarına erişebilirsiniz :

• /var/log/boot.logBaşlangıç ​​aşamasında gerçekleşen her şeyi kaydeder; eğer hata bu aşamadaysa, bakılması gereken ilk yer burasıdır.
• / var / log / messages o / Var / log / syslog (Dağıtıma bağlı olarak): Genel sistem olayları, servislerde, arka plan programlarında vb. hataları görüntülemek için çok kullanışlıdır.
• dmesg: Donanım arızaları, modül sorunları, veri yolu hataları, PCI hataları vb. dahil olmak üzere çekirdek mesajlarını görüntüler.
• JournalctlSystemd kullanan sistemlerde, tüm kayıt defterini taramak için kullanılan birincil araçtır; journalctl -xb Final başlangıcını tüm ihtişamıyla görüyorsunuz.

Sistem masaüstüne ulaşamaz ancak TTY veya kurtarma moduna ulaşırsa, `journalctl -xb` komutunu doğrudan oradan çalıştırabilirsiniz. Bu da işe yaramazsa, bir Canlı USB'den önyükleme yapmanız , sistem diskini bağlamanız ve dosyaları canlı ortamdan okumanız gerekecektir.

Sorunun donanımsal mı yoksa yazılımsal mı olduğunu kontrol edin.

Ayarları düzenlemeye başlamadan önce, sorunun doğrudan donanımla ilgili olup olmadığını kontrol etmekte fayda var : disk, bellek, işlemci, anakart veya güç kaynağı . "Rastgele" bozulan birçok kurulum aslında arızalı bir SSD veya hatalı bir RAM'den kaynaklanıyor olabilir.

Bilgisayar sürücüyü hiç tanımıyorsa, ilk adım BIOS/UEFI'ye girip sürücünün listede olup olmadığını doğrulamaktır. Sürücü hiç görünmüyorsa veya aralıklı olarak görünüyorsa, bağlantıları, SATA kablolarını ve güç kaynağını kontrol edin veya sürücünün geri dönüştürülmesi gerekebileceğini varsayın.

GRUB veya Canlı önyükleme moduna ulaştığınızda, RAM'inizi kontrol etmek için GRUB menüsünden MemTest86+'yı başlatabilirsiniz. En az sekiz geçiş boyunca çalışmasına izin verin; kırmızı çizgiler görürseniz, bellek arızalıdır ve modüllerin değiştirilmesi gerekir. Arızalı RAM, veri bozulması için uygun bir ortamdır.

Linux'ta disklerin durumunu kontrol etmek için smartmontools aracını kullanın . Kurulumdan sonra SMART'ı etkinleştirin ve en önemli özniteliklere göz atın:

• Yer Değiştiren_Sektör_Ct: Yeniden atanan sektör sayısı; eğer 0'dan büyükse, o diskte zaten bozuk sektörler oluşmaya başlamıştır.
• Mevcut_Bekleyen_Sektör_Ct: Yeniden atanması beklenen sektörler; 0'dan büyük herhangi bir değer, yakın zamanda başarısızlık riskinin yüksek olduğunu gösterir.
• Çalışma Saatleri: toplam kullanım saati; sayı ne kadar yüksekse, diskin arızalanma olasılığı o kadar yüksektir.

`smartctl -H /dev/sdX` komutunu kullanarak diskin sağlık testinden geçip geçmediğini hızlıca görebilirsiniz. Sonuç GEÇTİ değilse, verilerinizi en kısa sürede yedeklemeniz ve diski değiştirmeyi düşünmeye başlamanız gerekir.

Yüksek sıcaklıklardan şüpheleniyorsanız, takın lm-sensörler ve koş sensors (o watch -n 2 sensors (Gerçek zamanlı olarak görüntülemek için). SSD'ler ve SATA sürücüler için, hddtemp Bu özellik, mevcut sıcaklığı göstererek, boşta dururken bile sıcaklığı yükselen üniteleri tespit etmenizi sağlar; bu özellik özellikle şu durumlarda faydalıdır... sunucu optimizasyonu.

Linux'ta özel donanım teşhisi

Linux, CPU, RAM ve diskin yanı sıra ECC bellek, ağ kartları, GPU'lar ve diğer bileşenleri değerlendirmek için özel araçlara sahiptir . Bu noktaları kontrol etmek için birkaç dakika ayırmak, size saatlerce sürecek hata ayıklama işleminden tasarruf sağlayabilir.

Sunucunuz veya iş istasyonunuz ECC belleğe sahipse , çekirdek genellikle düzeltilmiş ve düzeltilmemiş hataları EDAC kullanarak kaydeder. Basit bir örnek:

dmesg | grep EDAC

Bu , CE (Düzeltilmiş Hatalar) veya UE (Düzeltilmemiş Hatalar) olup olmadığını görmenizi sağlar . CE'ler, RAM'de arızalar olduğunu ancak donanımın bunları düzeltebildiğini gösterir; bu modülleri izlemek tavsiye edilir çünkü genellikle düzeltilemez hatalara dönüşmeleri sadece zaman meselesidir. UE'ler genellikle ciddi veri bozulmasını önlemek için Çekirdek Panik ile sonuçlanır.

Bellek yapısını ve kapasitesini kontrol etmek için `dmidecode -t memory` komutu modül türlerini (DDR3, DDR4, DDR5), kapasiteleri, kullanılan bellek yuvalarını ve daha fazlasını gösterir. Ayrıca `dmidecode -t 16` komutuyla anakartın desteklediği maksimum RAM kapasitesini görebilirsiniz; bu da yükseltme yapmayı düşünüyorsanız faydalı olacaktır.

Sıcaklık ve görsel izleme alanında, psensor veya xsensors gibi grafiksel araçlarla sensör ve HDD sıcaklık verilerini destekleyebilir , böylece sıcaklığı zaman içinde grafikleyerek olağandışı ani yükselişleri veya sürekli olarak ısı sınırında çalışan ekipmanları tespit edebilirsiniz.

Diskleri ve USB sürücülerini teşhis etmek için , aygıtları listelemek üzere lsblk ve fdisk -l komutlarına ek olarak, aşağıdaki komutları birleştirmek çok faydalıdır:

• df -h y df -iAlan ve inode kullanım yüzdesi; gigabaytlarca boş alanınız olabilir ancak inode'ların %100'ü doluysa sistem yine de "yer yok" uyarısı verecektir.
• fsck /dev/sdXN -y: Dosya sistemlerindeki (EXT2/3/4 ve diğerleri) mantıksal hataları arar ve onarır.
• bozuk bloklar /dev/my_diskArızalı sektörleri tarar ve sistemin bunları kullanmaması için işaretler (bunu yapmadan önce yedekleme yapmanız şiddetle tavsiye edilir).

Ağ kartı söz konusu olduğunda , tipik belirtiler arasında bağlantı kesilmeleri, gecikme veya açıklanamayan paket kaybı yer alır. İstatistikleri incelemek için ethtool'u , paket kaybı oranlarını (RX-DRP ve TX-DRP) kontrol etmek için ise netstat'ı kullanabilirsiniz . Paket kaybı yüzdesi yaklaşık %0,2'yi aşarsa , ağ performansı açıkça etkilenir ve ağ kartı arızalı veya sürücü tarafından yetersiz destekleniyor olabilir.

Disk dolu ve alan hataları: Klasik "Cihazda yer kalmadı" hatası.

Birçok makinede (özellikle sunucularda ve sanal makinelerde ) en yaygın sorunlardan biri sistem disklerinin tamamen dolmasıdır. Bu durumda, servisler, günlükler, önyükleme işlemleri ve hatta çekirdeğin kendisi bile G/Ç hataları vermeye başlar.

Azure gibi ortamlarda, konsolda veya başlangıç ​​tanılamasında buna benzer mesajlar görmek yaygındır:

• Cihazda boş alan kalmadı Cloud-init'te, sanal makinenin önyükleme işlemini tamamlamasını engelleyebilecek bir durum söz konusu.
• Tekrarlanan mesajlar "Cihazda yer kalmadı." Bulut aracısı da dahil olmak üzere kritik hizmetleri etkileyen durumlar.
• Sistem günlüklerinde denetim veya ağ günlüklerinin yazılamadığını gösteren hatalar.

Alanın hangi nesne tarafından işgal edildiğini hızlıca bulmak için şu komutları kullanabilirsiniz:

• du -ks /* | sort -nKök dizinleri boyutlarına göre sıralar; asıl sorunlu dizin bulunana kadar en büyük dizinlerde işlemi tekrarlar.
• ls -altSr /var/log: Günlük dosyalarını boyutlarına göre, en küçüğünden en büyüğüne doğru sıralar; genellikle döndürülebilecek veya silinebilecek çok büyük eski günlük dosyaları görürsünüz.
• find / -size +500M -exec ls -alFh {} \;: Büyük boyutlu tek tek dosyaları arayın; bu 500 MB değerini gerektiği gibi ayarlayın.

/var/log veya /tmp klasörlerinin tipik olarak dolmasının yanı sıra, aşağıdaki gibi güvenlik yapılandırmaları da mevcuttur: denetim Bu durum, bir makinenin kapanmasına veya başlatılamamasına neden olabilir. /var/log/audit dosyasında yer kalmadı. Eğer /etc/audit/auditd.conf var:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

Sistem, denetim günlüklerine yazamıyorsa kontrollü bir şekilde kapanabilir veya önyüklemeyi reddedebilir. Geçici bir çözüm, sistemin önyükleme yapmasına ve yer açmasına izin vermek için bu değerleri SUSPEND, IGNORE veya diğer geçerli seçeneklere (bu bağlamda asla SINGLE değil) değiştirmektir . Sorun çözüldükten sonra, uyumluluk gerekiyorsa orijinal politikaya geri dönmelisiniz.

Sistemin önyükleme yapmaması nedeniyle dosyaları silmenin hiçbir yolu olmadığında, kurtarma modlarına başvurabilirsiniz : otomatik bulut onarım komutları (örneğin, Azure'da az vm repair), kurtarma sanal makineleri veya tek kullanıcı modu. Bu modlar, diski bağlayıp gereksiz dosyaları silerek /var/log ve diğer kritik dizinleri barındıran dosya sisteminde en az %10 boş alan elde edene kadar işlem yapmanızı sağlar.

Bozuk EXT4 ve XFS Dosya Sistemleri: Hasarlı Dosya Sistemleri Nasıl Onarılır?

Başlangıçta “EXT4-fs hatası (aygıt sda1)” , “hatalı extra_isize” , “günlük bulunamadı” gibi mesajlar veya “Metadata CRC hatası tespit edildi… Bağlantıyı kesin ve xfs_repair çalıştırın” gibi XFS mesajları görüyorsanız , tek seferlik bir sorunla karşı karşıya değilsiniz: dosya sistemi bozuk ve onarılana kadar makine normal şekilde önyükleme yapmayacaktır.

İlk adım, hangi aygıtın etkilendiğini belirlemektir . Önyükleme günlüklerinde, çekirdek mesajlarında parantez içinde görünen metne bakın: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname, vb. Bu, doğrudan bir bölümleme (sdXN) mi yoksa bir LVM mantıksal birimi (dm-N, /dev/vgname/lvname) mi ile uğraştığınızı size söyleyecektir.

Bir shell'e (acil durum modu, tek kullanıcı veya kurtarma makinesi) erişim sağladıktan sonra, diskler, bölümler, LVM ve dosya sistemi türleri de dahil olmak üzere tüm yapıyı görmek için `lsblk -f` komutunu çalıştırın. Burada, söz konusu bölümün gerçekten ext4, xfs, vfat, LVM2_member vb. olup olmadığını doğrulamak çok önemlidir ve yanlış yapılandırılmış olabileceğinden şüpheleniyorsanız, yalnızca `/etc/fstab` dosyasında yazanlara güvenmemelisiniz.

EXT4 dosya sistemlerini onarmak için fsck kullanılır . Genel kural olarak:

• Dosya sisteminin doğru olduğundan emin olun. monte edilmemiş (Eğer bir veri diski ise) veya kullanımda olmadığı bir kurtarma ortamında çalışıyorsanız.
• mızrak fsck /dev/sdXN o fsck /dev/vgname/lvnameTutarsızlıkları düzeltmek, yeniden boyutlandırma inode'unu yeniden oluşturmak, blok sayaçlarını ayarlamak vb. isteyip istemediğinizi soracaktır.
• Çok fazla soru çıkarsa, CTRL+C ile işlemi durdurun ve tekrar çalıştırın. fsck -y Böylece otomatik olarak "evet" diye yanıt verir; bu sayede hiçbir şeyi kaçırmazsınız.
• Dosyaları taşırsanız kayıp+bulunduOnları daha sonra kontrol etmeniz ve ait oldukları yerlere geri koymanız gerekecek.
• Dosya sisteminin çalıştığını gösteren çıktıyı görene kadar fsck komutunu tekrar çalıştırın. çamça.

XFS söz konusu olduğunda , kullanılan araç xfs_repair'dir . Tipik iş akışı şu şekildedir:

• Öncelikle, kuru bir kontrol yapalım: xfs_repair -n /dev/vgname/homelv Herhangi bir değişiklik yapmadan hasarın ne olduğunu görmek.
• Analiz mantıklıysa, düzeltme girişiminde bulunabilmesi için -n parametresi olmadan işlemi tekrarlayın: xfs_repair /dev/vgname/homelv.
• Eğer komut, dosya sisteminde "yeniden üretilmesi gereken değerli meta veri değişiklikleri" olduğunu belirtiyorsa, dosyayı bağlamayı deneyin: XFS sistemlerinde, bekleyen birçok değişiklik tam olarak bağlama işlemi sırasında uygulanır. Kurtarma sanal makinesindeyseniz, bunu şu gibi bir noktada yapabilirsiniz: /recovery.
• Başka çare yoksa ve günlük hataları düzeltilemezse, son çare olarak şunu kullanmak gerekir: xfs_onarım -L Günlük dosyasını silmek ve tüm değişiklikler uygulanmış gibi derlemeyi zorlamak. Bu, son verilerin kaybına neden olabilir, bu nedenle bunu yalnızca son çare olarak yapın.

Her durumda, fsck ve xfs_repair'in sihirli olmadığını anlamak çok önemlidir : dosya sistemi yapısını onarırlar, ancak her zaman tüm verileri kurtaramazlar. Bu nedenle, önceki yedeklemelere sahip olmak ve bulutta veya sanal makinede çalışıyorsanız, disk anlık görüntüsünden veya kurtarma makinesine bağlı bir kopyadan çalışmak çok önemlidir.

GRUB, UEFI, Güvenli Önyükleme ve diğer önyükleme klasikleri

Bilgisayarı açtığınızda GRUB menüsünü bile göremiyorsanız veya BIOS/UEFI "\EFI\ubuntu\grubx64.efi açılamadı - Bulunamadı" gibi hatalar verip bu girişten önyükleme yapmaya çalışırken bir döngüye giriyorsa, sorun neredeyse kesinlikle önyükleme yöneticisinde veya aygıt yazılımı yapılandırmasındadır.

Bu hatalar, Windows'u çift önyükleme yapılandırmasında kurduktan sonra (ki bu genellikle MBR'yi devralır veya UEFI girişlerinin üzerine yazar), yanlışlıkla bir EFI bölümünü sildikten sonra veya BIOS'taki önyükleme sırasına müdahale ettikten sonra ortaya çıkabilir. Modern dizüstü bilgisayarlarda, UEFI girişi "ubuntu" artık mevcut olmayan bir dosyayı işaret ediyorsa ve onu yüklemeye çalışıyorsa, makinenin sürekli yeniden başlatılması yaygın bir durumdur.

Bozuk bir GRUB önyükleyicisini onarmanın en kolay yolu, canlı bir dağıtımdan (örneğin Ubuntu) önyükleme yapmak ve Boot-Repair aracını kullanmaktır . Tipik prosedür şöyledir:

• Bir yerden başlayın. USB Canlı ve bir terminal açın.
• Depoyu ekleyin ve güncelleyin: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Aracı kurun: sudo apt install -y boot-repair.
• Şununla çalıştırın: boot-repair ve seçeneği seçin “önerilen onarım”.

Boot-Repair, bölümleri analiz eder, kurulu sistemleri bulur, GRUB'u yeniden yapılandırır, yapılandırma dosyasını yeniden oluşturur ve gerekirse bilgisayarın uygun önyükleme yöneticisinden önyükleme yapabilmesi için UEFI girişlerini ayarlar.

UEFI, Güvenli Önyükleme ve Hızlı Önyükleme etkinleştirilmiş sistemlerde , dikkat edilmesi gereken birkaç uyumsuzluk vardır. Tüm dağıtımlar Güvenli Önyüklemeyi doğru şekilde desteklemez ve eski donanımlar için tasarlanmış bazıları UEFI ile bile iyi çalışmaz. Dağıtımınız imzasızsa veya önyükleme katmanı uyumsuzsa, UEFI çekirdeği yüklemeyi reddedebilir.

Bu durumlarda çözüm genellikle UEFI ayarlarına erişmeyi, klasik BIOS tarzı önyüklemeye izin vermek için Legacy/CSM modunu etkinleştirmeyi ve Güvenli Önyüklemeyi devre dışı bırakmayı içerir . Ancak, bu bilgisayarda Windows 11 de kullanıyorsanız veya Windows'tan Linux'a geçmek istiyorsanız , Güvenli Önyüklemeyi devre dışı bırakmak Windows'un önyükleme gereksinimlerini bozabilir; bu nedenle hangi sistemin öncelikli olduğunu göz önünde bulundurmalı veya her seferinde BIOS'a erişmekten kaçınmak için Güvenli Önyükleme ile uyumlu bir Linux dağıtımı aramalısınız.

Windows Hızlı Önyükleme, çift önyükleme senaryolarında da sorunlara neden olur. Hızlı Önyükleme etkinleştirilmişken kapatma işlemi yapıldığında, Windows tamamen kapanmaz: çekirdeğin bir kısmını diskte uyku modunda bırakır ve NTFS dosya sistemine tam erişimi engeller. Linux bu bölümleri bağlamaya çalıştığında hatalar oluşabilir veya sistem donabilir. Hem Windows güç seçeneklerinde hem de UEFI'niz izin veriyorsa BIOS'ta Hızlı Önyüklemeyi devre dışı bırakmanız önerilir.

Kurtarma modlarının ve yerleşik onarım araçlarının kullanımı

GRUB görünüyor ancak Linux sisteminiz başlatılamıyorsa veya bir paketin tamamlanmamış kaldığından ya da bir güncelleme sonrasında sistemin bozulduğundan şüpheleniyorsanız, GRUB'un gelişmiş seçeneklerinden ve çoğu dağıtımda bulunan kurtarma modlarından yararlanabilirsiniz .

GRUB menüsünde genellikle " Gelişmiş seçenekler " veya benzeri bir giriş bulunur. Burada, genellikle mevcut tüm çekirdek sürümlerini ve her biri için bir Kurtarma modu görürsünüz . En son sürüm için kurtarma modunu seçin (ve bu başarısız olursa, bir öncekini deneyin).

Kurtarma modu size şu konularda oldukça faydalı yardımcı programların bulunduğu bir menü gösterir:

• fsckDosya sistemini kontrol edin ve onarın (Windows'taki chkdsk'ye benzer).
• çamçaGeçici dosyaları ve diğer artık dosyaları silerek yer açın.
• dpkgBozuk paketleri, karşılanmayan bağımlılıkları veya takılıp kalan kurulumları düzeltin.
• grubÖnyükleme yöneticisi yapılandırmasını yeniden oluşturun.

Bu seçenekleri sırayla çalıştırmak, genellikle güncellemeler sırasında yaşanan elektrik kesintileri, bozuk paketler veya dolmak üzere olan diskler nedeniyle oluşan birçok sorunu çözer . Ardından, sistem genellikle önyükleme işleminin normale dönüp dönmediğini kontrol etmek için yeniden başlatmayı teklif eder.

Azure gibi bulut ortamlarında , acil durum ve tek kullanıcı modlarına ek olarak, Azure Linux Otomatik Onarım (ALAR) ve az vm repair komutu gibi , sürecin bir bölümünü otomatikleştiren özel araçlar bulunur: bunlar sistem diskini bir kurtarma sanal makinesine bağlar, tipik yapılandırmaları düzeltmek için "auditd" gibi eylemleri çalıştırır ve bir sorun oluşması durumunda kolayca geri dönmenizi sağlar.

Veri kaybı olmadan Linux'u yeniden yükleme stratejileri

Bazı durumlarda, ne kadar araştırırsanız araştırın, sistem o kadar bozulmuş veya donanımınız o kadar sıra dışı (örneğin HP N150 veya egzotik kontrolcülere sahip modern dizüstü bilgisayarlar gibi) olabilir ki, yapılacak en mantıklı şey dağıtımı yeniden yüklemektir . Ancak bu, verilerinizin tamamını kaybetmeniz anlamına gelmez.

Ubuntu ve türevleri gibi birçok dağıtım, kurulum sırasında "belgeleri ve ayarları koruyarak işletim sistemini yeniden yükle " adı verilen bir seçenek sunar. Bu, temel sistemi yeniden yükler ancak /home dizininizi ve bazen de bazı yüklü uygulamaları korumaya çalışır. Bu kullanışlı bir seçenektir, ancak kusursuz değildir, bu nedenle kaybetmek istemediğiniz her şeyi manuel olarak yedeklemeniz önerilir .

Gelecekteki yeniden kurulumlara karşı en sağlam koruma yöntemi, diski birkaç ayrı bölüme ayırmaktır :

• Bir tanesi / (kök): temel sistem.
• Bir diğeri de /çizme (ve UEFI'de /boot/efi) önyükleme üzerinde daha fazla kontrol istiyorsanız.
• Özel bir bölüm / Ana Sayfa veya veri için.

Bu sayede, Linux sisteminiz kullanılamaz hale gelirse, veri bölümüne dokunmadan yalnızca sistem ve önyükleme bölümlerini biçimlendirebilirsiniz . Her şey için yalnızca bir bölümünüz olsa bile, canlı bir ortamdan önyükleme yapabilir, diski bağlayabilir, belgeleri harici bir sürücüye veya buluta kopyalayabilir ve her şey güvenli hale geldikten sonra temiz bir kurulum gerçekleştirebilirsiniz.

VirtualBox, VMware veya bulut tabanlı sanal makinelerde, veri disklerini sistem diskinden ayırmak iyi bir fikirdir . Örneğin Azure'da, işletim sistemi arızasının verileri de etkilemesini önlemek için LVM veri birimlerinin sistem diskiyle aynı birim grubunda karıştırılmaması önerilir.

Sorunların tekrarını önlemek için en iyi uygulamalar

Sistem başlatma hatasıyla başa çıktıktan ve sisteminizi (veya en azından verilerinizi) kurtardıktan sonra yapılacak en akıllıca şey, bir sonraki sefer aynı sorunun yaşanmasını önlemek veya tamamen engellemek için bazı adımlar atmaktır.

İlk olarak, sisteminizi ve yazılımlarınızı güncel tutun , ancak bunu mantıklı bir şekilde yapın. Arch gibi sürekli güncellenen dağıtımlarda sık güncellemeler şarttır; daha muhafazakar olanlarda (Debian Stable, Ubuntu LTS) güncellemeleri biraz daha aralıklı yapabilirsiniz, ancak yıllarca dokunmadan bırakmak tavsiye edilmez. Büyük çekirdek veya sürüm değişikliklerinden önce her zaman iyi bir yedekleme yapın.

Bir diğer çok sağlıklı alışkanlık da şudur: Yapılan tüm önemli yapılandırma değişikliklerini belgeleyin.Hangi dosyaya dokunduğunuzu, hangi satırı değiştirdiğinizi ve öncesinde nasıl olduğunu gösterir. Basit bir yöntem, orijinal dosyanın bir kopyasını her zaman uzantısıyla birlikte kaydetmektir. .bak (örneğin, sshd_config.bakBöylece bir hata yapmanız durumunda kolayca geri yükleyebilirsiniz.

Verilerle ilgili olarak, düzenli yedeklemeler şarttır . Artımlı yedeklemeler için rsync, tüm dizinleri paketlemek için tar veya bulut ve NAS çözümlerini kullanabilirsiniz. Ayrıca, verileriniz sistem bölümünden farklı bir bölümdeyse, disk önyükleme yapmasa bile büyük bir sorun yaşamadan yeniden yükleyebilirsiniz.

Son olarak, sistemin sağlığını düzenli olarak izlemek her zaman iyi bir fikirdir: SMART'ı aylık olarak kontrol edin, kritik bölümlerdeki (/, /var, /home) inode'ları ve boş alanı izleyin, tekrarlayan mesajlar için günlükleri inceleyin ve fiziksel ekipmanlardaki sıcaklık ve toz seviyelerini düşük tutun. Basit bir bakım rutini, "aniden" önyüklemeyi durduran makineleri düzeltmek için harcanacak birçok sabahı kurtarır.

Bu teknikler, komutlar ve en iyi uygulamalar cephaneliğiyle, Linux'ta önyükleme sorunlarını ve donanım hatalarını teşhis etmek ve onarmak artık bir inanç meselesi olmaktan çıkıp oldukça makul bir süreç haline geliyor: Öncelikle, hatanın diskten, dosya sisteminden, GRUB'dan, çekirdekten, yapılandırmadan veya donanımdan kaynaklanıp kaynaklanmadığını belirliyorsunuz; ardından uygun aracı uyguluyorsunuz (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, kurtarma modları vb.); ve en kötü senaryoda, dünyanın sonu gelmeden yeniden yükleme yapmanıza olanak tanıyan ayrı bölümler ve yedeklemelerle iyi organize edilmiş bir B planınız oluyor.