Vazne by me zajimalo, jak tvurci fedory vedi, ze mam doma 2 GPU a jednu mam zakazanou v linuxu a pass tru do virtualu v KVM ? - a vedi ze jim to nefunguje, takze krom konfigu se jeste musi dodat script, ktery manualne zakaze za pomoci echo nekde do proc nebo sys, nebot ac mam konfik pro modul v poradku, nefunguje to, ale i kdyby to fungovalo - ten konfig musi byt v init.ramdisku
#/etc/modprobe.d/vfio.conf
# GPU isolation
#install vfio-pci /usr/sbin/vfio-pci-override.sh
options vfio-pci ids=10de:1380,10de:0fbc
options vfio-pci disable_vga=1
!/bin/sh
PREREQS=""
DEVS="0000:1d:00.0 0000:1d:00.1"
for DEV in $DEVS; do
echo "vfio-pci" > /sys/bus/pci/devices/$DEV/driver_override
done
#
modprobe -i vfio-pci
A co se stane, kdyz to nebude v initram ? - no nacte se nvidia driver a uz tu kartu nepusti ;-) a ten noveau je jeste horsi, ten ma zakazany samozrejme taky, ten dela jeste vetsi bordel.
Takze dlasi vec, co chyrtre hlavy vymyslely a doufam ze to pujde zakazat.
Je to jako upgrade fedory na novou versi, ktery je ale zcela ale zcela nefunkcni, pokud tam ma clovek nejkake dalsi veci, velkou cast to resi uz v predchozi fazi, odisntsaluji kde co, neco natvrdo prepisu, ale spise odeberu a pak pridam, nebo uz to fakt neni potreba - ale pak se tam i pres vesketer testy objevi nejaka chyba, tu samozrejme nikam nenapise, v journal logu se jen clovek dozvi, ze to spadlo - a tak se musi rucne upravit v systemd upgradovaci script, kde se rekne, preskoc chyby - a ono se to upgraduje (jo asi mu vadi, ze mam nejake baliky zakazane, ale aplikacni, ne systemove, obcas i jine veci) - jo fresh fedora kde mam jen pridane doporucene repozitare jede, ale proc se to sakra nezepta a nebo to tam nemaji default ? - ono upgrade spadne v tichosti se rebootuje jako by nic. Vazne by me zajimalo, cim tak asi premysli? - proc resi par sekund generovani initramadisku - ktery je na miru a maly, misto toho daji nefunkcni bazmek, ktery bude uber velky
Mozna by nebylo spatne zkusit si najit o chystane zmene vice informaci pred sepisovanim rozsahlych rantu. Odkaz na podrobny navrh zmeny dokonce je v clanku.
Presto zkusim odpovedet na dve hlavni otazky, ktere si myslim, ze Vas tizi.
Q1: "proc resi par sekund generovani initramadisku - ktery je na miru a maly, misto toho daji nefunkcni bazmek, ktery bude uber velky"
A1: Smyslem jednotnych initrd obrazu neni ani tak usetrit cas jeho (ne)generovanim. Ale kdyz bude na vsech strojich stejny obraz, bude mnohem jednodussi identifikovat a ladit problemy s nim spojene. Eliminuji se problemy zpusobene chybou pri jeho generovani. A umozni se bezpecne podepisovani celeho obrazu.
Q2: "Takze dlasi vec, co chyrtre hlavy vymyslely a doufam ze to pujde zakazat."
A2: Ano. V prvni fazi pujde o opt-in funkci, ktera teprve umozni cely proces rozvijet.
initrmadisk podruhe:
Prechazel jsem z NASu z AMD64 na intel-xeon - HPE microserver - prehodil jsem HDDs a linux samozrejme nenabootoval, nebot initramdisk nemel radice, ani USB a logicky nenasel system - stacilo systemrescuecd (nebot to od RHE/FC je opravdu ale opravdu k nicemu) a ten umi nabootuj s mim kernelem stavajici system - heureka, pak stacilo pregenerovat image a bylo to. - novy server uz nemel 5x SATA, ale jen 4 - takze system sel na USB - jako jo, zde by mega nabobtnaly init.ramdisk pomohl, ale
Takze FC chce usetrit par sekund az minut pri upgrade kernelu a generovani initramdisku, zato brutalne zpomali kazdy start a bude tam davat kupu obezlicek a kde co, co nefunguje na te a te platfortme, ta se podivaji, jak dlouho se natahuje systemrescuecd, navrch tam maji vice kernelu a moznosti, nebot ne vse musi fungovat s danym HW, ale modul tam bude a asi ani nebude disabled
Coz dneska resi prave ten slavny dracut, hezky si vezme lspci, lsusb, zjisti cpu atd. a casto disabluje moduly, co vi, ze tam nefunguji a hlavne, natahne tam jen to, co musi a nenatahuje tam moduly, na ktere clovek nema HW - ano plno veci se natahuje az v systemu (z mnoha duvodu, treba ze to chce jeste firmware atd.)