Kernel güncellemesi sonrası açılmayan VPS nasıl kurtarılır

Kernel güncellemesi sonrası VPS açılmadığında ilk ne yapılmalı

Kernel güncellemesinden sonra açılmayan bir VPS, genellikle birkaç dakika içinde kurtarılabilir; çünkü güncelleme, dün çalışan kerneli silmemiştir. Ubuntu, yeni kerneli eskisinin yanına kurar ve yalnızca GRUB'ın varsayılan olarak hangi girdiyi 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 bir 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ştirilmelidir.

Herhangi bir değişiklik yapmadan önce kendi konsolunuzdaki çıktıları 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öntemlerine ihtiyaç duyabilir.

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

Servis sağlayıcınızın kontrol panelini açın ve konsol seçeneğini 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 denetimi makine henüz sağlıklı çalışıyorken yapın ve açıldığından emin olun. Bir kesinti anında bu özelliği aramak, ihtiyaç duyduğunuz sükuneti kaybetmenize neden olur. Bu kontrol, yeni bir VPS üzerindeki ilk on dakika içerisinde, güvenlik duvarı kuralları ve SSH anahtarlarıyla birlikte 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ışmaz. Kurtarma modu, GRUB'ın kendisinin bozulduğu durumlar için bir yedek plandır ve aynı zamanda kurtarmaktan vazgeçtiğiniz bir sunucudan verileri kopyalamanı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 donanımsal sıfırlama (hard reset) yapmanız gerekir. Donanımsal sıfırlama, elektriği kesmekle aynı işlemdir. Dosya sistemleri düzgün kapatılmamış sayılacağından, bir sonraki açılışta dosya sistemi denetimi yapılmasını beklemelisiniz.

GRUB menüsünden eski bir kernel sürümü nasıl seçilir?

Sistemi yeniden başlattığı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. Zaman aralığı kısadır ve konsol görüntüleyicinin bağlanması genellikle bir saniye sürer; bu nedenle tuşa basmaya erken başlayın ve basmaya devam edin.

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

Eski kernel ile sistem açılırsa, çalışan bir sunucuya tekrar sahipsiniz demektir. Hangi sürümde olduğunuzu doğrulayın ve sürüm numaralarını not edin.

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

dpkg çıktısı, yüklü kernel sürümlerinizin listesidir. Eğer listede yalnızca tek bir satır varsa, hiçbir yedek sürümünüz yok demektir; düzeltmeniz 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ı süresini 0 olarak ayarlar; bu nedenle en yeni çekirdek hemen başlar ve basılacak bir tuş 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ükleme kaydederse, bir sonraki başlatmada birisi bir tuşa basana kadar menüyü açık tutabilir. Klavyesi olmayan bir makinede bu bekleme süresi asla sona ermez. Konsolunuzda bir menü görünüyor ve hiçbir ilerleme olmuyorsa, yaşanan durum budur. Bir girdi seçin ve devam edin.

Her iki durumu da makine sağlıklı çalışırken 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 ayarları 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 yaptığınız değişiklikleri geçersiz kılabilir.

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

GRUB_TERMINAL="console serial", menüyü hem grafik konsola hem de seri porta gönderir; böylece panelinizin size sunduğu görüntüleyicide menü 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. Çekirdek güncellemesinden sonra yaşananların çoğu dört ana kalıba girer.

GRUB kendi dosyalarını bulamıyor. grub rescue> istemiyle karşılaşırsınız veya mevcut olmayan bir bölüm ya da dosya hakkında hata alırsınız; hiçbir çekirdek mesajı görünmez. Ç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ılan bir önyükleyiciden 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 sisteminin bağlanamadığına dair bir panik hatasıyla sonlanır. Çekirdek yüklenmiştir. Gerçek kök dosya sistemini bulup 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 ve aranan UUID bilgisi yer alır. Bu UUID değerini kopyalayın ve daha sonra blkid çıktısı ile karşılaştırın.

Mantıksal bir birim (logical volume) hiç 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ştir; dolayısıyla 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 kontrolü tekrar initramfs betiğine devreder ve bağlama işlemini yeniden dener. Eğer sistem bu şekilde açılırsa, yeni initramfs içinde LVM parçaları eksik demektir; bu durumda çözüm, çekirdeğe dokunmak yerine ilgili imajı yeniden oluşturmaktır.

Linux'tan hiçbir çıktı gelmiyor. Konsol; ürün yazılımı (firmware) metnini, bir UEFI (birleşik genişletilebilir ürün 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ışmaya başlamadan önce gerçekleşmektedir. Sisteme tekrar erişim sağladığınızda sunucunuzun hangi modu kullandığını kontrol edin; çünkü birçok VPS örneği legacy BIOS modunda açılır 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 sıradan ve boş bir dizine yazma işlemi gerçekleştirir. Ürün yazılımı, önyükleme girdisi disktekiyle eşleşmeyi bırakana kadar eski girdiyi 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 açılmış ancak kullanıcı alanı (userspace) durmuştur. Bu genellikle /etc/fstab dosyasındaki hatalı bir satır veya kontrolü başarısız olan bir dosya sistemi anlamına gelir. O kabukta journalctl -xb komutunu çalıştırın ve başarısız olan birimin adını okuyun.

Kernel 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 kerneli 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 ikisinin de makul bir boyutta olması beklenir. 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; 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 ayrıca son çalıştırmalarda hangi paketlerin ne zaman yüklendiğini tam olarak listeler; bu da neyin değiştiğine dair 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ü yenileyin. 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 ile kontrolü gerçekleştirin. Normal boyutta bir dosya, imajın artık orada olduğu anlamına gelir. Eğer kernel 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

Çekirdek önyüklemesi başarısız olduğunda kurtarma modundan onarım

Menüdeki hiçbir girdi çalışmıyorsa, sağlayıcının kurtarma imajını önyükleyin ve diski dışarıdan onarın. Diskiniz bağlanmamış (unmounted) bir aygıt olarak görünecektir; bu sayede disk ü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

Bir sonraki önyüklemeyi riske atmadan yeni bir çekirdeği test etme

GRUB, bir girdiyi tek seferlik başlatıp ardından seçtiğiniz varsayılana geri dönebilir. Varsayılan ayarı güvendiğiniz bir çekirdeğe yönlendirin, ardından yenisini yalnızca bir önyükleme için çalıştırın. Eğer başarısız olursa, panel üzerinden yapılacak bir donanımsal sıfırlama, 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 bir girdiyi tam olarak adlandırabilmek için girdi başlıklarını listeleyin:

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 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 okuyabilirsiniz:

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. sudo apt autoremove --purge komutunu yeni bir çekirdeğe geçiş yaptıktan hemen sonra çalıştırırsanız, korunan liste güncellenmiş olur; bu durumda güvendiğiniz eski çekirdek artık korunmaz. 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 için yeterli alan olduğunda ise üç çekirdek bulundurun. Eski çekirdekleri, uname -r komutunu kontrol ettikten sonra isimleriyle kaldırın; böylece o an çalışan çekirdeği asla silmezsiniz:

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

Son komutu işlemden sonra 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 anlık görüntü (snapshot) alın

apt upgrade öncesinde alınan bir anlık görüntü, herhangi bir sistemi başlatmaya gerek duymadan kurtarma sağlayan tek yoldur. Geri yükleme işlemi diski, eski çekirdeğin varsayılan olduğu duruma döndürür; böylece konsol halihazırda açıkken yükseltmeyi yeniden deneyebilirsiniz. Çalışan bir makinenin anlık görüntüleri "crash consistent" (çökme tutarlı) yapıdadır; bu, diskin gücü aniden kesilmiş gibi kaydedildiği anlamına gelir. Bu nedenle, servis sağlayıcınız çevrimdışı anlık görüntü almayı destekliyorsa önce sunucuyu kapatın. Anlık görüntü bir yedekleme değildir; çünkü genellikle kopyaladığı birimle aynı altyapıda barındırılır. VPS anlık görüntüleri 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 (bootloader) ve GRUB yapılandırmasının tek bir seferde değiştiği sürüm yükseltmelerinde kritik öneme sahiptir. Anlık görüntüyü, 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ı, üzerinde değişiklik yapacağınız makineyle tam olarak eşleşir. Eğer söz konusu yükseltme sunucunuzda henüz sunulmadıysa, bunun nedeni bozuk bir kurulum değil, zamanlamadır; çünkü LTS'den LTS'ye geçişler yalnızca ilk ara sürüm olan 26.04.1 ile kullanıma açılır.

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ışmaz. 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 talep ettiğ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ıldığında açılmayabilir. Açılışı bozan değişiklik üç ay öncesine aittir, bu nedenle o gün yaptığınız hiçbir işlem durumu açıklamaz. Şu an başarısızlığa neden olan çekirdeği yükleyen işlemi /var/log/apt/history.log dosyasında bulabilirsiniz.

Yeniden başlatma işlemini, konsol penceresi halihazırda açıkken ve kendi belirlediğiniz bir günde kasten yapın. Bu tek alışkanlık, gizemli bir kesintiyi iki dakikalık bir menü seçimine dönüştürür. Otomasyonu sürprizler olmadan kullanmak istiyorsanız, otomatik yüklemeleri açık, otomatik yeniden başlatmaları kapalı tutun ve 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 bu işlem aynı zamanda çekirdek güvenlik yamalarını da engeller. Bu nedenle bunu bir güvenlik önlemi olarak değil, almayı kabul ettiğiniz bir takas olarak değerlendirin.

FAQ

Klavyesi olmayan bir VPS üzerinde eski bir kernel ile nasıl başlatma yapabilirim?

Sağlayıcının konsolunu (VNC veya seri) açın ve kontrol panelinden bir hard reset tetikleyin; çünkü temiz bir yeniden başlatma için 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 kernel'in bir altındaki girdiyi seçin. Giriş ekranına ulaştığınızda, hangi kernel üzerinde olduğunuzu doğrulamak için uname -r komutunu, yüklü diğer paketleri 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 nedenle en yeni kernel herhangi 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 kernel'leri 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 kernel kalır. Çalışan kernel'in hedef olmadığından emin olmak için uname -r dosyasını kontrol ettikten sonra tam paket adıyla purge işlemini gerçekleştirin. Başsız (headless) bir makinede genel bir sudo apt autoremove --purge komutundan kaçının; çünkü korumalı kernel listesi her kernel değişikliğinde yeniden oluşturulur ve yanlış zamanda yapılan bir işlem, sizi tek bir kernel ile menüde yedek girdi olmadan bırakabilir.

unattended-upgrades önyüklememi bozabilir mi?

Daha sonra başlatılamayan bir kernel 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. Yaygın senaryo gecikmeli bir hatadır: kernel 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 hangi çalışmanın başlattığınız kernel'i yüklediğini bulmak için /var/log/apt/history.log dosyasını okuyun.