Fedora 35 VirtualBox 6.1.30

Red Hat, Fedora, CentOS

Üdv,

Fc35-ben a VirtualBox-nak kernel modul gondja van.

A modulok megvannak: /lib/modules/5.15.10-200.fc35.x86_64/extra/VirtualBox

vboxdrv.ko

vboxnetadp.ko

vboxnetflt.ko

 

systemctl status vboxdrv
fedora-nb systemd[1]: Starting Linux kernel module init script...
fedora-nb modprobe[13349]: modprobe: FATAL: Module vboxdrv not found in directory /lib/modules/5.15.10-200.fc35.x86_64
fedora-nb systemd[1]: vboxdrv.service: Main process exited, code=exited, status=1/FAILURE
fedora-nb systemd[1]: vboxdrv.service: Failed with result 'exit-code'.
fedora-nb systemd[1]: Failed to start Linux kernel module init script.

Mi hiányzik neki?

( dejo v | 2021. 12. 23., cs – 15:19 )

Amióta Fedorat használok, nem használok Virtualboxot.
Az Oracle nem készül el vele addigra mire 9 havonta kijön az új Fedora.
Próbáld ki helyette a "Virtual Machine Manager"-t. Nekem bejött.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Hogy érted, hogy nem készül el vele:

 

VirtualBox-6.1.30-1.fc35.x86_64
virtualbox-guest-additions-6.1.30-1.fc35.x86_64
kmod-VirtualBox-6.1.30-1.fc35.x86_64
kmod-VirtualBox-5.15.7-200.fc35.x86_64-6.1.30-1.fc35.x86_64
kmod-VirtualBox-5.15.8-200.fc35.x86_64-6.1.30-1.fc35.x86_64
kmod-VirtualBox-5.15.10-200.fc35.x86_64-6.1.30-1.fc35.x86_64
akmod-VirtualBox-6.1.30-1.fc35.x86_64
VirtualBox-server-6.1.30-1.fc35.x86_64

 

Ezek a csomagok nekem elég elkészültnek tűnnek :D

Nem azt mondom, hogy a release napján van package de 1-2 nap és megjön.

Fedora 38, Thinkpad x280

Egyetértek. Alap igényekre a virt-manager jobb, az a kernelben lévő KVM-et használja, és erőforrás-felhasználásban is jobb, kisebb az overheadje. Nem kell hozzá mindenféle kernelmodul minden kernelfrissülés után, meg nincs az, hogy az Oracle-re kell várni, mire beéri az új kerneleket a VB verziókkal, szerintem a cég is innen kapta a nevét, hogy Órák Köl-lennek nekik heteken át, mire jön ki új verzió. Főleg rollingon (Arch, Fedora, stb.) kínos, Ubuntun meg a többi szerencsétlenségen lehet fel se tűnik, ott vissza vannak tartva a verziók. Egyébként a VB se rossz, de hát ez a cseszekedés van vele. Így én régen qemu-t használtam KVM-mel, újabban virt-managert, és másnak is ezt ajánlom. Mármint alap virtualizácóra, otthonra, meg egyszerű fejlesztésekre. Céges monstrumokhoz lehet jobb más, Xen, meg VMware.

Az a baj, hogy sokan ragaszkodnak a VB-hoz, mert Windowson és Mac-en azt szokták meg. Azokon kell is VB, VMware, mert vagy nincs beépítve az OS-be hypervisor, vagy van (Windows Pro és Server verziók), csak gyopár, minden oltári lassan fut benne, és akkor a MS csodálkozik, hogy szerveren miért használ mindenki, még a windowsos cégek is Linuxot. Linuxon viszont nem kell a VB-hoz ragaszkodni.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az lehet ugyanazt hívja meg, csak a felülete más. Régen a qemu-t én paraméterztem fel kézzel, scriptből, shellből, ma meg a virt-manager kényelmesebb. Onnan nem voltam biztos benne, hogy egy a kettő, hogy a virt-manager a qemu-t nem húzza be függőségként, de a libvirt-et igen, ami viszont lehet qemu-alapú.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Linuxon viszont nem kell a VB-hoz ragaszkodni.

Mondjuk, hogy desktopon szereten mert jóval kényelmesebb, mint a szerver környezetbe kitalált, virt-manager/kvm stb. Hát igen cserébe néha van vele szarakodás. Az élet ilyen, valamit valamiért ...

Fedora 38, Thinkpad x280

( dejo v | 2021. 12. 23., cs – 15:53 )

Szerkesztve: 2021. 12. 23., cs – 15:55

Én a Fedora 32-vel kezdtem el Fedorat használni.
Akkor nem volt Virtualbox Fedora 32-re. A legutolsó RPM-es meg nem ment rajta. Aztán a Fedora 33-nál ugyanígy jártam. Sőt amikor visszanéztem, hogy mely kiadásokhoz van Virtualbox, voltak lyukak.
Kipróbáltam a Virtual Machine Manager-t és nekem megfelel. Még örülök is, hogy ennyivel is kevesebb közöm van az Oracle-höz. :)

(Ez _ventura_-nak leenne a válaszom, csak ide sikerült.)

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( makgab v | 2021. 12. 23., cs – 22:18 )

Olvastam a neten, hogy az UEFI Secure Boot miatt lehet, hogy nem tudja betölteni a modult. Nincs Secure Boot bekapcsolva.

Van ötlete valakinek?

Nem hinném. Mi kényelmetlen azon, hogy van egy GUI-s Virtual Machine Manager, azon nyomok egy play gombot, elindul a virtuális gép. Ha rákattintok az Open-re, akkor ott a grafikus felülete, ha nem, akkor ssh-zok a virtuális gépre, s használom konzolon. Akkor sem dől össze, ha véletlenül bezárom a Virtual Machine Manager-t, azt újraindítva a már futó virtuális gépet tudom kezelni. A grafikus megjelenítés is olyan, mintha bedugnék, vagy kihúznék egy monitort, az is bezárható, újra megnyitható futó virtuális gépnél, attól még az fut tovább.

Használtam VirtualBox-ot, és semmiben sem kellemetlenebb számomra a qemu-kvm, van nagyon jól használható kattintgatós GUI hozzá. Még távolról is használtam ssh tunnelingen átadott X protokollon, de egyébként lehetett volna távolról natívan is használni, mert azt is tudja, hogy localhost-on megy a Virtual Machine Manager, remote pedig a virtuális gép.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Fogalmam sincs, nem volt ilyen igényem. Nem értek a hálózathoz, de gondolom, létre lehet hozni egy virtuális hálózati eszközt, s a host-on kell megmondani, hova csatlakozzon az. A virtuális hálózati eszközhöz pedig statikusan csatlakozik a virtuális gép. De ez csak egy érzés, fogalmam sincs.

Én virtuális gépet arra használok, hogy forráskódból lefordítok valamit - jellemzően pipewire-t húzom ki git repóból -, a rakás devel csomag fenn van a virtuális gépen, lefordítom a forrást, elkészíti az rpm csomagokat, visszamásolom a host-ra, feltelepítem. A virtuális gép GUI-ját nem is használom, csak ssh-zok rá.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Használtam ezt a repot nagyon sokáig, kernel frissítésnél a DKMS miatt az új kernelhez is befordult a modul, 1-2x ez elmaradt de akkor 1 parancs volt meg akkor meg kellett várni hogy leforogjon ennyi. Sose volt semmilyen gondom vele.

A fenti hátrányért kárpótolt, hogy nem kellett napokat várni, amíg a distro szállítótta az aktuális verziót, feltéve ha egyáltalán szállította ...

Fedora 38, Thinkpad x280

Én már elkényelmesedtem. Nem használok külsős kernel modult. Virtualizációnak ott van a qemu-kvm virtmanagerrel, minden működik jól, egyedül pipewire-t szoktam néha forrásból fordítani git repóból, de abból is rpm csomagot csinálok, feltelepítem, használom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

minden működik jól

Mint fentebb említettem hát nem minden működik jól, amire nagyvonalúan beírtad, hogy szubjektív.

Valakinek nagyobbak at igényei egy VM indításnál, és egy VM shutdownnál ...

Fedora 38, Thinkpad x280

Mármint nyilván az igényeimnek. Természetesen még sohasem sikerült Fedorát telepítenem egy PIC16 architektúrára, mert nem támogatott, meg mert cseppet kevés az a néhány tíz, néhány száz byte RAM, az egyetlen CPU mag mondjuk 4 MHz-ről, és így tovább. Jó, szélsőséges, de azt akarom vele mondani, hogy nekem jó, amire kell, és arról sem vagyok meggyőződve, hogy megoldhatatlan, ami az igényed, csak lehet, nem úgy kell megoldani, ahogy megszoktad. Nem tudom.

VM indítás és shutdown között van az a rész, amikor kihúzom a git repóból a forrást, összetömörítem, lefordítom, majd ssh-n keresztül visszamásolom a host-ra. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem azt mondtam, hogy megoldhatatlan, hanem, hogy a virtualboxhoz képest kényelmetlen/körülményes. És nem csak a network váltás, hanem pl egy shared folder is. Ha jól tudom osztott vágólap már van.

Volt időszak mikor virt-managerrel próbálkoztam, a virtualbox helyett, de inkább visszaálltam rá (igaz akkor még osztott vágólap se volt).

Desktopon szerintem jobb/kényelmesebb.

Fedora 38, Thinkpad x280

Nekem desktopon kényelmesebb 2 mappát nautilussal mondjuk drag/drop kezelni , mint ssh/mc stb vel  -n keresztül másolgatni.

Valamit pl.: bőngészőben letöltök, rögtön az osztott mappába akkor az már a VM-ben használható rögtön, nem kell még "másolgatnom".

Vagy teszem azt mi van akkor ha 3 VM között kell megosztanom a mappát ? Akkor mind a 3 ra másolgassam ssh -val ? 

Fedora 38, Thinkpad x280

a virtualboxhoz képest kényelmetlen/körülményes. És nem csak a network váltás, hanem pl egy shared folder is.

Inkább azt mondanám, hogy más. Aki tudja, hogy mit miért csinál, annak ez nem annyira komoly probléma. Aki nem hozzáértő, aki nem mélyed el egy kicsit benne, annak a Virtualbox is, a VMware is űrtudomány.

A virt-managernél hozzá kell adni a VM-hez egy új hardvert, ami történetesen egy fájlrendszer, majd kell a Linux VM-ben egy mount parancs, és készen vagy (illetve jobb, ha mindjárt felveszed az fstabba). Windows VM-nél kicsit macerásabb (jó, nem kicsit), ahhoz kell a hoston még ez a kettő: cockpit és cockpit-machines, kell itt is egy új hardvert felvenni (ez egy channel device), még Windowson is kell ezt-azt kattintgatni, de megoldható :) Ha sok Windows VM-ed van, akkor ez tud bosszantó lenni, az igaz.

 

osztott vágólap már van

Van. Linux guest esetén egy dolgot kell utólag telepíteni ehhez (ez a spice-vdagent). Windows guesten a spice-guest-tools telepítése szükséges még.

Igen, van, de ehhez előbb létre kell hozni a hoston egy bridge kapcsolatot, abban létrejön egy bridge csatoló; a meglévő ethernet kapcsolatot törölni kell, majd a bridge csatolóhoz hozzá kell rendelni az ethernet csatolót. Ekkor a host ethernet adaptere helyett a bridge adapter fog IP-címet kapni (tételezzük fel, hogy DHCP-t használsz). A VM hálózati adapterénél utána csak annyit kell tenni, hogy a "Hálózat forrása" résznél az alapértelmezett "Átirányítás" (vagyis NAT) helyett azt kell választani, hogy "Adja meg a megosztott eszköz nevét", majd a "Hálózati híd neve" részhez be kell írni a bridge csatoló nevét (ami pl. alapesetben nm-bridge lesz, ha nmtui-val hoztad létre). Ilyenkor a VM leállítása és újraindítása nélkül alkalmazkodni fog a VM az új helyzethez, vagyis ugyanabból az alhálózatból fog IP-címet kapni, mint amiből a host kapott. Visszafelé váltásnál ugyanez az eljárás a VM hálózati csatolójának beállításánál, egyszerűen visszaállítod a NAT-ot, és pár pillanat múlva máris a KVM által NAT-olt hálózatból lesz IP-címe a VM-nek.

Wifi esetében ez a megoldás nem jó, és igazából nekem amúgy sem lenne jó, mert többször van olyanra szükségem, hogy egy VM-ben tudjak futtatni olyan alkalmazásokat, amik wifin dolgoznak. Ehhez van egy USB/wifi adapterem, amivel átvágható a gordiuszi csomó :)

Persze USB/ethernet adaptert is lehet használni, néha az is jól jön, azzal is egyszerűbb lehet az élet, és van, amikor egyetlen ethernet port amúgy sem elég.

Nem külső repót használt, hanem letöltött egy szoftver oldaláról egy fedora33/34-re forgatott binárist a Fedora35-höz, azt telepítette fel. Nincs szó külső repóról, ha használná az még a szerencsésebb eset lenne, de nem ezt írta. Szóval a csomagkezelő keresztbe van pisálva. Windows like szoftvertelepítés, letöltöm valahonnan, felrakom oszt jónapot.

Másik, hogy oké, ajánl egy repót is az oracle, de az abban lévő csomag betartja-e a Fedora szabványokat, vagy legalább figyel-e arra, hogy az /opt-ba települjön, de milyen függőségekkel lett lefordítva, lekezelik-e ha a Fedorában verziót ugrik egy függőség, nem csak a kernel a lényeg. Furcsa, hogy fedora33 tag van a csomagnévben... milyen környezetben buildelnek egyáltalán?

Értem, hogy örülünk Vincent, mert _most_ működik, a fedora tárolókban lévő meg nem, de biztos lett jelezve a Fedora teamnek, hogy baj van a repoban lévő csomaggal...

Még mindig nem értem miért van keresztbe pisálva a csomagkezelő :D

Fedorán RPM a csomagkezelő (legalsó szint), amire ha felrakok rpm -ivh vagy rpm -Uvh -val egy csomagot, attól az miért lesz keresztbepisálva ? Bármikor lekérdezhetem rpm paranccsal, bármikor leszedhetem vele stb.

Fedora 38, Thinkpad x280

Jó. Letöltöm a Fedora35-re a oracle honlapjáról a fedora33/34 binárist. Felhajítom rpm-el. Tudni fogja a rendszer mik a függőségei? Ha frissül valami, tudni fogja a rendszer hogy kéne frissülnie az oracle csomagnak is, vagy szólni fog, hogy ne távolítsak már el egy csomagot, mert ez amúgy kéne az oracle csomagnak? 

Csomagkezelő nem annyi, hogy feltelepíti, meg eltávolítja a csomagot. Jól van, ez lehet az én hülyeségem, de én nem akarok a rendszeremen semmi potyázó csomagot. Tudom lehet így is, meg működhet is, legfeljebb frissítéskor le kell tölteni egy másik binárist, stb. Én viszont sosem hagynám el a csomagkezelő által biztosított rendet és biztonságot ;) Meg vakarnám a fejem 3,56 hónap múlva, hogy ez a szar meg miért nem műxik, vagy miért rinyál a csomagkezelő, hogy már van ilyen fájl a fájlrendszerben stb. Na meg egy oracle/random helyről beszerzett csomagolt binárist telepítsek... Eleve az a csomag kívül esik a security team látókörén is. Nem tudom, én nem tenném. 

Ehhez csak azt teszem hozzá, hogy én például a Brave browser-ból meg az Opera browser-ból  a saját maguk által kiadott rpm-eket használom, az ő repojuk van beállítva, onnan frissül. Böngészőnél nekem fontos a frissesség, nem akarok a disztró-karbantartókra várni. Tökélestesen működik.

(A Mozillát viszont töketlennek tartom, hogy nem adnak ki saját csomagot, úgy mint a többiek.)

Meg vakarnám a fejem 3,56 hónap múlva, hogy ez a szar meg miért nem műxik, vagy miért rinyál a csomagkezelő, hogy már van ilyen fájl a fájlrendszerben stb.

Elviekben teljesen megértem az álláspontod, de ha már security-ről beszélünk, meg rendről, akkor nincs olyan, hogy random elbaszódik valami. Ha ilyen kontrollra van szükség, akkor legyen patch management, ne az "apt-get upgrade -y" kezelje a konfigurációdat. ;)

Az elbaszódást arra értettem, hogy ugye van csomag felrakva innen-onnan letöltve, a rendszer meg közben frissül a repókból és eltörik az innen-onnan csomag,  amiről a rendszer nem tudhat, vagy ha ráadásul szarul is van összerakva, a fájlrendszerben okoz gebaszt, hogy egy disztró csomag is hozna fájlt, amit a külsős szar már lepakolt. Ilyesmire gondoltam.