Sistem Açılmıyor: GRUB ve Boot Sorunlarını Giderme

Sabah erkenden işe geliyorsun, kritik bir sunucunun ekranında sadece siyahlık var ya da “GRUB rescue>” promptu seni karşılıyor. Kalp atışın hızlandı, ellerin biraz titredi. Bu his tanıdık geliyor mu? Linux sysadmin’lerin büyük çoğunluğu kariyerlerinde en az bir kez bu kabusla yüzleşir. İyi haber şu: GRUB ve boot sorunlarının büyük çoğunluğu kurtarılabilir ve bu yazıda adım adım nasıl yapacağını anlatacağım.

Önce Durumu Anlamak: Hata Mesajını Oku

Paniklemeden önce ekrandaki hata mesajını dikkatlice oku. GRUB hataları genellikle sana ne olduğunu açıkça söyler, sadece dinlemek gerekiyor.

En sık karşılaşılan durumlar şunlar:

• “GRUB rescue>”: GRUB ana konfigürasyon dosyasını veya modülleri bulamıyor
• “error: unknown filesystem”: GRUB boot partition’ı tanımıyor
• “error: no such partition”: Belirtilen partition mevcut değil veya değiştirilmiş
• “Minimal BASH-like line editing is supported”: GRUB menüsü yüklenemedi ama temel kabuk çalışıyor
• Siyah ekran, imleç yanıp sönüyor: Bootloader hiç yüklenemiyor
• “Operating System not found”: MBR veya EFI kayıtları bozulmuş

Bu hata mesajlarını not et, sonraki adımlarda ne yapman gerektiğini belirleyecek.

GRUB Rescue Promptundan Sistemi Geçici Olarak Açmak

Eğer grub rescue> promptundaysan, sistemi geçici olarak ayağa kaldırabilirsin. Bu kalıcı çözüm değil ama sisteme girip onarımı yapman için yeterli.

Önce mevcut partition’ları listele:

grub rescue> ls
(hd0) (hd0,msdos1) (hd0,msdos2) (hd0,msdos3)

Hangi partition’da Linux kurulu olduğunu bulmak için her birini dene:

grub rescue> ls (hd0,msdos1)/
grub rescue> ls (hd0,msdos2)/
grub rescue> ls (hd0,msdos3)/

/boot/grub dizinini veya etc/ gibi Linux dizinlerini gördüğünde doğru partition’ı buldun demektir. Diyelim ki (hd0,msdos2) doğru partition:

grub rescue> set root=(hd0,msdos2)
grub rescue> set prefix=(hd0,msdos2)/boot/grub
grub rescue> insmod normal
grub rescue> normal

Bu komutlar GRUB’ı normal modda başlatır ve tanıdık menüyü görürsün. Sisteme giriş yaptıktan sonra kalıcı onarımı yapabilirsin.

Live USB ile Chroot Ortamı Hazırlamak

Çoğu ciddi boot sorununda Live USB senin en iyi arkadaşın. Ubuntu, Debian veya kullandığın dağıtımın Live ISO’sunu boot edip sistemi chroot ile mount et.

# Live sistemde önce disk yapısını gör
lsblk -f
fdisk -l

# Root partition'ı mount et (örnek: /dev/sda2)
mount /dev/sda2 /mnt

# Eğer ayrı bir /boot partition'ı varsa
mount /dev/sda1 /mnt/boot

# EFI sistemi varsa EFI partition'ı da mount et
mount /dev/sda1 /mnt/boot/efi

# Gerekli sistem dizinlerini bind mount et
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run

# Chroot içine gir
chroot /mnt

Artık sanki kendi sistemindeymişsin gibi komut çalıştırabilirsin. Bu noktadan sonra yapacağın tüm değişiklikler gerçek sistemi etkiler.

GRUB’ı Yeniden Yüklemek

Chroot ortamına girdikten sonra GRUB’ı yeniden yüklemek genellikle sorunların büyük çoğunluğunu çözer.

BIOS/MBR sistemler için:

# GRUB'ı MBR'a yaz (sda = disk, partition numarası değil)
grub-install /dev/sda

# GRUB konfigürasyonunu yenile
update-grub

# Veya grub-mkconfig ile
grub-mkconfig -o /boot/grub/grub.cfg

UEFI sistemler için:

# EFI partition mount edilmiş mi kontrol et
ls /boot/efi/EFI/

# GRUB EFI için yükle
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

# Konfigürasyonu güncelle
update-grub

Eğer update-grub komutu çalışmıyorsa veya kernel’leri doğru bulmuyorsa, /boot dizininin doğru mount edilip edilmediğini kontrol et.

Gerçek Dünya Senaryosu: Disk Değişimi Sonrası UUID Sorunu

Geçen ay bir müşterinin sunucusunda tam bu durumla karşılaştım. Sistem diski değiştirilmişti, yeni disk takılmıştı ama GRUB “no such partition” hatası veriyordu. Sorun UUID’di.

Eski disk değişince UUID’ler de değişiyor, ama /etc/fstab ve GRUB konfigürasyonu hala eski UUID’leri gösteriyordu.

# Mevcut partition UUID'lerini gör
blkid

# Örnek çıktı:
# /dev/sda1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"
# /dev/sda2: UUID="b2c3d4e5-f6a7-8901-bcde-f12345678901" TYPE="swap"

# fstab dosyasını kontrol et
cat /etc/fstab

fstab’da eski UUID’ler varsa düzeltmen gerekiyor:

# fstab'ı düzenle
nano /etc/fstab

# Her satırdaki UUID'leri blkid çıktısıyla eşleştir
# Kaydet ve çık

# GRUB konfigürasyonunu yenile
update-grub

Bu basit adım o sunucuyu kurtardı. Disk değişimi, klonlama veya snapshot restore işlemlerinden sonra UUID sorunları çok yaygın.

Kernel Panik Durumlarını Ele Almak

Bazen sistem GRUB menüsünü gösteriyor ama kernel yüklenirken paniğe giriyor. Ekranda uzun bir hata mesajı görürsün ve sistem donar.

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Bu hata genellikle initramfs’in bozulduğunu veya root partition’ın bulunamadığını gösteriyor.

GRUB menüsünde eski bir kernel varsa önce onu dene. “Advanced options” altında bir önceki kernel versiyonunu seç. Sistem açılıyorsa yeni kernel’in kurulumu sırasında bir sorun çıkmış demektir.

Chroot ortamından initramfs’i yeniden oluştur:

# Mevcut kernel versiyonlarını listele
ls /boot/vmlinuz*

# Spesifik kernel için initramfs oluştur
update-initramfs -u -k 5.15.0-76-generic

# Tüm kernel'ler için
update-initramfs -u -k all

# GRUB'ı güncelle
update-grub

Red Hat/CentOS/Rocky Linux kullanıyorsan komutlar biraz farklı:

# initramfs yeniden oluştur
dracut --force /boot/initramfs-$(uname -r).img $(uname -r)

# Veya tüm kernel'ler için
dracut --regenerate-all --force

UEFI Sistemlerde Sık Karşılaşılan Sorunlar

Modern sunucuların çoğu UEFI kullanıyor ve bu beraberinde farklı sorunlar getiriyor.

EFI Boot Entry kayboldu:

Bazen firmware güncellemesi veya başka bir OS kurulumu EFI boot entry’lerini siliyor.

# Mevcut EFI boot entry'lerini listele
efibootmgr -v

# GRUB entry'si yoksa manuel ekle
efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/ubuntu/grubx64.efi --label "Ubuntu"

# Boot sıralamasını değiştir
efibootmgr --bootorder 0000,0001,0002

Secure Boot sorunları:

Bazı durumlarda Secure Boot özelleştirilmiş kernel veya driver’larla çakışıyor.

# Secure Boot durumunu kontrol et
mokutil --sb-state

# Eğer sorun Secure Boot'tan kaynaklanıyorsa BIOS'tan geçici olarak kapat
# veya MOK (Machine Owner Key) kaydet

EFI partition bozulması:

# EFI partition'ı kontrol et
fsck /dev/sda1

# FAT dosya sistemi için
dosfsck -r /dev/sda1

GRUB Konfigürasyon Dosyasını Manuel Düzenlemek

Bazen update-grub otomatik olarak doğru konfigürasyonu oluşturmuyor. /boot/grub/grub.cfg dosyasını anlamak önemli.

Dikkat: grub.cfg dosyasını doğrudan düzenlemek önerilmez çünkü update-grub çalıştırıldığında üzerine yazılır. Bunun yerine /etc/default/grub ve /etc/grub.d/ dizinindeki dosyaları düzenle.

# Ana GRUB ayarları
nano /etc/default/grub

# Önemli parametreler:
# GRUB_DEFAULT=0          -> Varsayılan boot seçeneği
# GRUB_TIMEOUT=5          -> Menü bekleme süresi (saniye)
# GRUB_CMDLINE_LINUX=""   -> Kernel parametreleri
# GRUB_HIDDEN_TIMEOUT=0   -> Menüyü gizle

# Değişiklikten sonra mutlaka çalıştır:
update-grub

Sorun giderme sırasında kernel parametrelerine geçici olarak ekleme yapmak gerekebilir. GRUB menüsünde ilgili entry’e gelip e tuşuna bas, linux satırının sonuna parametreleri ekle:

• nomodeset: Grafik driver sorunları için
• single: Single-user mode için
• init=/bin/bash: Sadece bash başlatmak için
• ro: Root’u read-only mount et
• rw: Root’u read-write mount et

Disk ve Dosya Sistemi Sorunları

Bazen sorun GRUB’da değil, altındaki disk veya dosya sisteminde. Sistemi açmadan önce dosya sistemi kontrolü yapmak önemli.

# Önce disk sağlığını kontrol et
smartctl -a /dev/sda

# Root partition'ı unmount edip kontrol et
# (Önce başka bir terminal veya live sistemden yap)
umount /dev/sda2

# ext4 dosya sistemi kontrolü
e2fsck -f /dev/sda2

# Otomatik onarım
e2fsck -y /dev/sda2

# XFS dosya sistemi için
xfs_repair /dev/sda2

LVM kullanan sistemlerde:

Birçok kurumsal Linux kurulumu LVM kullanıyor. Boot sırasında “Volume group not found” hatası alıyorsan:

# LVM modüllerini yükle
modprobe dm-mod

# Volume group'ları tara
vgscan

# Volume group'ları aktif et
vgchange -ay

# Logical volume'ları listele
lvs

# Mount et
mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt

Gerçek Dünya Senaryosu: Yanlış fstab Girişi

Bir başka klasik senaryo: Sistem yöneticisi yeni bir disk ekledi, fstab’a mount point ekledi ama bir yazım hatası yaptı. Sistem bir sonraki açılışta boot etmedi.

Bu durumda sistem genellikle emergency mode’a düşer veya şu mesajı verir:

[FAILED] Failed to mount /data.
See 'journalctl -xe' for details.
[DEPEND] Dependency failed for Local File Systems.

Çözüm için root şifresini gir ve fstab’ı düzelt:

# Emergency shell'de root filesystem'i read-write yap
mount -o remount,rw /

# fstab'ı düzenle
nano /etc/fstab

# Hatalı satırı bul ve düzelt veya yorum satırına al
# Kaydet

# Dosya sistemlerini yeniden mount et
mount -a

# Hata yoksa yeniden başlat
reboot

Eğer sisteme giremiyorsan chroot yöntemini kullan.

Grub2 ile BTRFS ve Şifreli Sistemler

Modern Ubuntu ve bazı Fedora kurulumları BTRFS veya LUKS şifreleme kullanıyor. Bu durumlarda boot süreci daha karmaşık.

LUKS şifreli sistemde GRUB onarımı:

# Şifreli partition'ı aç
cryptsetup luksOpen /dev/sda2 crypt_root

# Mount et
mount /dev/mapper/crypt_root /mnt

# LVM varsa
vgchange -ay
mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt

# Normal chroot adımlarını uygula
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

# GRUB onarımı
update-grub
grub-install /dev/sda

BTRFS subvolume sorunları:

# BTRFS subvolume'ları listele
btrfs subvolume list /mnt

# Doğru subvolume'u mount et
mount -o subvol=@ /dev/sda2 /mnt

Önleyici Tedbirler: Bu Sorunu Bir Daha Yaşamamak İçin

Sorun gidermek güzel ama önlemek daha güzel. İşte uygulamanı tavsiye ettiğim pratik önlemler:

• GRUB konfigürasyonunu yedekle: Her büyük değişiklikten önce /boot/grub/grub.cfg ve /etc/default/grub dosyalarını yedekle
• Kernel güncellemelerinde dikkatli ol: Production sunucularda yeni kernel’i test ortamında önce dene
• fstab değişikliklerini test et: mount -a komutu ile yeni girişlerin çalıştığını reboot’tan önce test et
• Live USB hazır tut: Bootable USB her zaman erişilebilir bir yerde olsun
• SMART izleme kur: Disk sağlığını düzenli izle, ani arızaları önceden fark et
• Snapshot kullan: LVM veya BTRFS snapshot’ları özellikle kernel güncellemelerinden önce al
• EFI backup: efibootmgr çıktısını düzenli olarak kaydet

# Basit bir GRUB backup scripti
#!/bin/bash
BACKUP_DIR="/root/grub-backups/$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR
cp /etc/default/grub $BACKUP_DIR/
cp /boot/grub/grub.cfg $BACKUP_DIR/
cp /etc/fstab $BACKUP_DIR/
efibootmgr -v > $BACKUP_DIR/efi-entries.txt
echo "Backup tamamlandi: $BACKUP_DIR"

Bu scripti crontab’a ekleyebilir veya paket yüklemelerinden sonra otomatik çalıştırabilirsin.

Sistemboot Durumunu İzlemek

Sorunları daha hızlı teşhis etmek için boot süreci loglarını bilmek önemli.

# Son boot loglarını gör
journalctl -b

# Son 3 boot'un loglarını karşılaştır
journalctl --list-boots

# Belirli bir boot'un loglarını gör (0 = şu anki, -1 = bir önceki)
journalctl -b -1

# Boot süresi analizi
systemd-analyze blame
systemd-analyze critical-chain

Kritik sistemlerde boot loglarını merkezi log sunucusuna göndermek, özellikle uzak lokasyonlardaki makinelerde hayat kurtarıcı olabilir.

Sonuç

GRUB ve boot sorunları ilk başta ürkütücü görünüyor ama aslında sistematik bir yaklaşımla büyük çoğunluğu çözülebilir. Önce hata mesajını oku, sonra Live USB ile chroot ortamı kur, sonra sırasıyla GRUB, initramfs ve fstab’ı kontrol et.

Aklında tutman gereken ana noktalar şunlar: UUID değişiklikleri disk işlemlerinden sonra en sık boot sorununa yol açan sebep. update-grub ve grub-install komutları sorunların büyük çoğunluğunu hallediyor. UEFI sistemlerde EFI partition’ının doğru mount edilmesi kritik. Kernel paniği durumunda önce eski kernel’i dene, sonra initramfs’i yeniden oluştur.

Son olarak, production sistemlerde her zaman bir recovery planın olsun. Live USB hazır tut, root şifreni bil, sisteme fiziksel erişimin olduğundan emin ol. Boot sorunlarının çoğu uzaktan çözülemiyor ve bu gerçekliği kabul edip hazırlıklı olmak sysadmin’liğin temel prensiplerinden biri.

Bir dahaki “sistem açılmıyor” krizinde umarım bu yazı sana rehber olur. Yorumlar bölümünde kendi boot sorun hikayelerini paylaşabilirsin, beraber çözeriz.