Sunucum Açılmıyor” Sandığım Şey Aslında Ekran Sorunuymuş: Bir Debian 12 + Supermicro Hikâyesi

Yeni kurduğum Debian 12 sunucuya reboot attım ve ekran şu iki satırda kalakaldı:

x86/cpu: SGX disabled by BIOS
[FAILED] Failed to start systemd-sysctl.service - Apply Kernel Variables

İlk bakışta sistem açılmıyor gibiydi. 30 dakika bekledim, hiçbir şey değişmedi. Ama sonunda ortaya çıkan sorun, ekranda gördüğüm hataların hiçbiriyle ilgili değildi. İşte adım adım neyi neden yanlış kovaladığımız ve gerçek çözümün ne olduğu.

Yanıltıcı İpucu 1: “SGX disabled by BIOS”

Bu satır bir hata değil, sadece bilgilendirme. Intel SGX özelliği BIOS’ta kapalı olduğu için kernel bunu log’a düşüyor. Boot’u durduran bir şey değil. Buraya takılmak zaman kaybıydı.

Yanıltıcı İpucu 2: “Failed to start systemd-sysctl.service”

Ekrandaki asıl dikkat çeken “FAILED” satırı buydu. Journal’ı çıkardığımda gerçek hatayı gördüm:

Couldn't write '"2000 64000"' to 'net/ipv4/ip_local_port_range': Invalid argument

/etc/sysctl.d/ altındaki bir config dosyasında değerler tırnak içinde yazılmıştı:

net.ipv4.ip_local_port_range = "2000 64000"

Kernel, /proc/sys/... dosyalarına tırnak karakteriyle yazmayı kabul etmiyor, bu yüzden Invalid argument veriyordu. Tırnakları kaldırıp sysctl --system ile test ettim, düzeldi.

Ama işin sırrı şurada: Bu servisin fail olması boot’u hiç durdurmuyordu. systemd-sysctl başarısız olsa bile sistem açılmaya devam ediyor. Yani bu da asıl sorun değildi — sadece yol üzerindeki temizlenmesi gereken bir çöptü.

Kritik Fark Ediş: Sistem Aslında Açılıyordu

Journal’ı incelediğimde asıl aydınlatıcı şeyi gördüm. Her boot’ta:

• Startup finished mesajı geliyordu
• SSH servisi ayağa kalkıyordu (ilginç bir şekilde port 22 değil, port 222)
• Docker, containerd, login prompt hepsi başlıyordu

Yani sistem hiçbir zaman donmuyordu. Bunu SSH ile bağlanarak doğruladım — bağlantı sorunsuz gidiyordu. Sunucu tamamen sağlıklıydı.

Peki neden ekranda takılı görünüyordu? İki sebep vardı:

Birincisi, GRUB’daki quiet parametresi kernel mesajlarının çoğunu gizliyordu. Onu kaldırınca bütün boot mesajları akmaya başladı. Ama akış yine belli bir noktada duruyordu — bu sefer görsel yanılsama değil, gerçekten o noktadan sonra ekrana hiçbir şey çıkmıyordu.

Sorunu Sıkıştırmak: Ekran mı, Sistem mi?

En ayırt edici testi yaptım. SSH üzerinden doğrudan fiziksel ekrana yazı bastım:

echo "MERHABA TTY1" > /dev/tty1

Fiziksel monitörde hiçbir şey çıkmadı.

İşte bu her şeyi netleştirdi. Sistem çalışıyor, klavye tanınıyor (dmesg’de USB klavye görünüyordu, ışıklar yanıyordu), agetty login prompt’unu hazırlamış — ama AST GPU’dan fiziksel VGA çıkışına görüntü gitmiyordu.

Sorun boot değil, sistem değil, sysctl değil, klavye değildi. Tek gerçek sorun ekrana görüntü gitmemesiydi.

Kök Neden: ast Sürücüsü

Donanım bir Supermicro SYS-512B-WR (X14SBW-F anakart), ekran çıkışını Aspeed AST2600 BMC GPU’su sağlıyor. Kanıtlar şunu gösteriyordu:

• ast sürücüsü kernel içinde yükleniyordu (lsmod | grep ast doluydu)
• fb0 framebuffer cihazı oluşuyordu
• DRM connector connected diyordu

Ama görüntü yoktu. Dikkat çeken nokta şuydu: boot’un ilk kısmında (BIOS/efifb aşamasında) ekran çalışıyordu. Görüntü tam olarak kernel’in ast DRM sürücüsüne geçtiği anda (~18.6 saniye) kayboluyordu.

Yani Debian 12’nin stock kernel’indeki (6.1.0-50) ast sürücüsü, bu görece yeni AST2600 donanımıyla düzgün modeset yapamıyordu. Sürücü yükleniyor ama fiziksel çıkışa sinyal veremiyordu. Bir donanım arızası değil, sürücünün bu yeni platform için henüz yeterince olgunlaşmamış olmasıydı.

Çözüm: Backports’tan Yeni Kernel

AST2600 desteği daha yeni kernel sürümlerinde epey iyileştirildi. Bu yüzden Debian backports’tan güncel bir kernel kurdum:

cat > /etc/apt/sources.list.d/backports.list <<EOF
deb https://deb.debian.org/debian bookworm-backports main non-free-firmware
EOF

apt update
apt install -t bookworm-backports linux-image-amd64 linux-headers-amd64

Reboot attım ve ekran düzeldi. Yeni kernel ast sürücüsünün düzeltmelerini içeriyordu, modeset artık doğru çalışıyor ve VGA çıkışına görüntü geliyordu.

Çıkarılan Dersler

Bu maceradan birkaç genel ders çıktı:

Ekranda gördüğün son satır, sorunun kaynağı olmayabilir. “SGX disabled” ve “sysctl FAILED” gerçek sorunla ilgisizdi; dikkati asıl meseleden uzaklaştırdı.

quiet parametresi tanı koymayı zorlaştırır. Sunucularda sorun ararken GRUB’dan quiet‘i geçici olarak kaldırmak, boot’un gerçekte nerede olduğunu görmeni sağlar.

Sistemin gerçekten donup donmadığını anlamanın en hızlı yolu SSH’tır. Ekran donuk görünse bile SSH bağlanıyorsa, sorun neredeyse kesinlikle konsol/ekran tarafındadır, sistemde değil.

echo "test" > /dev/tty1 çok değerli bir teşhis komutu. Sistemin fiziksel ekrana yazıp yazamadığını tek satırda gösteriyor.

Yeni sunucu donanımı + eski dağıtım kernel’i tanıdık bir problemdir. Görece yeni anakartlarda (özellikle BMC/GPU sürücüleri) stock kernel yetersiz kalabilir; backports kernel çoğu zaman en temiz çözümdür.

Son Not

Backports’tan gelen kernel normal apt upgrade ile otomatik güncellenmez — güncellemeleri almak için -t bookworm-backports bayrağını açıkça kullanman gerekir. Güvenlik güncellemelerini kaçırmamak için ara sıra kontrol etmekte fayda var. Eski kernel de GRUB’da durmaya devam eder, yeni kernel’de beklenmedik bir sorun çıkarsa geri dönebilirsin.