Portál AbcLinuxu, 6. května 2025 16:22
Tohle vlákno navazuje na tohle.
1.) Zkontroluj jestli máš nainstalovaný balíček ovmf.
2.) Zjisti kde se ti nainstalovaly soubory OVMF_CODE.fd a OVMF_VARS.fd (někdy mají také příponu .*bin). Bude to v adresáři /usr/share/.
3.) Klidně to nech zakomentované a nakonec souboru qemu.conf vlož nvram = [ "/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd", ]. Správné cesty k OVMF_CODE.fd a k OVMF_VARS.fd vlož tu z bodu 2.
Nepomohlo mi to. Když po tom všem ve virt-manageru přepnu z "BIOS" na "UEFI" a je tam i vidět ta nastavená cesta, tak po kliknutí na "Použít" se to vrátí zpět na BIOS.
K bodu 1:
~$ apt install ovmf Načítají se seznamy balíků… Hotovo Vytváří se strom závislostí Načítají se stavové informace… Hotovo ovmf je již nejnovější verze (0~20180205.c0d9813c-2ubuntu0.1). 0 aktualizováno, 0 nově instalováno, 0 k odstranění a 0 neaktualizováno.
K bodu 2:
~$ ls /usr/share/OVMF/ OVMF_CODE.fd OVMF_VARS.fd
K bodu 3:
sudo nano /etc/libvirt/qemu.conf # Na konec souboru qemu.conf přidáno: nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd", ]
Pak jsem v terminálu dal apt install qemu, abych se podíval, jakou verzi mám nainstalovanou. K mému překvapení na mě vyjelo tohle:
~$ apt install qemu Načítají se seznamy balíků… Hotovo Vytváří se strom závislostí Načítají se stavové informace… Hotovo Následující dodatečné balíky budou instalovány: qemu-slof qemu-system qemu-system-arm qemu-system-mips qemu-system-misc qemu-system-ppc qemu-system-s390x qemu-system-sparc qemu-user Navrhované balíky: qemu-user-static vde2 qemu-efi openbios-ppc openhackware openbios-sparc Doporučované balíky: qemu-user-binfmt Následující NOVÉ balíky budou nainstalovány: qemu qemu-slof qemu-system qemu-system-arm qemu-system-mips qemu-system-misc qemu-system-ppc qemu-system-s390x qemu-system-sparc qemu-user 0 aktualizováno, 10 nově instalováno, 0 k odstranění a 0 neaktualizováno. Nutno stáhnout 48,6 MB archivů. Po této operaci bude na disku použito dalších 283 MB. Chcete pokračovat? [Y/n]
A když dám apt install qemu a 2x Tab, tak:
qemu qemu-efi-arm qemu-system-common qemu-system-x86 qemu-block-extra qemu-guest-agent qemu-system-mips qemu-user qemubuilder qemu-kvm qemu-system-misc qemu-user-binfmt qemuctl qemu-slof qemu-system-ppc qemu-user-static qemu-efi qemu-system qemu-system-sparc qemu-utils qemu-efi-aarch64 qemu-system-arm qemu-system-s390x
Jsem si říkal, že bych si nainstaloval nejnovější verzi QEMU, ale nevím jak postupovat, abych si to neponičil. Z repozitáře bych měl mít verzi 2.x.
Řešení dotazu:
Hostitelský systém je GNU/Linux Mint 19.3 Cinnamon amd64.
<os>
<type arch="x86_64" machine="q35">hvm</type>
- vlož řádek:
<loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
Takže celý ten blok <os> bude vypadat nějak takto https://gist.github.com/whophil/ba71d0d8f5a62eda5a632bf9a0b328fc
Tag "<nvram>" se ti tam přidá až po kliknutí na "Začít instalaci".
Když jsem tam ten řádek chtěl vložit, tak už tam byl. Prostě se to chová tak, že z BIOS přepneš na UEFI, potvrdíš a to tlačítko se zase vrátí na BIOS, ale v XML je to správně.
Přikládám konfiguraci před instalací. Je to dobře, nebo bys něco zlepšil?
Kliknu na instalovat a kousne se to viz. přiložený obrázek.
Přiložil jsem špatný soubor. Správný je tento.
Obrázek znovu.
Nemá GPT. Ani se jej ale nesnažím předělat na UEFI. Ten první obrázek je pořízený při spuštění nové instalace VM Windows (Q35). Prostě nevím co mám udělat, aby se instalace spustila. Vždy se to sekne na tomhle, ať dělám co dělám.
Když po tom všem ve virt-manageru přepnu z "BIOS" na "UEFI" a je tam i vidět ta nastavená cesta, tak po kliknutí na "Použít" se to vrátí zpět na BIOS.Sa nejako neguje s tvrdením:
Ani se jej ale nesnažím předělat na UEFI.Poprosím o laický opis čo sa má dosiahnuť.
Neneguje. Po tom všem = po provedení bodu 1 a 2. Kdybys klikl na odkaz nahoře, tak by tě přesměroval do jiného vlákna. Tam by ses taky posunul kousek nahoru a z textu bys pochopil, že jde o novou instalaci. Na tom ale nezáleží. Prostě se snažím vytvořit nový VM Windows s UEFI (Q35) a nejde mi to. Potřebuji poradit, jak se dostanu přes tu obrazovku a taky schválit konfiguraci VM před instalací. To je vše. Dělám to proto, protože mám naději, že mi tam bude fungovat ta externí USB zvukovka a to by mi v podstatě vyřešilo to přepínání mezi sluchátky a bednami.
Odpověděl jsem špatně. Zamysli se nad tímto.
virt-install --virt-type kvm --name delete --ram 8048 --vcpus=1 --livecd --cdrom /home/golisp/VM/ubuntu-19.10-desktop-amd64.iso --os-variant win7 --boot uefi --machine q35 --disk size=10,bus=sataA hlavne si skontroluj či máš inštalačné médium ktoré je schopné štartu v UEFI móde. To môže byť hlavný zádrhel.
Díky, už to mám.
Už instaluji. Taky mi to došlo. Jsem fakt zvědavý, jestli pojedu ta zvukovka.
EDIT: pojede
Děs a hrůza. Je to ještě horší, než s i440FX. Obě dvě zvukovky hrají mnohem hůře. Tedy zatím jsem to nezkoušel s AC97. Tam předpokládám, že default zvukovka bude hrát dobře, ale mě šlo hlavně o tu externí a tam nepomůže asi nic. Asi ještě jednou zkusím VB.
Myslíš, že má cenu zabývat se instalací nejnovější verze QEMU? Mohlo by to pomoci?
Myslíš, že má cenu zabývat se instalací nejnovější verze QEMU? Mohlo by to pomoci?Pochybuji, že to problém s USB zvukovkou vyřeší, ale zkusit to můžeš. Možná, že nepomůže jiná verze, ale aby bylo Qemu zkompilované s jinými parametry, takže pokud máš na Mintu možnost nějakých uživatelských repozitářů, tak by sis nic rozbít neměl. Když tak to zase odinstaluješ a naisntaluješ současnou verzi Qemu. https://www.reddit.com/r/VFIO/comments/8hg0ac/crackling_audio_for_win10_guest_on_arch_linux_host/ Pokud alespoň trochu vládneš angličtinou, tak to zkus projít. Jsou tam stručně vyjmenované asi všechny možnosti řešení. Bohužel tazateli zřejmě nic z toho nepomohlo. Nezkoušel pouze dedikovanou PCIE sound card. Jeden člověk tam píše, že mu místo předání (passthrough) USB zvukovky do VM příkazem "<hostdev ...>" (to jsi zkušel i ty) pomohlo předání přes Spice. Když spustíš VM tak nahoře je Spice menu > Virtuální stroj > Přesměrované USB zařízení > vybereš USB zvukovku. To je předání USB jiným způsobem. Zkus to. Zřejmě ten problém způsobuje latence, která vzniká mezi hostitelem a hostem. Z jiné diskuze jsem pochopil, že máš monitor připojen přes HDMI a v monitoru reproduktory a při uspání ti to blbne. Jestli to s tím může souviset? Nebo se to možná liší podle toho co má kdo za kernel nebo OS nebo prostředí (DE) jakože v nějakém OS je spuštěných na pozadí více procesů s vyšší prioritou a ty mohou vstupovat "do práce" Qemu a tím vzniká latence. Těžko říct, nikdy jsem to takto do hloubky neřešil, protože mi pomohlo AC97 + alsa. Každopádně vždy jsem se v diskuzích setkal jen s praskajícím zvukem, to že tobě se u USB zvukovky zvuk úplně vypne nebo se sekne i video to je rarita. Chtělo by to nějak diagnostikovat jestli ti do chodu USB zvukovky nevstupuje nějaký proces nebo modul jádra (proto mě v té vedlejší diskuzi napadl nějaký modul/proces na šifrování disku) bohužel nevím jak to diagnostikovat. Snad někdo jiný kdo s tím má zkušenosti.
Víš, mě by ten AC97 stačil a tu USB zvukovku bych nepotřeboval. Jediné co mi vadí je, že jakmile se vypne monitor a pak jej probudím myší, tak mi nefungují bedny a musím je spouštět skriptem. Kdyby někdo věděl, jak nastavit, aby se ten skript spustil při probuzení monitoru, tak to by mi stačilo a nemusel bych do toho rýpat. Ještě je tedy otázka, co by se stalo, když bych pustil audio záznam a vypnul by se monitor? Asi by se to taky přeplo na HDMI (repráky v monitoru) a možná by bylo ticho. Ještě jsem to nezkoušel. Zkusím to.
... Jeden člověk tam píše, že mu místo předání (passthrough) USB zvukovky do VM příkazem "<hostdev ...>" (to jsi zkušel i ty) pomohlo předání přes Spice. Když spustíš VM tak nahoře je Spice menu > Virtuální stroj > Přesměrované USB zařízení > vybereš USB zvukovku. To je předání USB jiným způsobem. Zkus to.
To je ono. Teď to funguje perfektně. Zatím jen na tom prvním VM Windows i440FX, protože se zdá, že je potřeba hacknout VM tím AC97. Teď na to nemám čas, ale později to zkusím a pak o tom napíšu do toho vlákna o přepínání zvuku. V podstatě mi to vyřešilo vše. Mohl jsem vrátit zpět nastavení alsamixeru "Auto-Mute" na "Enabled" a taky ten konfigurák /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf jsem mohl vtátit do původního stavu, takže už se mi to nepřepíná na HDMI. Prostě to funguje přesně tak, jak jsem chtěl. Pak ještě zkusím upravit ten k3dARův skript, abych to mohl přepínat i klávesovou zkratkou a hotovo. Ještě doplním, že aby to fungovalo, tak nemůžeš udělat redirect. V momentě, kdy jej uděláš, tak už není ta zvukovka vidět v hostiteli v nastavení zvuku a nelze přepínat bedny/sluchátka. A ve VM je po kliknutí na ikonu hlasitosti na hlavním panelu jen AC97 a přepnout se taky nejde. Sluchátka pak nehrají. Takže redirect ne. Jen necháš zapojenou USB zvukovku v předním panelu a v ní headset. Pustíš VM a než naběhne, tak v hostiteli na hlavním panelu (později snad ta zkratka) nastavíš, jestli chceš bedny, nebo headset. Prostě pohodička
A ve VM ta sluchátka hrají super. Nezaznamenal jsem jediný problém. Tentokrát testuji na tomto - hodně dobrý
.
Díky za tvůj čas a přístup, LarryLe
Ještě jsem zapomněl zmínit, že nemusím používat VB, což je super.
Tak je to tak. Po nainstalování AC97 do VM Windows Q35 jede zvuk z té externí zvukovky krásně. Takže už jen pořešit ten skript no a ještě ty snapshoty, protože bez nich je to o ničem.
... Jeden člověk tam píše, že mu místo předání (passthrough) USB zvukovky do VM příkazem "<hostdev ...>" (to jsi zkušel i ty) pomohlo předání přes Spice. Když spustíš VM tak nahoře je Spice menu > Virtuální stroj > Přesměrované USB zařízení > vybereš USB zvukovku. To je předání USB jiným způsobem. Zkus to. To je ono.Když máš USB zvukovku předanou do VM pomocí "<hostdev ...>", tak se ti ve VM po pár sekundách zvuk vypl a když jsi to předal přes ten Spice redirect, tak USB zvukovka jede bez problémů? Chápu to správně?Teď to funguje perfektně.
Takže redirect ne.A nakonec jsi se rozhodl, že USB zvukovku nebudeš předávat do VM, ale ponecháš jsi ji v hostiteli (Mintu)? A tím skriptem budeš přepínat mezi integrovanou zvukovkou (reprobedny) a mezi USB zvukovkou (sluchátka)?
... Jeden člověk tam píše, že mu místo předání (passthrough) USB zvukovky do VM příkazem "<hostdev ...>" (to jsi zkušel i ty) pomohlo předání přes Spice. Když spustíš VM tak nahoře je Spice menu > Virtuální stroj > Přesměrované USB zařízení > vybereš USB zvukovku. To je předání USB jiným způsobem. Zkus to. To je ono.Když máš USB zvukovku předanou do VM pomocí "<hostdev ...>", tak se ti ve VM po pár sekundách zvuk vypl a když jsi to předal přes ten Spice redirect, tak USB zvukovka jede bez problémů? Chápu to správně?Teď to funguje perfektně.
Ne. Když zvukovku z hostitele předám VM, tak se zvuk sekne. Když udělám redirect, tak taky. Prostě jí ani nepředávám a ani nedělám redirect. Mám jí zapojenou v hostiteli (Mintu) a když spustím VM, tak v hostiteli na hlavním panelu, když chci ve VM zvuk ze sluchátek, přepnu z beden na sluchátka a v tu ránu jede ve VM zvuk ze sluchátek. Kdybych ale ve VM chtěl přepnout zvuk zpátky na bedny, tak zase v hostiteli kliknu na hlavním panelu na ikonu zvuku a přepnu z "Reproduktory USB Advenced Audio Device" zpátky na "Linkový výstup Vnitřní zvukový systém". To je celé.
Takže redirect ne.A nakonec jsi se rozhodl, že USB zvukovku nebudeš předávat do VM, ale ponecháš jsi ji v hostiteli (Mintu)? A tím skriptem budeš přepínat mezi integrovanou zvukovkou (reprobedny) a mezi USB zvukovkou (sluchátka)?
Až na to "Na konec" v podstatě ano. Asi to udělám hned a ještě sem napíšu.
Tak jsem upravil ten Radkův skript, ale nefunguje mi to.
Předtím jsem měl:
~$ sudo pactl list sinks | grep "Aktivní port:"| cut -d ' ' -f 3- analog-output-headphones analog-output-lineout
A teď mám:
~$ sudo pactl list sinks | grep "Aktivní port:"| cut -d ' ' -f 3- analog-output-speaker analog-output-lineout
Takže jsem to podle toho změnil v tom skriptu, ale nefunguje mi to. Možná je to tím, že se jedná o USB. Nevím. To nechám na Radka.
Koukal jsem do alsamixeru a toho skriptu a bude to tím, že v alsamixeru je ta USB zvukovka jako port 1, a ne port 0. Zkusím s tím něco udělat. Když tak mám Vás
# pactl set-sink-port 1 "analog-output-speaker" Spojení selhalo: Spojení odmítnuto pa_context_connect() selhalo: Spojení odmítnuto
Tak ten druhý výstup není "analog-output-speaker", jak jsem psal výše. Když jsem dal:
~$ sudo pactl list sinks | grep "Aktivní port:"| cut -d ' ' -f 3- analog-output-speaker analog-output-lineout
Tak jsem měl aktivní integrovanou zvukovku. Když jsem ale na hlavním panelu přepl na tu externí, tak to vypadalo takto:
~$ sudo pactl list sinks | grep "Aktivní port:"| cut -d ' ' -f 3- Home directory not accessible: Operace zamítnuta Spojení selhalo: Spojení odmítnuto pa_context_connect() selhalo: Spojení odmítnuto
Proč tam rveš sudo
Myslím, že jsem to napřed dělal bez sudo. Když jsem ale zpátky dostal:
Home directory not accessible: Operace zamítnuta Spojení selhalo: Spojení odmítnuto pa_context_connect() selhalo: Spojení odmítnuto
tak jsem to zkusil ještě se sudo. Tím nic nepokazíš, ne? Někdy předem nevím, jestli sudo použít, nebo ne. Např. u některých parametrů pro inxi to píše, že výpis je omezený kvůli absenci sudo. A u některých zase sudo nepotřebuješ. Takže já dávám sudo raději pořád a nemám problém. Znám člověka, který v terminálu dělá jenom jako root#, takže to sudo asi nevadí, ne?
Jdu založit nový dotaz. Admini ze mě budou na prášky.
Takže já dávám sudo raději pořád a nemám problém.Myslím, že podstatná většina zdejšího osazenstva se právě hrůzou zhroutila
Proč?
Co se týká bezpečnosti, tak mám spoustu otázek. Už nějaký čas v sobě živím myšlenku, že se tady na to na vše zeptám. Až dořeším tu virtualizaci, tak to udělám.
Už nějaký čas v sobě živím myšlenku, že se tady na to na vše zeptám.Když v poradně budeš chtít pomoct se scriptem na přepínání zvukovek, tak z tebe admini na prášky nebudou, ale pokud by ses ptal na takové základy, tak by asi nadšení nebyli. Stačí když do google napíšeš "proč nepoužívat sudo" nebo podobné spojení a najdeš dost článků i v češtině.
Dobře.
Používám Duckduckgo. Můžeš se podívat, co mi najde na dotaz "proč nepoužívat sudo". Zkoušel jsem to i bez úvozovek, nebo title:..., jiná podobná spojení a nic
Why not use sudo: tady už je možná zajímavý ten 4 výsledek linux - Why should one use sudo?, ale moc výsledků to tedy nanachází.
Ono i umět hledat je umění a bez angličtiny je to docela o ničem. Kolikrát ani nevím, jak se zeptat.
Zřejmě ten problém způsobuje latence, která vzniká mezi hostitelem a hostem.
Na https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6/ je mimo jiné:
Build for amd64 succeeded (see BUILD.LOG.amd64): linux-headers-5.6.0-050600_5.6.0-050600.202003292333_all.deb linux-headers-5.6.0-050600-generic_5.6.0-050600.202003292333_amd64.deb linux-headers-5.6.0-050600-lowlatency_5.6.0-050600.202003292333_amd64.deb linux-image-unsigned-5.6.0-050600-generic_5.6.0-050600.202003292333_amd64.deb linux-image-unsigned-5.6.0-050600-lowlatency_5.6.0-050600.202003292333_amd64.deb linux-modules-5.6.0-050600-generic_5.6.0-050600.202003292333_amd64.deb linux-modules-5.6.0-050600-lowlatency_5.6.0-050600.202003292333_amd64.deb
Kdysi mi tu bylo řečeno: "třeba lowlatenci je vhodné pro hudební profesionály" Nemohlo by mi to pomoci? Nezlob se, že se ptám, ale na vlatní pěst to zkoušet nechci.
No jasně. Vždyť já se pokouším o novou instalaci. Ani bych to nechtěl předělané. Chci to mít kvalitně.
Vyřešeno.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.