Kernel guncellemesi sonrasi acilmayan VPS nasil kurtarilir

Kernel güncellemesi sonrası VPS açılmadığında yapılacak ilk işlemler

Kernel güncellemesinin ardından açılmayan bir VPS genellikle birkaç dakika içinde kurtarılabilir; çünkü güncelleme işlemi, bir önceki gün çalışan kernel sürümünü silmez. Ubuntu, yeni kerneli eskisinin yanına kurar ve yalnızca GRUB önyükleyicisinin varsayılan olarak hangi girişi başlatacağını değiştirir. Bu nedenle ilk adım bir onarım işlemi değildir. Önyükleme menüsünden önceki kerneli seçin, oturum açma ekranına geri dönün ve ardından çalışan sistem üzerinden tanı koyun.

Sunucuda bu sorunu gidermek, dizüstü bilgisayarda yapmaktan farklıdır; çünkü fiziksel bir klavye bağlı değildir ve ekran kernel paniğini göstermez. Makine sshd servisinin başladığı noktaya hiçbir zaman ulaşamadığı için SSH bağlantısı da yanıt vermeyecektir. Aşağıdaki tüm işlemler servis sağlayıcınızın sağladığı konsol üzerinden gerçekleştirilir.

Herhangi bir değişiklik yapmadan önce kendi konsolunuzu okuyun. Ekranda görünen metin, hangi hata sınıfında olduğunuzu belirler; "açılmayan" iki farklı sunucu, birbirine zıt çözüm yöntemleri gerektirebilir.

SSH erişimi kesildiğinde konsola nasıl ulaşırım?

Servis sağlayıcınızın kontrol paneline giriş yapın ve bir konsol seçeneği arayın. Yaygın olarak kullanılan isimler VNC console, web console, noVNC ve serial console şeklindedir. Her ikisi de mevcutsa serial console tercih edilmelidir; çünkü bu seçenek metinleri kopyalamanıza ve kaydırmanıza olanak tanırken, VNC görünümü yalnızca ekranın bir görüntüsünü sunar. Bu kontrolü makine henüz sağlıklı çalışıyorken yapın ve açıldığından emin olun. Bir kesinti anında bu aracı aramak, ihtiyaç duyduğunuz sükuneti kaybetmenize neden olur. Bu kontrol, güvenlik duvarı kuralları ve SSH anahtarları ile birlikte yeni bir VPS üzerindeki ilk on dakika içerisinde yapılmalıdır.

Çoğu panel ayrıca bir kurtarma modu (rescue mode) veya kurtarma imajı sunar. Bu mod, sağlayıcının ağından küçük bir sistem başlatır ve diskinizi ek bir aygıt olarak bağlar; böylece diskinizdeki hiçbir şey çalıştırılmaz. Kurtarma modu, GRUB'ın kendisi bozulduğunda başvurulacak yedek yöntemdir ve aynı zamanda kurtarmaktan vazgeçtiğiniz bir sunucudan verileri nasıl kopyalayacağınızın yoludur.

Oturum açamadığınız bir makinede sudo reboot komutunu çalıştıramayacağınız için, önyükleme menüsüne ulaşmak adına genellikle panel üzerinden bir hard reset (donanımsal sıfırlama) yapmanız gerekir. Hard reset, gücü kesmekle aynı işlemdir. Dosya sistemleri düzgün kapatılmadığı için, bir sonraki açılışta bir dosya sistemi denetimi (filesystem check) gerçekleşmesini beklemelisiniz.

GRUB menüsünden nasıl eski bir çekirdek seçerim?

Reset tuşuna bastığınız andan itibaren konsolu izleyin. İlk saniyeler içinde Esc tuşuna art arda basın veya legacy BIOS modunda açılan bir makinede Shift tuşunu basılı tutun. Bu süre oldukça kısadır ve konsol görüntüleyicinin bağlanması genellikle bir saniye sürer, bu yüzden erken basmaya başlayın ve basmaya devam edin.

Menü göründüğünde "Advanced options for Ubuntu" seçeneğini seçin. Bu alt menü, her biri için bir kurtarma modu girişiyle birlikte, en yenisi en üstte olacak şekilde yüklü tüm çekirdekleri listeler. En yeni çekirdeğin bir altındaki ikinci normal girişi seçin ve Enter tuşuna basın. Kurtarma modu farklı bir işlemdir: minimal bir tek kullanıcılı sisteme açılır ve servislerinizi tekrar çevrimiçi hale getirmek için değil, onarım çalışmaları içindir.

Eski çekirdek açılırsa, tekrar çalışan bir sunucuya sahip olursunuz. Hangi sürümde olduğunuzu doğrulayın ve numaraları not edin.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

dpkg çıktısı, yüklü çekirdeklerinizin listesidir. Eğer sadece tek bir satır içeriyorsa, hiçbir yedekleme seçeneğiniz yoktur ve düzeltilmesi gereken ilk şey budur.

GRUB menüsü hiç görünmüyor. Şimdi ne yapmalı?

Bulut imajları, menüyü gizleyen bir yapılandırma ile gelir. Ubuntu imajları genellikle /etc/default/grub.d/ altındaki bir dosyada zaman aşımını 0 olarak ayarlar; bu nedenle en yeni çekirdek hemen başlar ve basılacak bir şey kalmaz.

Bunun tam tersi bir durum da mevcuttur; menü ekranda bekler ve sistem donmuş gibi görünür. GRUB başarısız bir önyüklemeyi kaydeder ve bir sonraki başlatmada, birisi bir tuşa basana kadar menüyü açık tutabilir. Klavyesi olmayan bir makinede bu bekleme süresi asla bitmez. Konsolunuzda bir menü görünüyor ve hiçbir şey ilerlemiyorsa, olan budur. Bir girdi seçin ve devam edin.

Her iki durumu da makine sağlıklı durumdayken düzeltin. /etc/default/grub dosyasını düzenleyin:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Ardından değişikliği uygulayın ve düzenlemenizin kalıcı olduğunu doğrulayın; çünkü /etc/default/grub.d/ içindeki dosyalar /etc/default/grub sonrasında okunur ve ayarlarınızı geçersiz kılabilir.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial", menüyü grafik konsola ve seri porta gönderir; böylece panelinizin size sunduğu görüntüleyicide görünür hale gelir. console= çekirdek argümanları, takip eden önyükleme mesajları için de aynı işlemi yapar. Önyükleme başına on saniyelik bir gecikme, gece saat 02:00'de erişebileceğiniz bir menü için ödenmesi gereken düşük bir bedeldir.

Hangi hata sınıfıyla karşı karşıyayım?

Konsol akışı durmadan önceki son yirmi satırı okuyun. Bir çekirdek (kernel) güncellemesinden sonra yaşananların çoğu dört ana kalıba girer.

GRUB kendi dosyalarını bulamıyor. Bir grub rescue> istemiyle veya mevcut olmayan bir bölüm ya da dosya hakkında bir hata ile karşılaşırsınız ve hiçbir çekirdek mesajı görüntülenmez. Çekirdek henüz devreye girmemiştir. Bu durum, çekirdek paketinden ziyade disk veya bölüm değişikliğinden ya da yanlış aygıta yazılmış bir önyükleyiciden (bootloader) kaynaklanır.

Çekirdek başlıyor ancak kök dizini (root) bağlayamıyor. Çekirdek mesajları akar, ardından (initramfs) istemine sahip bir busybox kabuğuna düşersiniz veya önyükleme, kök dosya sistemi bağlanamadığı için bir panik hatasıyla sonlanır. Çekirdek yüklenmiştir. Gerçek kök dosya sisteminizi bulan ve bağlayan küçük geçici kök dizin olan initramfs, diski bulamamıştır. Ubuntu üzerinde bu kabuktan önce genellikle kök aygıtın beklenmesinden vazgeçildiğine dair bir mesaj gelir ve aranan UUID belirtilir. Bu UUID değerini kopyalayın ve daha sonra blkid çıktısı ile karşılaştırın.

Mantıksal bir birim (logical volume) asla görünmüyor. Bu, tek bir özel nedeni olan bir önceki hata sınıfıdır. (initramfs) isteminde ls /dev/mapper komutunu çalıştırın. Eğer tek girdi control ise, hiçbir LVM (mantıksal birim yöneticisi) birimi etkinleştirilmemiş demektir; bu nedenle kök aygıt henüz mevcut değildir. Birim gruplarını manuel olarak ayağa kaldırın:

lvm vgchange -ay
ls /dev/mapper
exit

exit komutu kontrolü, bağlama işlemini tekrar deneyen initramfs betiğine geri verir. Eğer sistem bu şekilde açılırsa, yeni initramfs LVM bileşenlerini içermiyor demektir; bu durumda çözüm, çekirdeğe dokunmak yerine ilgili imajı yeniden oluşturmaktır.

Linux'tan hiçbir çıktı gelmiyor. Konsol donanım yazılımı (firmware) metnini, bir UEFI (birleşik genişletilebilir donanım yazılımı arayüzü) kabuğunu, çekirdek çıktısı olmayan boş bir ekranı veya bir yeniden başlatma döngüsünü gösterir. Hata, Linux çalışmadan önce gerçekleşmektedir. Sisteme tekrar eriştiğinizde sunucunuzun hangi modda çalıştığını kontrol edin; çünkü birçok VPS örneği eski BIOS modunda önyükleme yapar ve EFI yoluna hiç uğramaz:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Güncelleme sırasında /boot/efi dizininin bağlı olmaması, UEFI makinelerde yaygın bir nedendir; çünkü EFI sistem bölümünü yöneten paketler, bu durumda verileri normal ve boş bir dizine yazmış olur. Donanım yazılımı, ilgili girdi disk üzerindekiyle eşleşmeyi bırakana kadar eski önyükleme girdisini başlatmaya devam eder.

Bir diğer durum ise aslında bir önyükleme hatası değildir. Eğer sistemin acil durum modunda olduğunu belirten bir kök kabuğuna ulaşırsanız, çekirdek önyüklenmiş ancak kullanıcı alanı (userspace) durmuş demektir. Bu genellikle /etc/fstab dosyasındaki hatalı bir satırdan veya kontrolü başarısız olan bir dosya sisteminden kaynaklanır. Bu kabukta journalctl -xb komutunu çalıştırın ve başarısız olan birimin adını okuyun.

Çekirdek paketi mi bozuk, yoksa initramfs mi?

Bu iki durum konsoldan bakıldığında aynı görünür ancak farklı onarım yöntemleri gerektirir. Eski çekirdekle sistemi başlatın ve ardından dosyaları karşılaştırın.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Yüklü her sürüm için bir adet vmlinuz- ve buna karşılık gelen bir adet initrd.img- dosyasına sahip olmanız gerekir; her ikisi de makul bir boyutta olmalıdır. Eksik bir initrd dosyası veya diğerlerine göre çok daha küçük bir dosya, initramfs oluşturma işleminin başarısız olduğu anlamına gelir. Bunun yaygın nedeni /boot dizininin dolu olmasıdır ve kanıtlar paket günlüklerinde yer alır:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log dosyası ayrıca son çalıştırmalarda hangi paketlerin ne zaman yüklendiğini tam olarak listeler; bu da neyin değiştiği konusundaki tüm tartışmaları sonlandırır.

Eğer /boot doluysa önce diskte yer açın, ardından ihtiyacınız olan sürüm için imajı yeniden oluşturun ve menüyü güncelleyin. Aşağıdaki yer tutucu gerçek bir sürüm olmadığından, sürüm dizgisini kendi ls çıktınızdan alın:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Son olarak ls komutu kontrolü sağlar. Normal boyutta bir dosya, imajın artık orada olduğu anlamına gelir. Eğer çekirdek imajının kendisi hasarlıysa veya dpkg -l paketi ii dışında bir durumda gösteriyorsa, paketi yeniden yükleyin:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Hiçbir çekirdek önyüklenmediğinde kurtarma modundan onarım

Menüdeki tüm girdiler başarısız olursa, sağlayıcının kurtarma imajını önyükleyin ve diski dışarıdan onarın. Diskiniz bağlanmamış bir aygıt olarak görünecektir; bu sayede üzerinde çalışan hiçbir süreç yoktur ve müdahalenizi engelleyecek bir durum oluşmaz.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Yeni bir çekirdeği bir sonraki açılışı riske atmadan test etme

GRUB, bir girdiyi tek seferlik başlatıp ardından seçtiğiniz varsayılan ayara geri dönebilir. Varsayılan ayarı güvendiğiniz bir çekirdeğe yönlendirin, ardından yenisini yalnızca bir açılış için çalıştırın. Eğer başarısız olursa, panel üzerinden yapacağınız bir donanımsal sıfırlama (hard reset), konsol zamanlamasıyla uğraşmanıza gerek kalmadan sizi çalışan çekirdeğe döndürür.

GRUB_DEFAULT=saved değerini /etc/default/grub içinde ayarlayın, sudo update-grub komutunu çalıştırın ve ardından girdi başlıklarını listeleyerek birini tam olarak adlandırın:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list, seçtiğiniz başlığı saved_entry olarak yazdırmalıdır. Bu çıktı, mekanizmanın çalıştığının kanıtıdır; çünkü kaydetme işlemi yazılabilir bir /boot/grub/grubenv gerektirir ve bazı düzenlerde bu işlem sessizce başarısız olabilir. 0 numaralı girdi menünün en üstündedir ve en yeni çekirdeği temsil eder. Çekirdek her yüklendiğinde veya kaldırıldığında numaralar değiştiği için, burada başlıkları kullanmak numaralardan daha güvenlidir.

Headless bir sunucuda autoremove neden risklidir

APT, kendi başına kaldırmaması gereken çekirdek paketlerinin bir listesini tutar. Kendi listenizi şu komutla inceleyebilirsiniz:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Bu dosya, çekirdek paketleri her değiştiğinde yeniden oluşturulur ve çalışan çekirdek ile en güncel olanları koruma altına alır. Buradaki tuzak zamanlamadır. Yeni bir çekirdeğe geçiş yaptıktan hemen sonra sudo apt autoremove --purge komutunu çalıştırırsanız, korumalı liste güncellenmiş olur; bu durumda güvendiğiniz eski çekirdek artık koruma altında değildir. Klavyesi olan bir makinede bu sadece bir zahmettir. Headless bir sunucuda ise bu durum, bir menü öğesi seçmek ile diskinizi bir kurtarma imajından mount etmek arasındaki farktır.

Alt sınır olarak iki çekirdek tutun, /boot üzerinde yeterli alan varsa bu sayıyı üçte bırakın. Eski çekirdekleri, uname -r komutunu kontrol ettikten sonra isimlerini belirterek kaldırın; böylece o an çalışan çekirdeği asla silmemiş olursunuz:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

İşlemden sonra son komutu tekrar çalıştırın. Sayının üçten ikiye düşmesi bir temizliktir. Bire düşmesi ise bir sonraki yeniden başlatmada yaşanacak bir kesintinin habercisidir.

Yükseltme öncesinde snapshot alın

apt upgrade öncesinde alınan bir snapshot, herhangi bir sistemi önyüklemeye gerek duymayan tek kurtarma yoludur. Geri yükleme işlemi diski eski çekirdeğin varsayılan olduğu duruma döndürür; böylece konsol zaten açıkken yükseltmeyi tekrar deneyebilirsiniz. Çalışan bir makinenin snapshot'ları "crash consistent" yani çökme tutarlıdır; bu, diskin gücü kesilmiş gibi yakalandığı anlamına gelir. Bu nedenle, servis sağlayıcınız çevrimdışı snapshot desteği sunuyorsa önce sunucuyu kapatın. Snapshot bir yedekleme değildir; genellikle kopyaladığı birimle aynı altyapıda barındırılır. VPS snapshot'ları ile gerçek yedeklemeler arasındaki farkı anlamak, hata çekirdek seviyesinden daha büyük olduğunda sizi neyin kurtaracağını belirler.

Bu durum, çekirdeğin, initramfs araçlarının, önyükleyicinin ve GRUB yapılandırmasının tek bir işlemde değiştiği sürüm yükseltmelerinde kritik öneme sahiptir. Snapshot'ı, Ubuntu 24.04'ten 26.04'e yükseltme işlemine başlamadan hemen önce alın; bir gece önceden almayın. Böylece geri yükleme noktası, değiştirmek üzere olduğunuz makineyle tam olarak eşleşir.

unattended-upgrades paketinin çekirdek paketlerini işleme biçimi

Ubuntu üzerindeki unattended-upgrades, güvenlik güncellemelerini onay almadan yükler; çekirdek paketleri de diğer tüm paketler gibi güvenlik havuzu üzerinden gelir. Bu durum iki sonucu beraberinde getirir.

Birincisi, yeni çekirdek yüklenir ancak çalışır durumda değildir. Bir çekirdek yalnızca sistem açılışında devreye girer. /var/run/reboot-required dosyası oluşur ve /var/run/reboot-required.pkgs dosyası yeniden başlatmayı neyin tetiklediğini belirtir, ancak /etc/apt/apt.conf.d/50unattended-upgrades içerisinde Unattended-Upgrade::Automatic-Reboot ayarını etkinleştirmediğiniz sürece hiçbir şey otomatik olarak yeniden başlamaz.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

İkincisi, bu zaman farkı sorunun kaynağını gizler. Bir sunucu Mart ayında bir çekirdek yükleyip Haziran ayında tamamen alakasız bir nedenle yeniden başlatılabilir ve ardından açılmayabilir. Açılışı bozan değişiklik üç ay öncesine ait olduğundan, o gün yaptığınız hiçbir işlem durumu açıklamaz. Şu an başarısızlığa neden olan çekirdeğin yüklendiği süreci /var/log/apt/history.log dosyasında bulabilirsiniz.

Sistemi, konsol penceresi halihazırda açıkken ve kendi belirlediğiniz bir günde kasten yeniden başlatın. Bu basit alışkanlık, gizemli bir kesintiyi iki dakikalık bir menü seçimine dönüştürür. Otomasyonun sürprizlerini yaşamak istemiyorsanız, otomatik yüklemeleri açık, otomatik yeniden başlatmaları ise kapalı tutun; tam ayarlar için Ubuntu üzerinde unattended-upgrades yapılandırması rehberine göz atın. Çekirdek paketlerini sudo apt-mark hold linux-image-generic ile tutmak (hold), güncellemeleri tamamen durdurur ancak aynı zamanda çekirdek güvenlik yamalarını da engeller; bu nedenle bunu bir güvenlik önlemi olarak değil, bilinçli bir tercih olarak değerlendirin.

FAQ

Klavyesi olmayan bir VPS üzerinde eski bir çekirdek (kernel) ile nasıl önyükleme yaparım?

Sağlayıcının konsolunu (VNC veya seri) açın ve kontrol panelinden bir donanımsal sıfırlama (hard reset) tetikleyin; çünkü temiz bir yeniden başlatma için sisteme giriş yapamazsınız. Makine yeniden başlarken, GRUB menüsünü yakalamak için art arda Esc tuşuna basın veya eski tip BIOS önyüklemesinde Shift tuşunu basılı tutun. "Advanced options for Ubuntu" seçeneğine girin ve en yeni çekirdeğin bir altındaki girişi seçin. Giriş istemine ulaştığınızda, hangi çekirdekte olduğunuzu doğrulamak için uname -r komutunu, başka nelerin yüklü olduğunu görmek için ise dpkg -l 'linux-image-*' komutunu çalıştırın. Tanılama işlemlerini ancak sistem tekrar çalışır hale geldikten sonra yapın.

VPS üzerinde neden hiçbir GRUB menüsü görünmüyor?

Bulut imajları genellikle /etc/default/grub.d/ altındaki bir dosyada GRUB zaman aşımını 0 olarak ayarlar, bu yüzden en yeni çekirdek hiçbir tuşa basmanıza fırsat kalmadan başlar. /etc/default/grub dosyasında GRUB_TIMEOUT=10 ve GRUB_TIMEOUT_STYLE=menu değerlerini ayarlayın, menünün seri konsola da ulaşması için GRUB_TERMINAL="console serial" ekleyin ve ardından sudo update-grub komutunu çalıştırın. grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ ile doğrulama yapın, çünkü bu dizindeki dosyalar ana dosyadan sonra okunur ve yaptığınız düzenlemeyi geçersiz kılabilir.

/boot dizininde yer açmak için eski çekirdekleri kaldırmalı mıyım?

En eskileri kaldırın ve en az iki tanesini tutun. Tamamen dolu bir /boot kendi başına bir hata modudur; çünkü bu durumda initramfs oluşturma işlemi başarısız olur ve elinizde çalışan bir imajı olmayan bir çekirdek kalır. uname -r dosyasını kontrol ettikten sonra tam paket adıyla temizleme (purge) yapın, böylece çalışan çekirdek asla silinme adayı olmaz. Başsız (headless) bir makinede genel bir sudo apt autoremove --purge komutundan kaçının; çünkü korumalı çekirdek listesi her çekirdek değişikliğinde yeniden oluşturulur ve yanlış zamanda yapılan bir işlem, sizi tek bir çekirdek ile menüde yedek giriş olmadan bırakabilir.

unattended-upgrades önyüklememi bozabilir mi?

Daha sonra önyüklenemeyen bir çekirdek yükleyebilir, ancak /etc/apt/apt.conf.d/50unattended-upgrades dosyasında Unattended-Upgrade::Automatic-Reboot değeri true olarak ayarlanmadığı sürece makineyi yeniden başlatmaz. Genel senaryo gecikmeli bir hatadır: çekirdek otomatik bir çalışma sırasında yüklenir, /var/run/reboot-required görünür ve sorun ancak haftalar sonraki bir sonraki yeniden başlatmanızda ortaya çıkar. Konsol halihazırda açıkken bilinçli bir şekilde yeniden başlatma yapın ve önyüklediğiniz çekirdeğin hangi çalışma sırasında yüklendiğini bulmak için /var/log/apt/history.log dosyasını okuyun.