Rocky Linux Sistem Kurtarma ve Rescue Modu Kullanımı

yazar

Sistem yöneticiliğinde en stresli anlardan biri, bir sunucunun açılmaması ve önünüzde kara bir ekranla baş başa kalmanızdır. Rocky Linux kullanıyorsanız ve sistem bir şekilde boot edemiyorsa, panik yapmadan önce rescue modunun sunduğu güçlü araçları kullanabilirsiniz. Bu yazıda gerçek dünya senaryoları üzerinden Rocky Linux’ta sistem kurtarma sürecini adım adım ele alacağız.

Rescue Modu Nedir ve Ne Zaman Kullanılır?

Rescue modu, sistemin normal şekilde açılamadığı durumlarda minimum bir ortam sağlayan özel bir boot modudur. Rocky Linux’ta rescue modu, kurulum medyasından ya da GRUB üzerinden başlatılabilir. Bu mod sayesinde bozuk dosya sistemlerine erişebilir, hatalı konfigürasyon dosyalarını düzeltebilir ve sistemi kurtarabilirsiniz.

Rescue moduna ihtiyaç duyduğunuz tipik senaryolar şunlardır:

  • GRUB bozulması: Bootloader yanlış yapılandırıldı ya da silindi
  • Bozuk fstab: /etc/fstab dosyasındaki hatalı bir satır sistemi tamamen kilitler
  • Unutulan root şifresi: Root parolasını sıfırlamak gerekiyor
  • Bozuk dosya sistemi: fsck çalıştırılması gereken durumlar
  • Kernel panik: Yanlış kernel parametreleri ya da modül sorunları
  • SELinux kilitlemeleri: SELinux politikası sistemi açılmaz hale getirdi

GRUB Üzerinden Rescue Moduna Giriş

Sistem açılırken GRUB menüsü göründüğünde, birkaç farklı yöntemle kurtarma moduna geçebilirsiniz.

Tek Kullanıcı Moduna Geçmek

GRUB menüsünde Rocky Linux girdisini seçip e tuşuna basın. Açılan editörde linux ile başlayan satırı bulun ve satırın sonuna aşağıdaki parametreyi ekleyin:

# GRUB editöründe linux satırının sonuna eklenecek parametre
rd.break

rd.break parametresi, initramfs ortamında sistemi durdurur ve size bir shell açar. Bu noktada /sysroot altında asıl dosya sistemine erişebilirsiniz.

# rd.break ile açılan shell'de sistemi mount etmek
mount -o remount,rw /sysroot
chroot /sysroot

# Şimdi asıl sistemdeyiz, şifreyi değiştirebiliriz
passwd root

# SELinux context'ini düzeltmek için
touch /.autorelabel
exit
exit

Burada touch /.autorelabel komutu kritik öneme sahiptir. SELinux aktifse ve şifre dosyasını değiştirdiyseniz, bu dosya olmadan sistem açılış sırasında SELinux hataları üretir.

systemd.unit Parametresi ile Kurtarma

Alternatif olarak GRUB satırına şu parametreyi ekleyebilirsiniz:

# Rescue target için
systemd.unit=rescue.target

# Ya da daha minimal olan emergency target için
systemd.unit=emergency.target

emergency.target ile açıldığınızda dosya sistemi salt okunur olarak bağlanır. rescue.target ise daha fazla servis başlatır ve root şifresi ister.

Kurulum Medyasından Rescue Moduna Giriş

Sistem hiç açılamıyorsa, Rocky Linux ISO’sundan boot etmeniz gerekir. Bu en güvenilir yöntemdir çünkü tamamen bağımsız bir ortam sağlar.

Rocky Linux ISO ile boot ettikten sonra şu adımları izleyin:

  1. Boot menüsünden “Troubleshooting” seçeneğini seçin
  2. “Rescue a Rocky Linux system” seçeneğine tıklayın
  3. Sistem mevcut kurulumu bulmaya çalışacak ve genellikle /mnt/sysimage altına mount edecektir
# ISO rescue modunda sistemin mount durumunu kontrol etmek
df -h
lsblk

# Eğer otomatik mount başarısız olduysa manuel mount
mount /dev/sda2 /mnt/sysimage

# LVM kullanan sistemlerde önce LVM'i aktif etmek gerekir
vgscan
vgchange -ay
mount /dev/mapper/rl-root /mnt/sysimage

# chroot ile asıl sisteme geçiş
chroot /mnt/sysimage

# Gerekli dosya sistemlerini bağlamak
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -o bind /dev /dev

Senaryo 1: Bozuk fstab Düzeltme

Bu durum tahmin ettiğinizden çok daha sık yaşanır. Bir diski fstab’a eklerken UUID yerine /dev/sdb1 gibi bir ifade yazdınız ve disk sıralamasi değişti. Ya da NFS mount noktası için _netdev seçeneğini eklemeyi unuttunuz ve sistem ağa erişemeden askıya aldı.

# rd.break veya rescue modunda, sisteme chroot yaptıktan sonra
# Önce mevcut fstab'ı yedekle
cp /etc/fstab /etc/fstab.bak

# Mevcut fstab'ı görüntüle
cat /etc/fstab

# Nano veya vi ile düzenle
vi /etc/fstab

# Doğru UUID'leri bulmak için
blkid

# fstab sözdizimini test et
mount -a

# Hata vermiyorsa sorun giderilmiştir

Gerçek bir örnekle açıklayalım. Bir müşteri sunucusunda fstab şöyle görünüyordu:

# /etc/fstab - hatalı örnek
/dev/sdb1    /data    xfs    defaults    0    0

# Doğrusu UUID ile olmalıydı
UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890    /data    xfs    defaults    0    2

/dev/sdb1 ifadesi, disk sıralaması değiştiğinde farklı bir diske işaret edebilir. Bu nedenle her zaman UUID kullanmak kritik önem taşır.

Senaryo 2: GRUB Bootloader’ı Yeniden Yüklemek

Bazen yanlışlıkla MBR veya EFI bölümü bozulabilir ya da başka bir işletim sistemi kurulurken üzerine yazılabilir.

# Rescue modunda chroot yaptıktan sonra
# BIOS/MBR sistem için GRUB yeniden yüklemek
grub2-install /dev/sda

# EFI sistem için
# Önce EFI bölümünü mount et
mount /dev/sda1 /boot/efi

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

# GRUB konfigürasyon dosyasını yeniden oluştur
grub2-mkconfig -o /boot/grub2/grub.cfg

# EFI sistemlerde konfigürasyon farklı yerde
grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

EFI sistemlerde efibootmgr ile boot girişlerini de kontrol etmek gerekebilir:

# Mevcut EFI boot girişlerini listele
efibootmgr -v

# Bozuk ya da fazla giriş varsa sil (XXXX boot girişinin numarasıdır)
efibootmgr -b XXXX -B

# Yeni boot girdisi ekle
efibootmgr -c -d /dev/sda -p 1 -L "Rocky Linux" -l 'EFIrockyshimx64.efi'

Senaryo 3: Dosya Sistemi Kontrolü ve Onarımı

Beklenmedik bir kapanma ya da donanım sorunu sonrası dosya sistemi tutarsız hale gelebilir. XFS ve ext4 için farklı araçlar kullanılır.

# Dosya sistemini önce unmount etmek gerekir
# XFS dosya sistemi kontrolü
xfs_repair /dev/sda2

# Eğer mount edilmişse önce unmount et
umount /dev/sda2
xfs_repair /dev/sda2

# XFS'de sadece kontrol yapmak için (değişiklik yapmadan)
xfs_repair -n /dev/sda2

# ext4 dosya sistemi kontrolü
fsck.ext4 -f /dev/sda2

# ext4 otomatik onarım
fsck.ext4 -y /dev/sda2

# Tüm dosya sistemlerini kontrol et (fstab'a göre)
fsck -A -y

XFS ile ilgili önemli bir not: XFS dosya sistemi mount edilmişken xfs_repair çalıştırmayın. Bu ciddi veri kaybına yol açabilir. Rescue modunun avantajı tam da buradadır; dosya sistemleri genellikle mount edilmeden erişilebilir durumdadır.

# XFS log'unu temizlemek (dikkatli kullanın)
xfs_repair -L /dev/sda2

# XFS dosya sistemi bilgilerini görüntüle
xfs_info /dev/sda2

# XFS metadata dökümü al
xfs_metadump /dev/sda2 /tmp/metadata.dump

Senaryo 4: Root Şifresini Sıfırlamak

Bu senaryo hem en sık karşılaşılan hem de en hızlı çözülen durumdur. Bir sunucuyu devraldınız ve root şifresi kayıp. Ya da üretim sisteminde şifre manager’ı bir şekilde erişilemez hale geldi.

# GRUB'da rd.break ile boot et
# Shell açıldıktan sonra

# /sysroot'u okuma-yazma modunda yeniden mount et
mount -o remount,rw /sysroot

# chroot ile asıl sisteme geç
chroot /sysroot

# Root şifresini değiştir
passwd root
# Yeni şifre: (girin)
# Şifreyi tekrar girin: (girin)

# SELinux aktifse bu dosyayı oluşturmak şart
touch /.autorelabel

# Çıkış
exit
exit
# Sistem yeniden başlayacak ve SELinux relabeling yapacak
# Bu işlem biraz sürebilir, beklemeniz normal

SELinux relabeling işlemi büyük sistemlerde 10-15 dakika sürebilir. Bu süreyi kısaltmak için SELinux’u geçici olarak permissive moda almak mümkündür, ancak üretim sistemlerinde bunu tavsiye etmiyorum.

Senaryo 5: Kernel Panik Durumlarında Eski Kernel ile Boot

Yeni bir kernel güncellemesinin ardından sistem açılmıyorsa, GRUB menüsünden eski kerneli seçebilirsiniz.

# GRUB menüsünde "Advanced options for Rocky Linux" seçin
# Oradan eski kernel sürümünü seçin

# Sisteme girdikten sonra sorunlu kerneli kaldırmak için
rpm -qa | grep kernel
# Çıktı örneği:
# kernel-5.14.0-362.8.1.el9_3.x86_64
# kernel-5.14.0-370.17.1.el9_4.x86_64

# Sorunlu kerneli kaldır
dnf remove kernel-5.14.0-370.17.1.el9_4.x86_64

# Varsayılan kerneli ayarla
grub2-set-default 0
grub2-mkconfig -o /boot/grub2/grub.cfg

Kernel sorunlarını araştırmak için rescue modunda kernel mesajlarına bakın:

# Kernel boot mesajlarını görüntüle
dmesg | grep -i error
dmesg | grep -i panic
dmesg | grep -i fail

# Son boot'un günlüklerini kontrol et
journalctl -b -1 --priority=err

# Kernel panik detayları için
journalctl -b -1 | grep -A 20 "kernel panic"

Senaryo 6: LVM Sorunları

Logical Volume Manager kullanan sistemlerde volume group aktif olmayabilir ya da logical volume bozulmuş olabilir.

# Mevcut fiziksel volume'leri tara
pvscan

# Volume group'ları bul ve aktif et
vgscan --mknodes
vgchange -ay

# Logical volume'leri listele
lvs
lvdisplay

# Bozuk LV'yi kontrol et
fsck /dev/mapper/rl-root

# LVM metadata'sını geri yükle (yedekten)
vgcfgrestore -l VolGroup00
vgcfgrestore -f /etc/lvm/backup/VolGroup00 VolGroup00

# Snapshot ile kurtarma
# Eğer önceden snapshot alındıysa
lvconvert --merge /dev/VolGroup00/root_snapshot

Senaryo 7: SELinux Kaynaklı Boot Sorunları

SELinux politikası değişikliği ya da yanlış bir semanage komutu sistemi kilitleyebilir.

# GRUB'da kernel parametrelerine ekle (geçici çözüm)
selinux=0

# Ya da permissive mod için
enforcing=0

# Sisteme girildikten sonra SELinux durumunu kontrol et
sestatus
getenforce

# SELinux log'larını incele
ausearch -m AVC -ts recent
sealert -a /var/log/audit/audit.log

# SELinux policy hatasını giderdikten sonra relabeling başlat
restorecon -Rv /
# Ya da
touch /.autorelabel
reboot

Sistem Kurtarma Sonrası Yapılacaklar

Sistemi kurtardıktan sonra kontrol listesi hazırlamak iyi bir alışkanlıktır:

  • Boot testini doğrula: Sistemi yeniden başlatın ve normal açılıp açılmadığını gözlemleyin
  • Servis durumlarını kontrol edin: systemctl --failed ile başarısız servisleri listeleyin
  • Log analizini yapın: journalctl -b 0 --priority=warning ile uyarıları inceleyin
  • Dosya sistemi sağlığını doğrulayın: xfs_repair -n ya da tune2fs -l ile durum kontrolü yapın
  • Yedekleme sistemini gözden geçirin: Bu kriz neden yaşandı ve bir dahaki sefere nasıl önlenebilir?
# Sistem sağlık kontrolü için hızlı komutlar
systemctl --failed
df -h
free -m
journalctl -b 0 --priority=warning --no-pager | tail -50
dmesg | grep -E "(error|fail|warn)" | tail -20

Önleyici Tedbirler

En iyi kurtarma operasyonu, hiç yapılmayan kurtarma operasyonudur. Bu düşünceyle şu pratik önlemleri almak hayat kurtarır:

  • Düzenli snapshot alın: Özellikle büyük güncellemeler ya da konfigürasyon değişiklikleri öncesi
  • fstab değişikliklerini test edin: mount -a komutu ile her değişikliği anında test edin
  • GRUB konfigürasyonunu yedekleyin: grub2-mkconfig öncesi mevcut cfg’yi kopyalayın
  • Kernel güncellemelerini aşamalı yapın: Tek seferde tüm sistemleri değil, önce bir test sunucusunu güncelleyin
  • Rescue USB hazır bulundurun: Güncel Rocky Linux ISO’sundan önyüklenebilir bir USB daima erişilebilir olsun
  • Root şifresini güvenli saklayın: Şifre manager ya da güvenli bir fiziksel kopya
  • SELinux değişikliklerini kaydedin: Her semanage ve setsebool komutunu dokümante edin
# fstab değişikliği öncesi güvenli test prosedürü
cp /etc/fstab /etc/fstab.$(date +%Y%m%d)
echo "UUID=xxxx /newmount xfs defaults 0 2" >> /etc/fstab
mount -a && echo "Basarili" || echo "HATA - fstab kontrol edin"

Rescue Modunu Pratik Olarak Test Etmek

Kriz anında rescue modunu ilk kez kullanmak streslidir. Bu nedenle sakin bir ortamda pratik yapmanızı şiddetle tavsiye ediyorum. Bir sanal makine üzerinde kasıtlı olarak fstab’ı bozun, GRUB’u silin ya da root şifresini değiştirin ve kurtarma işlemini prova edin.

# Test VM'de kasıtlı fstab bozma (sadece test ortamında!)
echo "/dev/sdz1 /test xfs defaults 0 0" >> /etc/fstab
reboot
# Şimdi sistemi kurtarma pratiği yapabilirsiniz

Bu tip tatbikatlar, gerçek bir kriz anında sakin kalmanızı ve doğru adımları hızlıca uygulamanızı sağlar. Birçok deneyimli sistem yöneticisi, yeni bir sunucu kurulumundan sonra rescue modunu test etmeyi standart bir prosedür olarak benimser.

Sonuç

Rocky Linux’un rescue modu, doğru kullanıldığında son derece güçlü bir kurtarma aracıdır. Burada ele aldığımız senaryoların büyük çoğunluğu, yani bozuk fstab, GRUB sorunları, unutulan şifreler ve dosya sistemi hataları, sistem yöneticilerinin günlük hayatında karşılaştığı gerçek problemlerdir.

Önemli olan, panik yapmadan sistematik bir yaklaşım benimsemektir. Önce sorunu tanımlayın, sonra uygun kurtarma yöntemini seçin, değişikliklerinizi uygulayın ve sistemi test ederek çıkın. Her kurtarma operasyonundan sonra bir post-mortem belgesi hazırlamak, aynı sorunun tekrar yaşanmaması için alınabilecek önlemleri belirlemenize yardımcı olur.

Son olarak, en iyi sistem yöneticisi krizleri çözen değil, krizlerin yaşanmasını önleyen kişidir. Düzenli yedekleme, kapsamlı monitoring ve değişiklik öncesi test prosedürleri, bu yazıda bahsedilen senaryoların büyük bölümünün yaşanmasını baştan engeller.

Yorum yapın