Mint 22.1'de boot sırasında busybox'a düşüp
Hatanın özü şu: ext4 journal'ında veri var ama superblock'taki
Burada
İlk yapman gereken:
Eğer hala aynı hatayı alıyorsan journal'ı bypass edip doğrudan onarım denemek gerekebilir:
Bu sadece journal'daki transaction'ları replay eder, dosya sisteminin geri kalanına dokunmaz.
En kötü senaryoda journal'ı komple sıfırlayıp yeniden oluşturmak işe yarar:
Bu işlem sırasında son birkaç saniyelik yazma işlemi kaybolabilir ama sistem açılır hale gelir.
Bu arada busybox ortamında disk zaten read-only mount edilmemiştir diye düşünme; bazen kernel panic'i önlemek için ro mount edebiliyor. Emin olmak için:
Eğer
Benim vakada
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY hatasını alanlar için durumu netleştireyim. Aynı senaryoyu geçen hafta bir NVMe diskte yaşadım.Hatanın özü şu: ext4 journal'ında veri var ama superblock'taki
needs_recovery flag'i kalkmış. Kernel bu çelişkiyi görünce mount etmeyi reddediyor, doğrudan initramfs shell'ine atıyor.
Kod:
(initramfs)Burada
fsck -f /dev/nvme0n1p5 komutunu verdiğinde status code 4 almanın sebebi, fsck'in hataları tespit etmesine rağmen onarmaması. Çünkü onay bekliyor ya da journal recovery için ek parametre şart.İlk yapman gereken:
Kod:
e2fsck -fy /dev/nvme0n1p5-f force check, -y ise tüm sorulara otomatik yes cevabı verir. Bu komut genelde işi çözer.Eğer hala aynı hatayı alıyorsan journal'ı bypass edip doğrudan onarım denemek gerekebilir:
Kod:
e2fsck -f -E journal_only /dev/nvme0n1p5En kötü senaryoda journal'ı komple sıfırlayıp yeniden oluşturmak işe yarar:
Kod:
tune2fs -O ^has_journal /dev/nvme0n1p5
e2fsck -f /dev/nvme0n1p5
tune2fs -j /dev/nvme0n1p5Bu arada busybox ortamında disk zaten read-only mount edilmemiştir diye düşünme; bazen kernel panic'i önlemek için ro mount edebiliyor. Emin olmak için:
Kod:
mount | grep nvme0n1p5(ro) ibaresini görürsen fsck'ten önce remount yapmana gerek yok, fsck zaten unmount edilmiş partition üzerinde çalışmalı.Benim vakada
e2fsck -fy direkt çözdü, reboot sonrası sistem açıldı.