İPUCUEmergency shell çoğu zaman sadece fstab UUID hatası değildir; altta dosya sistemi bozulmuş olabilir.
UYARIUUID’yi düzeltirsem açılır” deyip BTRFS hatalarını görmezden gelme.
MIND MAP
ÖNEMLİ
- Hipotez geliştir.
- Arch Linux Live erişimi gerçekleştir.
- Şifreli diski aç.
- Onarımı gerçekleştir.
- Fstab düzenle.
- Bağlantıyı kes, yeniden başlat.
OLAY
Selam dostum. Sorun şu ki, bilgisayarımı görünür bir sorun yokken kapattım. Saatler sonra açtığımda disk şifresi girildikten sonra sistem “emergency shell” ekranında kaldı. Kritik hata mesajları şunlardı: mount: ... fsconfig() failed ve ERROR: Failed to mount 'UUID=...'. Yani önyükleme sırasında kök (root) dosya sistemi, UUID ile bulunup bağlanamadı.
Bu yazıda; adım adım teşhisi, kök nedenin netleştirilmesini ve sistemi tekrar ayağa kaldırmak için uygulanan teknik adımları bir kurtarma rehberi gibi toparladım.
OLAY ÇÖZÜM VE GELİŞİMİ
1. HİPOTEZ
Önyükleme “emergency shell”e düştü ve hata mesajında kök bölüm için UUID=9d... göründü.
İlk hipotezim şu olmuştu: /etc/fstab içinde yanlış UUID vardır ve sistem yanlış bölümü arıyordur. Ama kritik nokta: UUID doğru olsa bile dosya sistemi bozuksa mount yine başarısız olur. O kısma geldiğimizde bunu da göstereceğim.
2. ARCH LINUX LIVE ERİŞİMİ
Teşhis ve kurtarma için Arch Linux Live ortamına eriştim. Bu sayede şüpheli sistemden bağımsız analiz yapacaktım.
2.1 Disk Bölümlerini Tespit Ettim
fdisk -l ile diski inceledim. Ana disk /dev/nvme0n1 ve iki bölüm vardı:
- EFI ->
nvme0n1p1 - Linux Dosya Sistemi ->
nvme0n1p2
Ardından blkid ile UUID’yi kontrol ettim. /dev/nvme0n1p2 için doğru UUID 645f... olarak bulundu; bu, hata ekranındaki 9d... ile farklıydı. Ayrıca disk bölümümü daha önce LUKS ile şifrelediğim için önce diski açmalıydım.
2.2 Şifreli Bölümü Açtım (LUKS)
Önce LUKS bölümünü aşağıdaki komut ile şifremi girip açtım:
sudo cryptsetup open /dev/nvme0n1p2 cryptroot
- Buradaki
cryptroot, açılan eşlemenin adıdır.
3. MOUNT DENEMESİ - KRİTİK SİNYAL
Root’u live sisteme bağlamak için dizin oluşturdum ve mount etmeyi denedim:
sudo mkdir /mnt/archiso
sudo mount /dev/mapper/cryptroot /mnt/archiso
Ancaaak! Burada gelen hatalar sorunun “sadece UUID” olmadığını söyledi.
BTRFS: error (device dm-0) in btrfs_replay_log:2100: errno=-5 IO failure (Failed to recover log tree)
BTRFS: error (device dm-0 state E): open_ctree failed: -5
mount: /mnt/archiso: can't read superblock on /dev/mapper/cryptroot
Kısa çeviriyle:
- log tree kurtarılamıyor → BTRFS meta verilerinde bozulma var
- errno=-5 I/O failure → okuma hatası var
- superblock okunamıyor → dosya sistemi mount edilemez
İşte “yanlış anlama” tam burada kırılıyor: fstab’daki UUID’yi düzeltmek tek başına yetmiyor; önce BTRFS bozulmasını ele almak gerekiyor.
Araştırmalarımın sonunda onarım için şu komutu yazmam gerektiğini öğrendim:
sudo btrfs check --repair /dev/mapper/cryptroot
4. ONARIM
Disk live’a bağlı değilken onarım denedim:
sudo btrfs check --repair /dev/mapper/cryptroot
Komut, veri kaybı riskiyle ilgili uyarı verdi; burada tercihen devam ettim. Bütün verilerim kaybolabilirdi. (Benim için sorun değildi çünkü yedekli; senin için olmayabilir.)
Sonrasında mount etmeyi tekrar denedim ve hata almadım:
sudo mount /dev/mapper/cryptroot /mnt/archiso
5. FSTAB DÜZELTİMİ
sudo nano /mnt/cryptroot/@/etc/fstab
Dosyada /home, /var/cache, /var/log gibi satırların aynı UUID’yi kullanması normaldir; çünkü BTRFS aynı disk üzerinde subvolume (alt bölüm) mantığıyla çalışır.
Asıl sorun, root satırındaki 9d... UUID’siydi. Bu satırdaki UUID, blkid ile bulunan doğru UUID 645f... ile değiştirildi.
6. BAĞLANTIYI KES - YENİDEN BAŞLAT
Yeniden başlatmadan önce disk bağlantısı kesildi:
sudo umount /dev/mapper/cryptroot
Ardından:
reboot
OLAY SONUCU VE ÇIKARIMLAR
- Kök neden: Sistem düzgün kapanmadan (shutdown tamamlanmadan) güç durumunun kesilmesiyle BTRFS meta verilerinde bozulma oluştu.
- Etkisi:
superblockvelog treegibi kritik meta veriler okunamayınca root mount edilemedi ve sistem “emergency shell”e düştü. - Çözüm: Önce
btrfs check --repairile onarım yapıldı, ardındanfstabiçindeki yanlış UUID düzeltilerek sistem normal çalışmaya döndü.
REFLEKS
UYARI“Bunu görürsem → şunu düşüneceğim → şunu yapacağım”
- Tetikleyici: “emergency shell” +
Failed to mount 'UUID=...'- Düşünce: “Sadece fstab değil; BTRFS bozulmuş olabilir.”
- Aksiyon: Live aç →
blkidkontrol et → LUKS aç → mount hatalarını oku → gerekirsesudo btrfs check --repair /dev/mapper/cryptroot→ sonrafstabUUID düzelt.
MINIMUM BİLGİ SETİ
UYARIANA MESAJ
- “Emergency Shell”de kaldıysan önce BTRFS bozulmasını doğrula/onar, sonra fstab UUID’yi düzelt.
UNUTMA
- Ekrandaki UUID hatası bazen sadece görünen kısımdır—altta BTRFS
log tree/superblockkırılmış olabilir.Mind Map
- Live ortamda disk/UUID tespiti (
fdisk -l,blkid)- LUKS aç → mount dene → BTRFS hatalarını doğrula
btrfs check --repair+fstabUUID düzelt → rebootÖNERİ
shutdownsonrası cihazın kapağını “hemen” kapatma; kapanış tamamlanana kadar bekle.
Bazı bilgiler güncel olmayabilir.
