29 Ekim 2026 Perşembe

taşınabilir bilgisayarda Fedora 44 üzerinde intel gpu + nvidia 4060 kullanımının yapılandırılması

Intel ve NVIDIA kartı birlikte olan bir laptopta, Fedora 44 ve MATE masaüstü ile üç sorunla karşılaştım:

  • Harici monitör ile laptop ekranı ters tarafta duruyordu.
  • Ekran düzenini değiştirmeye çalıştığımda X kapanıp yeniden açılıyor, oturum gidiyordu.
  • Bir düzeltmeden sonra monitör takılıyken her şey çalıştı, ama monitör yokken laptop ekranına hiç görüntü gelmedi.

Bu yazıda sorunların nedenini, nasıl bulduğumu ve iki durumda da (monitörlü ve monitörsüz) çalışan çözümü anlatıyorum. Yazının sonunda tüm adımları yapan bir script var.

Ortam

DağıtımFedora 44
MasaüstüMATE, X11 (Wayland değil)
Giriş ekranı yöneticisilightdm (slick-greeter)
Dahili grafik kartıIntel Meteor Lake (Intel Arc)
Harici grafik kartıNVIDIA GeForce RTX 4060 Laptop
NVIDIA sürücüsü595.112.07
Laptop ekranı1920x1200, Intel kartına bağlı
Harici monitörLG UltraWide 2560x1080, HDMI ile NVIDIA kartına bağlı

Önemli nokta şu: laptop ekranı Intel kartına, HDMI çıkışı ise NVIDIA kartına bağlı. İki ekranı tek masaüstünde göstermek için iki kartın birlikte çalışması gerekiyor. Bu birlikte çalışmanın adı PRIME.

Önce hangi kartın neye bağlı olduğuna bakın

X'in gördüğü kartları ve ekranları şu komutlar gösterir:

xrandr --listproviders
xrandr --query | grep -E "Screen| connected"

Benim sistemimde (çözümden sonra) çıktı şöyle:

Provider 0: ... name:NVIDIA-0
Provider 1: ... Sink Output ... name:modesetting
Screen 0: minimum 8 x 8, current 4480 x 1200, maximum 32767 x 32767
HDMI-0 connected 2560x1080+0+0 ...
eDP-1-1 connected primary 1920x1200+2560+0 ...

NVIDIA-0 NVIDIA kartı, modesetting Intel kartıdır. HDMI-0 harici monitör, eDP-1-1 laptop ekranıdır. Sizin sisteminizde bu adlar farklı olabilir. Scriptte bu adları kullandığım için kendi adlarınızı not edin.

Sorun 1: Ekran düzeni değişince X çöküyor

X'in kendiliğinden kapanıp açılması bir çökmedir. Çökme kayıtları şu komutla görülür:

coredumpctl list --since today
TIME                         PID   SIG     EXE
... 10:19:14  7475  SIGSEGV /usr/libexec/Xorg
... 10:19:43 22518  SIGSEGV /usr/libexec/Xorg
... 10:20:42 25777  SIGSEGV /usr/libexec/Xorg
...

Çökmenin nerede olduğunu görmek için:

coredumpctl info <PID> --no-pager | grep -E "^\s+#[0-9]+"
#4  wfbDestroyPixmap (/usr/lib64/xorg/modules/libwfb.so + 0xb7f9)
#5  n/a (/usr/lib64/xorg/modules/drivers/nvidia_drv.so + 0x2359d4)

Çökme NVIDIA'nın X sürücüsünün içinde. O sırada xrandr --listproviders çıktısında Intel (modesetting) birinci sıradaydı, NVIDIA ise NVIDIA-G0 adıyla ikinci sıradaydı. Yani:

  • X, Intel kartını birincil kart olarak kullanıyordu.
  • HDMI'deki monitör, NVIDIA kartı üzerinden "ek çıkış" olarak sürülüyordu. Bu düzenin adı reverse PRIME.

Bu düzende NVIDIA çıkışının ayarı değiştirilince X'in çökmesi, NVIDIA sürücüsünün 580 ve 595 sürümlerinde bilinen bir hata. Benzer raporlar yazının sonundaki kaynaklarda var.

Neden Intel birincildi? NVIDIA'yı birincil kart yapan ayar dosyası /etc/X11/xorg.conf.d/10-nvidia.conf silinmişti. Dosyanın paketten gelip gelmediğini ve yerinde olup olmadığını şu komut gösterir:

rpm -V xorg-x11-nvidia
missing   c /etc/X11/xorg.conf.d/10-nvidia.conf

Bu dosyanın içeriği şu (NVIDIA'nın kendi paketindeki hali):

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "yes"
    Option "SLI" "Auto"
    Option "BaseMosaic" "on"
EndSection

PrimaryGPU "yes" satırı NVIDIA'yı birincil kart yapar. Bu durumda X, Intel kartını kendiliğinden "ek çıkış" olarak bağlar ve laptop ekranı Intel üzerinden gösterilir. Bu, reverse PRIME'ın tersidir ve benim sistemimde düzen değişince çökmedi.

Sorun 2: nvidia-xconfig laptop ekranını yok ediyor

Çözüm ararken nvidia-xconfig komutunu denedim. Bu komut /etc/X11/xorg.conf dosyasını üretir. Ürettiği dosyada yalnızca NVIDIA kartı tanımlıdır. Bu dosya varken X, Intel kartını hiç kullanmaz. Sonuç: harici monitör çalışır, laptop ekranı X'te hiç görünmez.

Elle Intel bölümü ekleyerek de denedim, yine olmadı. İki hata vardı:

  • Yanlış sürücü: Intel için Driver "intel" yazmıştım. Bu eski sürücü (xf86-video-intel) Meteor Lake gibi yeni işlemcilerde X'i çökertiyor. Doğrusu modesetting sürücüsü. X bunu ayar yazmadan kendisi seçiyor.
  • İki ayrı ekran: İki ayrı "Screen" bölümü tek masaüstü değil, birbirinden ayrı iki X ekranı demek. Pencereler bir ekrandan diğerine taşınamaz.

Sonuç olarak bu düzende /etc/X11/xorg.conf dosyasına hiç gerek yok. 10-nvidia.conf yeterli.

Sorun 3: Monitör yokken laptop ekranı kararıyor

xorg.conf kaldırılıp 10-nvidia.conf geri konunca, monitör takılıyken iki ekran da sorunsuz çalıştı. Ama monitör çıkarılıp laptop açılınca ekrana görüntü gelmedi.

Monitörsüz açılışın X kaydında (/var/log/Xorg.0.log) şunlar vardı:

(--) NVIDIA(GPU-0): DFP-0: disconnected
(--) NVIDIA(GPU-0): DFP-1: disconnected
(--) NVIDIA(GPU-0): DFP-2: disconnected
(--) NVIDIA(GPU-0): DFP-3: disconnected
(--) NVIDIA(0): No enabled display devices found; starting anyway ...
(II) NVIDIA(0): Validated MetaModes:
(II) NVIDIA(0):     "NULL"
...
(II) modeset(G0): Output eDP-1-1 has no monitor section
(II) NVIDIA(0): Setting mode "NULL"

Anlamı şu:

  • NVIDIA birincil kart, ama NVIDIA'ya bağlı hiç ekran yok. X ekran modunu boş ("NULL") bırakıyor.
  • Laptop ekranı (eDP-1-1) Intel üzerinden tanınıyor, ama onu açan kimse yok.

Monitör takılıyken bu sorun görünmüyor, çünkü NVIDIA'nın kendi ekranı olduğu için X açılırken bir mod seçiyor ve masaüstü oturumu ikinci ekranı da açıyor.

Çözüm: lightdm'in display-setup-script ayarı. lightdm, X açılır açılmaz ve giriş ekranını göstermeden önce bu ayarda yazan dosyayı root olarak çalıştırır. Bu dosyada iki iş yapılır:

  1. Intel kartının çıkışları NVIDIA'ya bağlanır: xrandr --setprovideroutputsource modesetting NVIDIA-0
  2. Takılı ekranlar xrandr ile açılır. Monitör varsa monitör solda ve birincil, laptop ekranı sağda olur. Monitör yoksa laptop ekranı tek ekran olur.

Bu yöntem NVIDIA'nın kendi belgelerinde de PRIME için önerilen yöntemdir.

Çözümün özeti

DosyaDurumGörevi
/etc/X11/xorg.confOlmamalınvidia-xconfig ile üretilen hali laptop ekranını kapatıyor.
/etc/X11/xorg.conf.d/10-nvidia.confOlmalıNVIDIA'yı birincil kart yapar, Intel'i ek çıkış olarak bağlar.
/etc/lightdm/nvidia-prime-ekran.shOlmalıX açılınca ekranları bağlar ve açar.
/etc/lightdm/lightdm.conf.d/50-nvidia-prime.confOlmalılightdm'e yukarıdaki dosyayı çalıştırmasını söyler.

Script

Aşağıdaki script tüm adımları yapar. Her adımda önce mevcut durumu kontrol eder. Dosya zaten doğruysa dokunmaz. Değiştireceği dosyanın önce yedeğini alır. Ne yaptığını ve neyi atladığını ekrana yazar. --force verilirse dosyaları aynı olsa bile yeniden yazar.

Kullanmadan önce: scriptteki HARICI=HDMI-0 ve LAPTOP=eDP-1-1 satırlarını kendi xrandr --query çıktınızdaki adlarla değiştirin. NVIDIA birincilken laptop ekranının adı genelde eDP-1-1 gibi sonuna ek almış olur.

Dosya adı: nvidia-intel-prime-duzelt.sh

#!/bin/bash
# NVIDIA + Intel (PRIME) ekran ayarini duzeltir. Harici monitor takili da
# olsa takili olmasa da grafik ekranin acilmasini saglar.
#
# Bu laptopta:
#   - Harici monitor (HDMI) NVIDIA kartina bagli. X'teki adi: HDMI-0
#   - Laptop ekrani (eDP) Intel kartina bagli. X'teki adi: eDP-1-1
#
# Hedef durum:
#   1) /etc/X11/xorg.conf YOK. nvidia-xconfig ile uretilen bu dosya sadece
#      NVIDIA'yi tanimliyor, laptop ekranini X'in disinda birakiyor.
#   2) /etc/X11/xorg.conf.d/10-nvidia.conf VAR. NVIDIA birincil kart olur,
#      Intel karti X'e ek cikis olarak baglanir (surucusu: modesetting).
#   3) /etc/lightdm/nvidia-prime-ekran.sh VAR. lightdm, X acilir acilmaz bu
#      dosyayi calistirir. Dosya Intel cikislarini NVIDIA'ya baglar ve takili
#      ekranlari acar. Bu adim olmadan, harici monitor yokken NVIDIA'da hic
#      ekran olmadigi icin X bos ekranla baslar ve laptop ekrani kapali kalir.
#   4) /etc/lightdm/lightdm.conf.d/50-nvidia-prime.conf VAR. lightdm'e 3.
#      adimdaki dosyayi calistirmasini soyler.
#
# Her adim once kontrol edilir; zaten dogruysa atlanir.
# --force : dosyalar ayni olsa bile yeniden yazilir.
# Calistirma: sudo bash nvidia-intel-prime-duzelt.sh [--force]
# Script lightdm'i YENIDEN BASLATMAZ; sonunda ne yapilacagini yazar.

set -euo pipefail
FORCE=0; [ "${1:-}" = "--force" ] && FORCE=1
[ "$(id -u)" -eq 0 ] || { echo "HATA: root olarak calistirin (sudo)."; exit 1; }

TARIH=$(date +%Y%m%d-%H%M%S)
DEGISTI=0

# Verilen icerigi (stdin) hedef dosyaya yazar. Icerik ve izin ayniysa atlar.
# Farkliysa once yedek alir, sonra gecici dosyaya yazip mv ile tasir.
# Kullanim: dosya_yaz <hedef> <izin>  < icerik
dosya_yaz() {
    local hedef=$1 izin=$2 dizin gecici
    dizin=$(dirname "$hedef")
    gecici=$(mktemp "$dizin/.$(basename "$hedef").XXXXXX")
    cat > "$gecici"
    chmod "$izin" "$gecici"
    if [ -e "$hedef" ] && cmp -s "$gecici" "$hedef" \
       && [ "$(stat -c '%a %U:%G' "$hedef")" = "$izin root:root" ] \
       && [ "$FORCE" -eq 0 ]; then
        rm -f "$gecici"
        echo "ATLANDI: $hedef zaten dogru."
        return 0
    fi
    [ -e "$hedef" ] && cp -av "$hedef" "$hedef.yedek-$TARIH"
    mv -f "$gecici" "$hedef"
    chown root:root "$hedef"
    restorecon "$hedef" 2>/dev/null || true
    echo "YAPILDI: $hedef yazildi."
    DEGISTI=1
}

# 1) nvidia-xconfig ile uretilmis /etc/X11/xorg.conf dosyasini kenara al
if [ -e /etc/X11/xorg.conf ]; then
    mv -v /etc/X11/xorg.conf "/etc/X11/xorg.conf.yedek-$TARIH"
    echo "YAPILDI: /etc/X11/xorg.conf kenara alindi (yedek: /etc/X11/xorg.conf.yedek-$TARIH)"
    DEGISTI=1
else
    echo "ATLANDI: /etc/X11/xorg.conf zaten yok."
fi

# 2) 10-nvidia.conf (xorg-x11-nvidia paketindeki orijinal icerik)
install -d -m 755 -o root -g root /etc/X11/xorg.conf.d
dosya_yaz /etc/X11/xorg.conf.d/10-nvidia.conf 644 <<'CONF'
Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "yes"
    Option "SLI" "Auto"
    Option "BaseMosaic" "on"
EndSection
CONF

# 3) lightdm'in X acilinca calistiracagi ekran hazirlama dosyasi
install -d -m 755 -o root -g root /etc/lightdm/lightdm.conf.d
dosya_yaz /etc/lightdm/nvidia-prime-ekran.sh 755 <<'SH'
#!/bin/sh
# lightdm, X acildiktan hemen sonra bu dosyayi root olarak calistirir.
# Kuran: nvidia-intel-prime-duzelt.sh
# Gorevi:
#   - Intel kartinin cikislarini (laptop ekrani) NVIDIA'ya baglamak.
#   - Harici monitor takiliysa: monitor solda ve birincil, laptop ekrani sagda.
#   - Harici monitor yoksa: laptop ekrani tek ve birincil ekran.
# Buradaki bir hata lightdm'i durdurmasin diye dosya her zaman 0 ile biter.
# Ne yapildigi /var/log/lightdm/nvidia-prime-ekran.log dosyasina yazilir.

LOG=/var/log/lightdm/nvidia-prime-ekran.log
exec >>"$LOG" 2>&1
echo "=== $(date '+%F %T') DISPLAY=$DISPLAY"

XR=/usr/bin/xrandr
HARICI=HDMI-0
LAPTOP=eDP-1-1

# Intel cikislarini NVIDIA'ya bagla (zaten bagliysa zarari yok)
$XR --setprovideroutputsource modesetting NVIDIA-0 || echo "UYARI: setprovideroutputsource basarisiz"

BAGLI=$($XR --query | awk '$2=="connected"{print $1}')
echo "Takili ekranlar: $(echo $BAGLI)"

takili() { echo "$BAGLI" | grep -qx "$1"; }

if takili "$HARICI" && takili "$LAPTOP"; then
    $XR --output "$HARICI" --auto --primary --pos 0x0 \
        --output "$LAPTOP" --auto --right-of "$HARICI"
elif takili "$LAPTOP"; then
    $XR --output "$LAPTOP" --auto --primary --pos 0x0
    takili "$HARICI" || $XR --output "$HARICI" --off 2>/dev/null
else
    # Ad beklenenden farkliysa: takili her ekrani varsayilan ayarla ac
    $XR --auto
fi
echo "Sonuc: $?"
$XR --query | grep -E " connected" || true
exit 0
SH

# 4) lightdm'e bu dosyayi calistirmasini soyleyen ayar
dosya_yaz /etc/lightdm/lightdm.conf.d/50-nvidia-prime.conf 644 <<'CONF'
# NVIDIA + Intel (PRIME): X acilinca laptop ekranini ve harici monitoru ac.
# Kuran: nvidia-intel-prime-duzelt.sh
[Seat:*]
display-setup-script=/etc/lightdm/nvidia-prime-ekran.sh
CONF

# Baska bir yerde ikinci bir display-setup-script tanimi var mi? (cakisma kontrolu)
DIGER=$(grep -rlE "^\s*display-setup-script" /etc/lightdm/lightdm.conf /etc/lightdm/lightdm.conf.d/ 2>/dev/null \
        | grep -v "50-nvidia-prime.conf" || true)
[ -n "$DIGER" ] && echo "UYARI: su dosyalarda da display-setup-script var, sonuncusu gecerli olur: $DIGER"

echo
if [ "$DEGISTI" -eq 1 ]; then
    echo "Ayar degisti. Etkili olmasi icin oturumu kapatin ve su komutu calistirin:"
    echo "    sudo systemctl restart lightdm"
    echo "Ekran gelmezse Ctrl+Alt+F3 ile konsola gecip geri alin:"
    echo "    sudo rm /etc/lightdm/lightdm.conf.d/50-nvidia-prime.conf"
    echo "    sudo systemctl restart lightdm"
    echo "Ekran hazirlama kaydi: /var/log/lightdm/nvidia-prime-ekran.log"
else
    echo "Degisiklik yok, yeniden baslatma gerekmiyor."
fi

Uygulama

Scripti çalıştırın:

sudo bash nvidia-intel-prime-duzelt.sh

Script lightdm'i kendisi yeniden başlatmaz, çünkü bu açık oturumu kapatır. Açık işlerinizi kaydedip oturumu kapatın, sonra:

sudo systemctl restart lightdm

Ya da laptopu yeniden başlatın.

Test

  1. Monitörü çıkarın ve laptopu yeniden başlatın. Giriş ekranı laptop ekranında görünmeli.
  2. Monitörü takın ve laptopu yeniden başlatın. Monitör solda, laptop ekranı sağda olmalı.

Benim sistemimde iki durumda da sorunsuz çalıştı.

Ekran hazırlama dosyasının ne yaptığı şu kayıtta görülür:

sudo cat /var/log/lightdm/nvidia-prime-ekran.log

Bir şey ters giderse

Ekrana görüntü gelmezse Ctrl+Alt+F3 ile metin konsoluna geçin, kullanıcı adı ve şifrenizle girin, sonra:

sudo rm /etc/lightdm/lightdm.conf.d/50-nvidia-prime.conf
sudo systemctl restart lightdm

X'in kendisi açılmıyorsa 10-nvidia.conf dosyasını da kaldırın:

sudo rm /etc/X11/xorg.conf.d/10-nvidia.conf
sudo systemctl restart lightdm

Sorunu incelemek için işe yarayan komutlar:

# X'in son açılış kaydındaki hatalar
grep -E "\(EE\)|PrimaryGPU|Setting mode" /var/log/Xorg.0.log

# Bir önceki X açılışının kaydı
grep -E "\(EE\)|PrimaryGPU|Setting mode" /var/log/Xorg.0.log.old

# X çökmeleri
coredumpctl list --since today

# Yüklü NVIDIA sürücü sürümü
nvidia-smi --query-gpu=driver_version,name --format=csv,noheader

Notlar

  • Wayland kullananlar için geçerli değil. Bu yazı X11 oturumu ve lightdm içindir. Oturum türünü echo $XDG_SESSION_TYPE gösterir.
  • Oturum açıkken monitör takıp çıkarmak: Bu durumda ekranları masaüstünün kendi ekran ayarı yönetir. lightdm dosyası yalnızca X açılırken çalışır.
  • Sürücüyü tek yoldan kurun. NVIDIA sürücüsünü hem paket (rpm) hem de NVIDIA'nın .run kurucusu ile kurmak dosyaların birbirinin üzerine yazılmasına yol açar. .run ile kurulan çekirdek modülü çekirdek güncellemesinden sonra yeni çekirdekte olmaz ve X açılmaz. Bu durumda X kaydında şu hata görülür: Failed to initialize the NVIDIA kernel module.
  • Intel için "intel" sürücüsünü yazmayın. Yeni Intel işlemcilerde modesetting sürücüsü kullanılmalı.

Kaynaklar

26 Ağustos 2026 Çarşamba

Uygulamanın Desteklediği Linux Dağıtımı ve Çekirdek Sertifikasyon Aralığı

Çekirdek Sertifikasyon Aralığı

Linux Sistem Yönetimi

“Asgarinin üzerindeyiz, sorun olmaz”

Çekirdek sertifikasyonu hakkındaki en yaygın yanılgı, üreticinin yayımladığı tek bir satırı yanlış okumaktan doğuyor. Oracle 19c ve RHEL 9 örneğinde, yamanın içine bakarak.

Kurumsal Linux ortamlarında yıllardır aynı cümleyi duyuyorum:

Sık duyulan

“Üreticinin istediği asgari çekirdek sürümü şu. Biz onun üzerindeyiz. O zaman en güncel yamaya çıkabiliriz.”

Cümle mantıklı görünüyor. Yazılım bir asgari sürüm istiyor, siz o sürümün üzerindesiniz, dolayısıyla şart sağlanmış oluyor. Sürüm numaraları sonuçta artan bir sayı dizisi; büyük olan küçüğü kapsar.

Ne yazık ki bu, işletim sistemi çekirdeğine modül yükleyen yazılımlar söz konusu olduğunda doğru değil. Bu yazıda neden doğru olmadığını, Oracle Database 19c ile Red Hat Enterprise Linux 9 örneği üzerinden, doğrulanabilir kanıtlarla anlatacağım. Örnek Oracle ama mesele Oracle’a özgü değil — sonunda buna döneceğim.

Asgari sürüm bir taban çizgisidir, aralık değil

Oracle’ın Grid Infrastructure ve RAC kurulum kılavuzundaki işletim sistemi kontrol listesinde RHEL 9 satırı şöyle:

Oracle — OS Checklist for Grid Infrastructure and Oracle RAC, 19c

Red Hat Enterprise Linux 9: 5.14.0-70.22.1.el9_0.x86_64 or later

“or later” ifadesi, cümleyi okuyan herkesi aynı yere götürüyor: daha yeni olan her çekirdek uygun. Oysa bu satır yalnızca alt sınırı söylüyor. Bir üst sınır olup olmadığı hakkında hiçbir şey söylemiyor — ve üst sınır, aynı belgede değil, yazılımın kendi içinde tanımlı.

Bunu görmek için belgeleri okumayı bırakıp yazılımın içine bakmak gerekiyor.

Kanıt: yamanın içine bakmak

Oracle’ın küme dosya sistemi ACFS ve disk filtresi AFD, kullanıcı alanında çalışan programlar değil; çekirdek modülleri. Oracle bu modülleri sizin sisteminizde kaynak koddan derletmiyor. Her Release Update’in (RU) içine, belirli çekirdek sürümleri için önceden derlenmiş olarak koyuyor.

Elimdeki en güncel yama olan 19.29.0.0.251021 (Ekim 2025) GI RU’sunun içindeki ACFS bileşenini açıp usm/install/Oracle/EL9/x86_64/ dizinine baktığımda karşıma çıkan sürücülerin tamamı şunlar:

oracleacfs-5.14.0-284.11.1.el9_2.x86_64.rpm    →  RHEL 9.2
oracleacfs-5.14.0-362.18.1.el9_3.x86_64.rpm    →  RHEL 9.3
oracleacfs-5.14.0-427.13.1.el9_4.x86_64.rpm    →  RHEL 9.4
oracleacfs-5.14.0-503.11.1.el9_5.x86_64.rpm    →  RHEL 9.5
oracleacfs-5.14.0-570.12.1.el9_6.x86_64.rpm    →  RHEL 9.6
RHEL 9 ara sürümleri ve en güncel RU’daki ACFS sürücü karşılıkları
9.0yok
9.1yok
9.25.14.0-284
9.35.14.0-362
9.45.14.0-427
9.55.14.0-503
9.65.14.0-570
9.7yok
9.8yok
belgedeki
asgari sürüm
bugün kurulan
tipik sistem
Derlenmiş sürücü var Sürücü yok

Bu liste üç şeyi birden söylüyor.

Birincisi, destek bir aralık değil, ayrık bir liste. Her RHEL ara sürümü için tam olarak bir sürücü var. “Şu sürümden sonrası” diye bir şey yok; “şu beş sürüm” var.

İkincisi, listenin bir tavanı var. En güncel yamanın desteklediği en yeni çekirdek 5.14.0-570, yani RHEL 9.6. Sisteminiz 9.7 veya 9.8 ise — ki bugün yeni kurulan bir RHEL 9 büyük ihtimalle öyle olacak — bu çekirdek için Oracle’ın yayımladığı bir sürücü yok.

Üçüncüsü, ve en can sıkıcısı: belgedeki asgari sürümün kendisi bile listede yok. Kontrol listesi 5.14.0-70 diyor, yani RHEL 9.0. Ama yukarıdaki listede 9.0 ve 9.1 için sürücü bulunmuyor. Yani kontrol listesindeki asgari şartı harfiyen sağlayan bir sistem kurup ACFS kullanmaya kalksanız, çalışmayacaktı.

Belgedeki tek satıra bakıp karar vermenin neden yetmediği tam olarak burada görülüyor.

Kurulum daha ilk adımda duruyor

İşin ilginç tarafı, bu sistemlerde sorun genellikle çalışma zamanında değil, çok daha erken ortaya çıkıyor.

Oracle 19c’nin baz kurulum medyası olan 19.3.0.0’ın içindeki ön koşul doğrulama tanım dosyasına (cv/cvdata/cvu_prereq.xml) baktığımda, tanımlı işletim sistemlerinin tamamı şunlar:

<OPERATING_SYSTEM RELEASE="OL7">
<OPERATING_SYSTEM RELEASE="RHEL7">
<OPERATING_SYSTEM RELEASE="SUSE12">
<OPERATING_SYSTEM RELEASE="SUSE15">

Listede RHEL 8 bile yok. Sebep basit: bu dosyanın tarihi 18 Şubat 2019. RHEL 9, Mayıs 2022’de çıktı. Medya, üzerine kurulmasını istediğiniz işletim sisteminden üç yıl eski.

Kurulum sihirbazı sistemi tanıyamadığı için ön koşul kontrolünde duruyor. Bu bir hata değil, tasarlanmış davranış.

İnternette bu noktada CV_ASSUME_DISTID gibi bir değişkenle kurulum programına sistemi RHEL 7 ya da 8 gibi tanıtmayı öneren çok sayıda yazı bulacaksınız. Yöntem işe yarıyor — kurulum ilerliyor. Ama ortaya çıkan şey, üreticinin desteklemediği bir konfigürasyon. Bir laboratuvarda sorun değil; üretim ortamında, bir destek talebinin ilk kapanma sebebi.

Doğru yol: yamayı kurulum sırasında uygulamak

Oracle’ın desteklediği yöntem, çoğu kişinin farkında olmadığı bir seçenekte gizli. Grid Infrastructure kurulum kılavuzundan:

Oracle — Applying Patches During a GI Installation or Upgrade, 19c

“Starting with Oracle Grid Infrastructure 18c, you can download and apply Release Updates (RUs) and one-off patches during an Oracle Grid Infrastructure installation or upgrade.”

Komut şu şekilde:

./gridSetup.sh -applyRU /yol/38298204 \
               -applyOneOffs /yol/one-off-1,/yol/one-off-2

Yani kurulum programı, kendisini önce yamalıyor, sonra kuruluma başlıyor. Yamalanmış kurulum programı yeni işletim sistemlerini tanıyor, güncel ön koşul tanımlarına sahip oluyor ve doğru sürücüleri getiriyor.

Buradan çıkan pratik sıralama şöyle:

  1. Hedef RHEL ara sürümüne, RU’nun sürücü listesine bakarak karar verin.
  2. Sistemi o sürüme kurun ve çekirdeği sabitleyin.
  3. Üreticinin ön hazırlık paketini (oracle-database-preinstall-* benzeri) kurun.
  4. OPatch’i güncelleyin — 19.29 için asgari 12.2.0.1.47.
  5. Kurulumu -applyRU ile başlatın.
  6. Kurulum sonrası acfsdriverstate supported ve afddriverstate supported ile doğrulayın.

Sıra önemli. Kurulum sonrası da aynı sıra geçerli: önce yazılımı hedef çekirdeği destekleyen seviyeye çıkarın, sonra işletim sistemini güncelleyin. Ters sırada ilerlerseniz, sunucu açılıyor ama sürücüsü olmayan bir çekirdeğe düşüyor; dosya sistemi mount edilemiyor, küme kaynakları gelmiyor.

Peki bu kısıttan kaçınmak mümkün mü?

Kısmen, evet. Ve burada 2026 itibarıyla çoğu kişinin kaçırdığı önemli bir gelişme var.

ASM disklerinin yönetimi için üç yol var: AFD (ASM Filter Driver), ASMLib ve udev kuralları. Yaygın kanı, Oracle’ın kendi ürünü olan AFD’nin tercih edilmesi gerektiği yönünde. Oysa Oracle 19c dokümantasyonundaki bildirim şöyle:

Oracle — Changes in This Release, 19c · “Deprecation of Oracle ASMFD”

“Oracle ASM Filter Driver (ASMFD) is deprecated on both Linux and Oracle Solaris beginning with Oracle Database 19c. It will be desupported in a future release.

On Linux systems running kernel 5.14 or higher (including Oracle Linux, RedHat Enterprise Linux, and SUSE Linux Enterprise Server), ASMFD filtering is already disabled and will not be supported going forward.”

RHEL 9’un tamamı 5.14 çekirdek ailesinde. Yani AFD’nin varlık sebebi olan özellik — ASM disklerine Oracle dışı yazmaları engelleyen filtre — RHEL 9’da zaten çalışmıyor. Geriye kalan tek işlevi disk adlandırma ve kalıcılık.

Oracle aynı yerde ASMLib v3’e geçilmesini öneriyor. Ancak ASMLib bir Oracle Linux bileşeni: “Oracle ASMLib is included with the Oracle Linux packages, and with SUSE Linux Enterprise Server.” Red Hat dağıtımları için ayrı bir destek notuna yönlendiriliyor ve Oracle’ın ASMLib indirme sayfaları RHEL 5, 6, 7 ile OL8, OL9 için mevcutken RHEL 8 ve RHEL 9 için bulunmuyor.

Geriye udev kalıyor — ve udev, Oracle’ın kendi kurulum kılavuzunda “Configuring Device Persistence Manually for Oracle ASM” başlığı altında adım adım belgelenmiş durumda.

RHEL 9’daAFDASMLib v3udev
19c’deki durumuDeprecatedDestekleniyorDestekleniyor
FiltrelemeDevre dışı——
Erişilebilir miEvetBelirsizEvet
Çekirdek modülü gerektirir miEvetHayırHayır
Çekirdek sürümüne kilitler miEvetHayırHayır
Sonuç açık: RHEL 9’da AFD, sizi çekirdek sürümüne kilitliyor ve karşılığında asıl faydasını sunmuyor. udev yalnızca bir alternatif değil, üreticinin kendi yol haritasıyla uyumlu olan tercih.

Bir ayrımı vurgulamakta fayda var: AFD ile ACFS aynı şey değil. AFD bir disk filtresi, ACFS bir küme dosya sistemi. udev’e geçmek AFD kaynaklı çekirdek kilidini kaldırır; ancak gerçekten ACFS dosya sistemi kullanıyorsanız oradaki kilit yerinde durur. ACFS’i gerçekten ihtiyaç duyduğunuz için mi yoksa kurulum sırasında öyle geldiği için mi kullandığınız, sorulmaya değer bir soru.

Bu yalnızca Oracle’ın meselesi değil

Buraya kadar anlattığım her şey Oracle örneği üzerindendi ama kural genel: çekirdeğe modül yükleyen her yazılım, çekirdek sürümüne sıkı biçimde bağlıdır.

Aynı davranışı şuralarda da görürsünüz:

  • Depolama ve küme dosya sistemleri (GPFS/Spectrum Scale, Lustre, ZFS on Linux)
  • Yedekleme ajanları ve snapshot sürücüleri
  • GPU sürücüleri (NVIDIA) ve hızlandırıcı yığınları
  • Sanallaştırma misafir araçları
  • Kernel modülü olan güvenlik/EDR ajanları
  • Bazı ağ ve multipath eklentileri

Bu ürünlerin bir kısmı DKMS ile kaynak koddan derlenir; onlarda esneklik daha fazladır ama bu sefer de derlemenin yeni çekirdek API’siyle uyumlu olması gerekir. Bir kısmı ise Oracle gibi önceden derlenmiş modül dağıtır; orada esneklik sıfırdır.

Buna karşılık, tipik bir uygulama yığını — web sunucusu, PHP, MariaDB, uygulama sunucuları — çekirdek sürümüne bu düzeyde bağlı değildir. Onlarda “asgarinin üzerinde olmak” çoğu zaman gerçekten yeterlidir. Yanılgı da buradan doğuyor: ekipler bir alanda geçerli olan sezgiyi, geçerli olmadığı bir alana taşıyorlar.

Pratik kontrol listesi

Bir sisteme çekirdek güncellemesi planlarken şu dört soruyu sorun:

  1. Bu sistemde çekirdek modülü yükleyen bir ürün var mı? lsmod çıktısını dağıtımın kendi paketleriyle karşılaştırın; dışarıdan gelen modülleri tespit edin.
  2. Varsa, hedef çekirdek üreticinin sertifikasyon listesinde mi? Belgedeki asgari sürüme değil, ürünün kendi sürücü listesine bakın. Çoğu zaman bu liste yamanın içindedir.
  3. Sıra ne olmalı? Neredeyse her zaman: önce uygulamayı hedef çekirdeği destekleyen sürüme çıkar, sonra işletim sistemini güncelle.
  4. Geri dönüş planı ne? Eski çekirdek GRUB’da duruyor mu, grubby --default-kernel beklediğiniz değeri veriyor mu?

Ve kümelenmiş sistemlerde bir beşincisi: güncelleme düğüm düğüm yapılır, pencere kapanmadan tüm düğümler aynı seviyede eşitlenir.

Kapanış

“En güncel yamaya çıkmak” güvenlik açısından doğru bir refleks ve çoğu sunucu için doğru cevap. Ama çekirdek modülü barındıran sistemlerde hedef, “en güncel” değil, “üreticinin desteklediği en güncel” olmalı. Bu ikisi aynı şey değil ve aradaki fark, bir bakım penceresinin sessizce geçmesiyle gece yarısı telefonla uyanmak arasındaki fark olabiliyor.

En sağlıklısı, bu konuşmayı sorun çıktığında değil, hedef sürüme karar verirken yapmak. Sistem ekibiyle veritabanı ekibi burada karşı taraflar değil; aynı hizmetin iki parçası. Bir tarafta çıkan aksaklığın faturasını er geç ikisi birlikte ödüyor.

Kaynaklar

  • Oracle — Operating System Checklist for Oracle Grid Infrastructure and Oracle RAC, 19c · docs.oracle.com
  • Oracle — Applying Patches During an Oracle Grid Infrastructure Installation or Upgrade, 19c · docs.oracle.com
  • Oracle — Changes in This Release for Oracle Database (“Deprecation of Oracle ASMFD”), 19c · docs.oracle.com
  • Oracle — Configuring Device Persistence Manually for Oracle ASM, 19c · docs.oracle.com
  • Oracle — Installing and Configuring Oracle ASMLIB Software, 19c · docs.oracle.com
  • Oracle — About Oracle Grid Infrastructure Software Patch Levels, 19c · docs.oracle.com
  • Mike Dietrich (Oracle) — Oracle Database 19c is certified on OL9 and RHEL9 · mikedietrichde.com
  • Oracle MOS — ACFS and AFD Support On OS Platforms (Certification Matrix), Doc ID 1369107.1
  • Oracle MOS — Requirements for Installing Oracle Database/Client 19c (19.19+) on OL9 or RHEL9, Doc ID 2982833.1

Yazıdaki sürücü listesi ve cvu_prereq.xml içeriği, Oracle’ın kendi kurulum ve yama medyasından doğrudan çıkarılmıştır.

26 Temmuz 2026 Pazar

Ansible değişkenlerini doğru yerde tutmak

Ansible Değişkenlerini Doğru Yerde Tutmak

Ansible · Değişkenler

Ansible değişkenlerini doğru yerde tutmak

Ansible'da 22 farklı değişken katmanı var. Asıl soru “hangisi kazanır?” değil — belgelerde yazıyor. Asıl soru şu: bu değişkeni nereye koymalıyım?

Ansible öğrenirken herkesin karşılaştığı bir an vardır: bir değişkeni değiştirirsiniz ama hiçbir şey olmaz. Başka bir yerde tanımlı aynı isimli değişken sizinkini eziyordur. Bu noktada çoğu kişi öncelik tablosunu ezberlemeye çalışır. Oysa tabloyu ezberlemek semptomu tedavi eder; hastalığı değil.

Hastalık şu: değişkeni ne olduğuna değil, o an aklınıza gelen yere koymak. Bu yazıda gerçek bir projeden — RHEL 9 ve RHEL 10 için osbuild-composer ile imaj üreten bir rolden — örneklerle, bir değişkenin yerini nasıl belirleyeceğinizi anlatacağım. Kendi yaptığım hatayı da göstereceğim.

Önce kısa hatırlatma: öncelik sırası

Ansible değişkenleri en düşükten en yükseğe doğru şu sırayla uygular. Sondakiler öncekileri ezer:

#KatmanNe zaman kullanılır
2Rol defaults/Rolün makul varsayılanı
3Envanter dosyasındaki grup değişkenleriNadiren; dağınık olur
4Envanter group_vars/allTüm makinelere ortak makine bilgisi
5Playbook group_vars/allPlaybook'a özgü, tüm gruplara
6Envanter group_vars/*Ortama/gruba özgü makine bilgisi
7Playbook group_vars/*Playbook'un gruba özgü zorlaması
9Envanter host_vars/*Tek makineye özgü
11Facts ve set_factÇalışma anında keşfedilen
12Play vars:Playbook'un kendi bağlamı
15Rol vars/Rolün ezilmemesi gereken sabitleri
18include_varsKoşullu yükleme (ör. sürüme göre)
22-e extra varsTek çalıştırmaya özgü; her şeyi ezer

Dikkat edilecek iki nokta var. Birincisi: group_vars/ ve host_vars/ iki ayrı yerde bulunabilir — envanterin yanında ve playbook'un yanında. İkincisi: playbook'un yanındaki, envanterinkini ezer.

Bunu kanıtlayalım

İddiaya güvenmeyin, ölçün. Üç katmanda aynı değişkeni tanımlayıp tek tek kaldıralım:

$ tree
├── inventory/
│   ├── hosts.yml
│   └── group_vars/all.yml        → nereden: "2-INVENTORY group_vars/all"
├── group_vars/all.yml            → nereden: "3-PLAYBOOK group_vars/all"
├── roles/demo/defaults/main.yml  → nereden: "1-ROLE defaults"
└── pb.yml
$ ansible-playbook -i inventory/hosts.yml pb.yml
kazanan -> 3-PLAYBOOK group_vars/all

$ rm group_vars/all.yml && ansible-playbook ...
kazanan -> 2-INVENTORY group_vars/all

$ rm inventory/group_vars/all.yml && ansible-playbook ...
kazanan -> 1-ROLE defaults
Playbook group_vars > envanter group_vars > rol defaults. Beklendiği gibi.

Pratik ipucu. Bir değerin nereden geldiğini merak ettiğinizde tahmin etmeyin: ansible-inventory --graph --vars ve ansible-inventory --host <makine> size envanterden gelenlerin tamamını gösterir. Rol katmanları için de ansible-playbook --list-tasks ve bir debug görevi en hızlı yoldur.

Asıl soru: bu değişken neyi tarif ediyor?

Karar kuralı bu kadar basit. Değişkenin adına değil, anlamına bakın:

Değişken neyi tarif ediyor?YeriNeden
Makineyi / ortamı
“RHEL 9 sunucusu şudur”
Envanter group_vars/ Envanterle birlikte seyahat eder. Aynı envanteri kullanan her playbook aynı bilgiyi alır.
Rolün makul varsayılanını
“aksi söylenmedikçe böyle davran”
Rol defaults/ En düşük öncelik = her katmandan ezilebilir. Rol kendi kendine yeter hale gelir.
Playbook'un kendi bağlamını
“çıktıları buraya yaz”
Play vars: Hedef makineyle ilgisi yoktur; envantere konursa yanlış yere yayılır.
Bu çalıştırmaya özgü seçimi
“şimdi RHEL 10 üret”
-e Her şeyi ezer, kalıcı değildir. Tam da geçici seçim için.
Ezilmemesi gerekeni
iç sabitler, eşleme tabloları
Rol vars/ Yüksek önceliklidir; kullanıcının kazara ezmesini istemediğiniz şeyler.

Gerçek bir örnek: osbuild imaj üretim rolü

Bu rol, parametre alarak RHEL 9 veya RHEL 10 için ISO / qcow2 / vmdk imajları üretiyor:

ansible-playbook build-image.yml \
  -e rhel_version=10 -e image_template=devel \
  -e '{"image_types":["qcow2","vmdk"]}'

rhel_version doğrudan hedef grubu seçiyor: RHEL 9 imajı RHEL 9 sunucusunda üretilmeli, çünkü osbuild-composer kendi host sürümünü varsayılan distro olarak alır.

Envanterde ne var

# inventory/group_vars/osbuild_rhel10.yml
ansible_user: remzi
ansible_become: true
osbuild_expected_major: "10"
osbuild_extra_sources:
  - id: crb
    url: https://cdn.redhat.com/.../codeready-builder/os
    required_for_templates: ["devel"]

Bunların hepsi makineyi tarif ediyor. “RHEL 10 sunucusunda CRB deposu gerekir” bilgisi, hangi playbook'u çalıştırdığınızdan bağımsızdır. Yarın bir cleanup.yml yazarsanız o da aynı envanteri kullanıp aynı bilgiyi alır.

Rol varsayılanlarında ne var

# roles/osbuild_image/defaults/main.yml
run_boot_test: true
enable_kdump: true
kdump_crashkernel: "2G-64G:256M,64G-:512M"
min_free_gib: {minimal: 12, devel: 30}

lvm_volumes:
  - {name: rootlv,     mount: /,          size_gib: 30, label: root}
  - {name: varcrashlv, mount: /var/crash, size_gib: 2,  label: var_crash}
  # ... 11 mantıksal birim

Disk şeması burada olmalı, çünkü rolün ne ürettiğini tarif ediyor. Üstelik tek kaynak olması sayesinde hem customizations.disk (qcow2/vmdk) hem de kickstart logvol satırları (ISO) aynı listeden üretiliyor — ikisinin birbirinden ayrışması yapısal olarak imkânsız hale geliyor.

Playbook'ta ne var

# build-image.yml
  vars:
    image_fetch_dir: "{{ playbook_dir }}/imajlar"
    artifact_dir: "{{ playbook_dir }}/artifacts"

Bunlar kontrol makinesinin yolları. Hedef sunucuyla hiçbir ilgileri yok. Ayrıca playbook_dir ancak playbook bağlamında anlamlıdır — envantere koyarsanız, aynı envanter başka bir dizinden kullanıldığında yanlış çözülür.

Benim yaptığım hata

İlk versiyonda politika değişkenlerinin hepsini envanterin group_vars/all.yml dosyasına koymuştum:

# inventory/group_vars/all.yml   ← YANLIŞ
run_boot_test: true
enable_kdump: true
min_free_gib: {minimal: 12, devel: 30}
compose_timeout_min: 90
image_fetch_dir: "{{ playbook_dir }}/imajlar"

Çalışıyordu. Ama iki gerçek sakıncası vardı:

  1. Ezme zinciri yanlış yerden başlıyordu. enable_kdump rolün varsayılanı olmalıydı. Envantere konunca rol defaults'ı sessizce eziliyor ve rol tek başına anlamsız hale geliyor — birisi rolü başka bir projede kullanmak istese, hangi değişkenleri tanımlaması gerektiğini bilemez.
  2. İkinci bir ortam eklendiğinde kopyalama zorunluluğu. inventory/prod/ ve inventory/test/ açtığınızda, ortamla hiç ilgisi olmayan politika değişkenlerini de iki kez yazmanız gerekir. Kopya olan yerde er geç ikisi birbirinden ayrışır.

Düzeltilmiş hali:

DeğişkenÖnceSonra
ansible_user, osbuild_extra_sourcesenvanter group_varsaynı — doğruydu
enable_kdump, run_boot_test, min_free_gibenvanter group_vars/allrol defaults
image_fetch_dir, artifact_direnvanter group_vars/allplay vars:
rhel_version, image_types-eaynı — doğruydu

Envanterin group_vars/all.yml dosyası artık boş — ama silmedim. İleride gerçekten tüm makinelere ortak bir makine ayarı gerektiğinde (proxy, zaman sunucusu, ortak depo) yeri orasıdır. Dosyanın içine bunu bir yorum olarak yazdım; boş bir dosyadan çok, niyeti belgelenmiş bir dosya bırakmak daha iyidir.

Sürüme göre değişenler: include_vars

Bu projede öğrendiğim en değerli şeylerden biri, sürüm farklarını veri olarak tutmaktı. RHEL 10'da kdump, kexec-tools paketinden ayrılıp kdump-utils'e taşınmış. Bunu göreve gömmek yerine:

- name: "Sürüme özel değişkenleri yükle"
  ansible.builtin.include_vars:
    file: "rhel{{ rhel_version }}.yml"

Böylece vars/rhel9.yml ve vars/rhel10.yml sürüm farklarını taşır, görevler sürümden bağımsız kalır. include_vars'ın önceliği yüksektir (18. sıra) — bu tam olarak istediğimiz şey: sürüme özgü veri, genel varsayılanı ezmeli.

Daha da iyisi: bu projede kdump paketini sabit yazmak yerine çalışma anında sorduk — dnf repoquery --file /usr/lib/systemd/system/kdump.service. Sonuç: RHEL 9'da kexec-tools, RHEL 10'da kdump-utils bulundu, hiçbir yere sabit yazılmadan. Değişkene hiç gerek kalmadı. En iyi değişken, yazmak zorunda kalmadığınız değişkendir.

Kaçınılması gereken üç tuzak

1. set_fact tipi sessizce değiştirir

Bir JSON dosyasını okuyup metin araması yapmak istedim:

- set_fact:
    manifest_text: "{{ manifest_raw.content | b64decode }}"

- assert:
    that: "'org.osbuild.lvm2.create' in manifest_text"   # her zaman False!

İçerik JSON'a benzediği için Ansible onu otomatik olarak dict'e çevirdi. Dolayısıyla in operatörü metin değil anahtar araması yaptı. Aradığım şey dosyada vardı ama testi hiç geçmiyordu. Çözüm: metin araması yerine from_json ile ayrıştırıp yapısal denetim yapmak.

2. delegate_to bağlantı değişkenlerini değiştirir

- command: "{{ 'cp ...' if ansible_connection == 'local' else 'scp ...' }}"
  delegate_to: localhost      # ← ansible_connection artık 'local'!

Delegasyon yapılan görevde ansible_connection, delegasyon hedefinin bağlantı türüdür. Asıl hedefin bilgisini kullanacaksanız, onu delegasyondan önce bir set_fact ile saklayın. Bu hatayı fark etmem, aynı kodun bir sunucuda çalışıp diğerinde patlamasını görmemi gerektirdi.

3. -e geri alınamaz

Extra vars her şeyi ezer ve playbook içinden değiştirilemez. Bu yüzden -e'yi yalnızca o çalıştırmaya özgü seçimler için kullanın (rhel_version, image_types). Kalıcı politikayı -e ile taşımaya başlarsanız, her çalıştırmada uzun bir komut satırı ezberlemek zorunda kalırsınız — ve bir gün birini yazmayı unutursunuz.

Özet: karar ağacı

SoruCevap
Makineyi/ortamı mı tarif ediyor?Envanter group_vars/ · host_vars/
Rolün makul varsayılanı mı?Rol defaults/
Sürüme/platforma göre mi değişiyor?Rol vars/ + include_vars
Playbook'un kendi bağlamı mı?Play vars:
Bu çalıştırmaya mı özgü?-e
Kullanıcı ezerse bozulur mu?Rol vars/ (defaults değil)

Bu kuralı uyguladığınızda öncelik tablosunu ezberlemenize gerek kalmaz — çünkü çakışma çıkmaz. Tablo, ancak aynı değişkeni birden fazla katmanda tanımladığınızda gerekir; ve bunu yapıyorsanız muhtemelen değişkeni yanlış yere koymuşsunuzdur.

Bu yazıdaki örnekler, RHEL 9 ve RHEL 10 için osbuild-composer ile ISO / qcow2 / vmdk imajları üreten gerçek bir Ansible rolünden alınmıştır. Öncelik sırasının tamamı için: Ansible — Using Variables.

16 Haziran 2026 Salı

Podman'da "unresolvable CDI devices nvidia.com/gpu=all" Hatası ve Çözümü

Podman'da "unresolvable CDI devices nvidia.com/gpu=all" Hatası ve Çözümü

Podman ile GPU gerektiren bir container (örneğin RHEL CLA, ollama, vllm gibi) çalıştırmaya çalışırken şu hatayı alabilirsiniz:

Error: setting up CDI devices: unresolvable CDI devices nvidia.com/gpu=all


















Bu hata, NVIDIA sürücünüz düzgün çalışıyor olsa bile (nvidia-smi çıktısı normal görünse bile) ortaya çıkabilir. Sorunun kaynağı, Podman'ın GPU'ya erişmek için kullandığı CDI (Container Device Interface) spec dosyasının sisteminizde bulunmamasıdır.

CDI Nedir?

CDI, container runtime'larının (Podman, Docker vb.) GPU gibi özel donanımlara erişimini standartlaştıran bir arayüzdür. Podman, --device nvidia.com/gpu=all gibi bir parametre aldığında, /etc/cdi/nvidia.yaml dosyasına bakarak GPU'nun container'a nasıl sunulacağını öğrenir. Bu dosya yoksa veya güncel değilse, yukarıdaki hatayı alırsınız.

Çözüm Adımları

1. NVIDIA Container Toolkit Kurulumu

Öncelikle nvidia-container-toolkit paketinin kurulu olup olmadığını kontrol edin:

rpm -q nvidia-container-toolkit

Kurulu değilse, NVIDIA'nın resmi repo'sunu ekleyip kurun:

curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
  sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo

sudo dnf install -y nvidia-container-toolkit

2. CDI Spec Dosyasını Oluşturun

Bu adım sorunun asıl çözümüdür. Aşağıdaki komut, sisteminizde bulunan NVIDIA GPU'ları tarayarak CDI spec dosyasını oluşturur:

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

3. Doğrulama

Spec'in başarıyla oluşturulduğunu doğrulayın:

nvidia-ctk cdi list

Çıktıda şuna benzer satırlar görmeniz gerekir:

INFO[0000] Found 2 CDI devices
nvidia.com/gpu=0
nvidia.com/gpu=all

4. Container'ı Tekrar Çalıştırın

Artık Podman GPU'yu CDI üzerinden çözebilir durumda. Uygulamanızı tekrar başlatın:

rhel-cla start

Alternatif: Spesifik GPU Belirtme

Eğer gpu=all hâlâ çözülemiyorsa, uygulamanızın yapılandırma dosyasında cihazı spesifik olarak belirtmeyi deneyin:

# nvidia.com/gpu=all yerine:
nvidia.com/gpu=0

Örneğin RHEL CLA için bu ayar ~/.config/rhel-cla/.env dosyasındadır.

Önemli Not

Kernel veya NVIDIA sürücü güncellemesi sonrasında CDI spec dosyası geçersiz hale gelebilir. Sürücü güncellemesi yaptıktan sonra sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml komutunu tekrar çalıştırmayı unutmayın.

Ortam Bilgisi

Bu yazıdaki çözüm aşağıdaki ortamda test edilmiştir:

  • Fedora / RHEL tabanlı dağıtımlar
  • NVIDIA GeForce RTX 4060 Laptop GPU
  • NVIDIA Driver 595.80, CUDA 13.2
  • Podman (rootless ve rootful)



















Umarım işinize yarar. Sorularınız varsa yorumlarda belirtebilirsiniz.

27 Şubat 2026 Cuma

Ne işe yarar; sar -n DEV

sar -n DEV|awk 'BEGIN{mak=0} !/txpck|x86|CPU|^[ \t]*$/{if (mak<$5) {mak=$5;li=$0}} END{print mak,li;}'

29 Aralık 2025 Pazartesi

Elektrikli Bisiklet Bataryaları hakkında

Bafang M615 (BBS02B / BBSHD) – Tam Paket Tablo + BOM + Özet

Bafang M615MM G320.750/1000.C (BBS02B / BBSHD) – Tam Paket Özellikler + Batarya + BOM

Bu sayfa: 750W ve 1000W varyantları için (48V ve 52V senaryoları dahil) teknik özet, aynakol (36T’den başlayarak), ısı/sürekli güç pratikleri, elektrik güvenliği, menzil hesap şablonu ve BOM (parça listesi) + otomatik toplamlar içerir.

Önemli not: “Tepe güç” burada pratikte en sık kullanılan tanımla, yaklaşık (Voltaj × Kontrolcü Akımı) olarak “tepe elektriksel giriş gücü” şeklinde hesaplanmıştır. Gerçek mekanik tepe; hız, vites, kadans, ısı ve yükle değişir.

1) Motor Özellikleri (Özet Tablo)

Motor kodu Piyasa adı Nominal (W) V A (tipik) Tepe (≈W) Tork BB uyumu (mm) Ağırlık (kg) İdeal batarya (BMS)
MM G320.750.C BBS02B 750 48 25 1200 ≈120–160 Nm (piyasada farklı yazılabilir) 68 / 73 / 83 / 90 / 100 / 110 / 120 5.6 48V BMS ≥30A (35A önerilir)
MM G320.1000.C BBSHD 1000 48 30 1440 160 Nm (Peak 200 Nm) 68 / 73 / 83 / 90 / 100 / 110 / 120 5.6 48V BMS ≥40A (45A önerilir)
MM G320.750.C BBS02B (52V) 750 52 25 1300 ≈120–160 Nm 68 / 73 / 83 / 90 / 100 / 110 / 120 5.6 52V BMS ≥30A (35A önerilir)
MM G320.1000.C BBSHD (52V) 1000 52 30 1560 160 Nm (Peak 200 Nm) 68 / 73 / 83 / 90 / 100 / 110 / 120 5.6 52V BMS ≥40A (45A önerilir)

2) Batarya Boyutlandırma (Ah/Wh önerileri)

Senaryo V A BMS (A) Min Ah Rahat Ah Min Wh Rahat Wh Not
BBS02B 48V 48 25 30 17 24 816 1152 Şehir + orta yokuş: 24Ah+ daha stabil (voltaj sarkması azalır)
BBSHD 48V 48 30 40 20 28 960 1344 Yokuş/kargo: 28Ah civarı daha az ısınma + daha az voltaj düşümü
BBS02B 52V 52 25 30 17 24 884 1248 52V: daha canlı tepki/hız; kablo/konnektör/BMS uyumu şart
BBSHD 52V 52 30 40 20 28 1040 1456 Performans yüksek: XT90-S + güçlü sigorta + kalın kablo önerilir

3) Aynakol / Dişli Seçimi (36T’den başlayarak)

Aynakol (T) Kullanım Artıları Eksileri Önerilen motor Not
36T Dik yokuş / kargo / düşük hız Tırmanış çok güçlü, ısı daha az Düzde maksimum hız düşer BBS02B veya BBSHD Yokuş/kargo ağırlıklı için en güvenli başlangıç
38T Yokuş + şehir dengesi Denge iyi 36T kadar tırmanış avantajı yok BBS02B / BBSHD Günlük kullanım için çok iyi “orta yol”
40T Şehir + hafif yokuş Şehir hızlarında rahat Ağır yükte ısınma artabilir BBS02B Düz ağırlıklı rotalarda mantıklı
42T Genel kullanım (kitlerde yaygın) Parça bulunurluğu yüksek Uzun/dik yokuşta akım yükselir BBS02B / BBSHD Uzun yokuş varsa 36–38T daha sağlıklı
44T Hız odaklı şehir/banliyö Düzde daha yüksek hız Yokuşta zorlar BBSHD Kargo/yokuş ağırlıklı önerilmez
46T Maksimum hız odaklı Düzde en yüksek hız Yokuş verimsiz + ısı/akım artar BBSHD Fren/lastik/aktarma güçlü olmalı

4) Sürekli Güç & Isı (Pratik Derating)

Koşul Sürekli güç önerisi Akım davranışı Risk Pratik önlem
Düz yol, 20–30 km/h, iyi hava akımı Nominalin %80–100’ü mümkün Ortalama akım daha düşük Düşük Kadansı 80–100 rpm aralığında tut, uygun vites kullan
Uzun yokuş (6–10%), 10–18 km/h Nominalin %50–70’i Akım uzun süre yüksek kalır Orta 36–38T, düşük vites, dur-kalk azalt
Çok dik yokuş (>10%), düşük hız (<10 km/h) Nominalin %30–50’si Akım maksimuma yakın Yüksek Mola/soğut, daha küçük aynakol, mümkünse BBSHD + güçlü batarya
Kargo + yokuş (ağır yük) Nominalin %30–60’ı Voltaj sarkması olabilir Yüksek Yüksek BMS, kalın kablo, iyi fren/aktarma, 36T önerilir
Sıcak hava (30°C+), düşük hız Nominalin %30–60’ı Isı birikir Yüksek Aralıklı sürüş, gölgede soğut, kadansı yükselt

5) Elektrik & Güvenlik Önerileri

Bileşen BBS02B (25A) öneri BBSHD (30A) öneri Not
Ana besleme kablosu (batarya→motor) 12 AWG (min) 10 AWG (öneri) / 12 AWG (min) Kablo kısa olsun; 52V/uzun kablo/ısı için kalınlaştır
Konnektör XT60 (min) XT90 / XT90-S (öneri) XT90-S (anti-spark) kıvılcımı azaltır
Sigorta (batarya çıkışı) 35A (Blade/MIDI) 45A (Blade/MIDI) Bataryaya yakın konumda
BMS sürekli akım ≥30A (35A rahat) ≥40A (45A rahat) BMS “sürekli” akım kapasitesi kritik
Şarj 5A 5–8A Hızlı şarjda kablo/konnektör ısınmasını takip et

6) Senaryo Önerileri

Senaryo Motor Voltaj Aynakol (başlangıç) Batarya örneği Kritik not
Şehir içi, düz ağırlıklı BBS02B 48V 38–42T (min 36T) 48V 20–24Ah, BMS ≥30–35A Uzun yokuş varsa 36–38T daha iyi
Şehir + düzenli yokuş (6–10%) BBS02B / BBSHD 48V 36–38T 48V 24–28Ah, BMS ≥35–45A Isı yönetimi için küçük aynakol + uygun vites
Dağ/çok dik yokuş BBSHD 48V/52V 36T 52V 24–28Ah, BMS ≥45A Düşük hızda uzun süre tam akım ısınma yapar; mola/soğut
Kargo / ağır yük + yokuş BBSHD 48V 36T 48V 28Ah+, BMS ≥45A Fren/aktarma güçlendir; XT90-S önerilir
Banliyö / hız odaklı BBSHD 52V 40–46T (min 36T) 52V 24–28Ah, BMS ≥45A Fren ve lastik kalitesi çok önemli

7) Menzil Hesabı (İnteraktif)

Kural: Wh = V × Ah, Menzil (km) = Wh / (Wh/km)
Tipik tüketim aralıkları: Düz: 8–12 Wh/km Karma: 12–18 Wh/km Yokuş/Kargo: 18–28 Wh/km

Enerji (Wh)
—
Wh = V × Ah
Tahmini menzil (km)
—
km = Wh / (Wh/km)
Not
—
Sürüş tarzı/lastik/rüzgar/yokuş etkiler

Hızlı örnekler

Senaryo Örnek batarya Wh/km Menzil
Şehir düz 48V 20Ah (960Wh) 10 ≈ 96 km
Şehir karma 48V 24Ah (1152Wh) 15 ≈ 77 km
Yokuş/kargo 48V 28Ah (1344Wh) 22 ≈ 61 km
Hız odaklı 52V 24Ah (1248Wh) 18 ≈ 69 km

Bu örnekler “yaklaşık”tır. Yüksek hız + rüzgar + düşük lastik basıncı tüketimi hızlı yükseltir.

14 Eylül 2025 Pazar

🚴 Yeni Başlayanlar İçin Elektrikli Bisiklet Yapım Kılavuzu (2025) - Beginner’s Guide to Building an Electric Bike (2025) 🚴

🚴 Yeni Başlayanlar İçin Elektrikli Bisiklet Yapım Kılavuzu (2025)

🚴 Yeni Başlayanlar İçin Elektrikli Bisiklet Yapım Kılavuzu (2025)

Yaklaşık iki yıllık elektrikli bisiklet yapım tecrübemle, yeni başlayanların en sık yaptığı hataları ve dikkat edilmesi gereken noktaları paylaşmak istiyorum. Amaç, yanlış seçimler yüzünden gereksiz masraf ve zaman kayıplarını önlemek.

1. Kadro Seçimi

  • Disk frenle uyumlu olmalı
  • Orta kısımda motor ve pil için boşluk olmalı
  • Çelik veya sağlam alaşım kadro daha dayanıklıdır

2. Motor Seçimi

Kullanım Alanı Motor Gücü Not
Şehir içi, düz yollar 250W – 500W Türkiye'de yasal sınır 250W / 25 km/s
Hafif yokuş, uzun turlar 500W – 750W Orta seviye kullanım
Dik yokuş, dağlık alanlar 750W – 1000W Örn: Bafang BBSHD 1000W

3. Pil Seçimi

Motor Gücü Minimum Pil İdeal Pil Not
250W 250W 400W Şehir içi için yeterli
500W 500W 800W Uzun menzil avantajlı
1000W 1000W 1500–1700W BBSHD kısa süreli 1764W çekebilir
Kaliteli hücreler: Samsung, LG, Panasonic
Voltaj: 48V yaygın, 52V daha verimli ama şarj cihazı uyumluluğunu kontrol edin

4. Jant ve Göbek

  • 36 delikli göbek ve sağlam telleri kullanın
  • Normal bisiklet telleri kolay kırılır
  • Arka göbek dayanıklı olmalı

5. Lastik Seçimi

Lastik Türü Hız Sınırı Uygunluk
Normal bisiklet lastiği 25 km/h ❌ Güvenli değil
E-Bike lastiği (E25) 25 km/h ✅ Şehir içi
E-Bike lastiği (E50) 50 km/h ✅ Uzun mesafe, yüksek hız

6. Güvenlik

  • Korna: Trafikte şart
  • Ayna: Motosiklet aynası uyarlanabilir
  • Aydınlatma: Ön/arka LED far
  • Frenler: 500W+ için hidrolik disk fren
  • Koruma: Kask, eldiven, dizlik

7. Yedek Parça ve Bakım

  • Zincir, dişliler, fren balataları hızlı aşınır
  • E-bike uyumlu zincir kullanın
  • Düzenli bakım yapın
Sonuç: Elektrikli bisiklet yapmak keyifli ama dikkat isteyen bir iş. Yanlış parçalar hem güvenliği hem de bütçenizi olumsuz etkiler.
👉 En önemli tavsiyem: Ucuza kaçmayın. Kaliteli parçalar daha pahalı olabilir ama uzun vadede daha güvenli ve ekonomik olacaktır.

🚴 Beginner's Guide to Building an Electric Bike (2025)

With about two years of experience in building electric bikes, I want to share the most common mistakes beginners make and the key points to consider. The goal is to avoid unnecessary costs and wasted time due to wrong choices.

1. Frame Selection

  • Must be compatible with disc brakes
  • Should have enough space for motor and battery
  • Steel or strong alloy frames are more durable

2. Motor Choice

Usage Area Motor Power Notes
City rides, flat roads 250W – 500W Legal limit in Turkey is 250W / 25 km/h
Light hills, long rides 500W – 750W Mid-level usage
Steep hills, mountains 750W – 1000W Example: Bafang BBSHD 1000W

3. Battery Selection

Motor Power Minimum Battery Ideal Battery Notes
250W 250W 400W Enough for city use
500W 500W 800W Good for longer range
1000W 1000W 1500–1700W BBSHD can pull up to 1764W
Quality cells: Samsung, LG, Panasonic
Voltage: 48V is common, 52V is more efficient but check charger compatibility

4. Rims & Hubs

  • Use 36-hole hubs and strong spokes
  • Regular spokes break easily
  • Rear hub must be durable

5. Tires

Tire Type Speed Rating Suitability
Regular bicycle tire 25 km/h ❌ Not safe
E-Bike tire (E25) 25 km/h ✅ City rides
E-Bike tire (E50) 50 km/h ✅ Long distance, higher speed

6. Safety

  • Horn: Essential in traffic
  • Mirrors: Motorcycle mirrors can be adapted
  • Lights: Front and rear LED lights
  • Brakes: Hydraulic disc brakes for 500W+
  • Protection: Helmet, gloves, knee pads

7. Spare Parts & Maintenance

  • Chains, cogs, brake pads wear out fast
  • Use e-bike compatible chains
  • Perform regular maintenance
Conclusion: Building an e-bike is fun but requires attention. Wrong parts can hurt both your safety and your budget.
👉 My main advice: Don't go cheap. Good components may cost more, but they are safer and more economical in the long run.

taşınabilir bilgisayarda Fedora 44 üzerinde intel gpu + nvidia 4060 kullanımının yapılandırılması

Intel ve NVIDIA kartı birlikte olan bir laptopta, Fedora 44 ve MATE masaüstü ile üç sorunla karşılaştım: Harici monitör ile laptop e...