Qemu o simili simulare installaizone di sistema con EFI

[joe]

Ciao a tutti,
sto cercando semplicemente di simulare l'installazione e l'avvio di un sistema (diciamo pure slackware, ma va bene anche in generale) su un hardware che include un firmware UEFI.

Mi interessava capire in particolare come deve essere partizionato il disco per essere ospitato in sistemi del genere e come deve essere installato il bootloader.

Una volta, tanto tempo fa c'era un simpatico bootloader che risiedeva nella prima parte del disco MBR e da lì avviava questa o quella partizione. Il BIOS passava l'avvio del PC al disco di boot e lì il bootloader si prendeva in carico l'avvio del sistema operativo scelto in base alla configrazione /etc/lilo.conf ecc ecc...

Ora se ho ben capito c'è qualcosa di diverso.
Il disco deve essere partizionato in GPT per sfruttare UEFI.
Il MBR non esiste praticamente più in termini di funzioni di boot, e il bootloader si deve infilare nella partizione EFI dedicata. In questa a seconda del bootloader scelto si va ad installare un file che solitamente è /boot/efi/EFI/GRUB oppure /boot/efi/EFI/ELILO ecc...
Lì dentro viene installato un file, esempio per grub nel caso che ho testato io "grubx64.efi".

Ma questo file non è solo preso da qualche parte e messo lì, da come ho capito viene anche "registrato" nella memoria del UEFI.
Ho il forte sospetto che questo passaggio, quando si testa la situazione con un software di virtualizzazione come qemu, possa portare a complicazioni varie. Del tipo che al riavvio, il UEFI potrebbe non ricordare più che il nostro bootloader era stato registrato... E banalmente non si avvia nulla.
Il mio è solo un sospetto, confermato però dal fatto che non parte nulla...

Ho avviato Qemu con questo script e funziona, cioè si avvia slackware live e sembrerebbe avviata su un PC UEFI (ci son i files /sys/efi o qualcosa del genere):

Codice: Seleziona tutto

#!/bin/bash

ISO=$1
SYSDRV=$2
qemu-system-x86_64 \
        -enable-kvm \
        -m 1.5G \
        -drive file=$ISO,media=cdrom \
        -drive file=$SYSDRV,media=disk,format=raw \
        -boot d \
        -bios /usr/share/ovmf-x64/OVMF_CODE-pure-efi.fd

Di fatto ho seguito questo approccio (Sezione GRUB):
https://docs.slackware.com/howtos:slack ... e?s[]=grub

Ho fatto la prova avviando con la iso di LiveSlak e un disco virtuale raw vuoto da 8GB.
Ho installato la live sull'HDD con lo script di Alien:
https://docs.slackware.com/slackware:liveslak

Codice: Seleziona tutto

setup2hd

Ho saltato l'installazione di Elilo e quindi ho proceduto ad installare il pacchetto grub su liveslak, con slackpkg e le dipendenze efivar e efibootmgr che sono necessari richiamati da grub-install.

(Tra parentesi sarebbe una bella cosa se Alien aggiungesse grub di default alla liveslak, diamine! È un programma essenziale per una live...).

Ad ogni modo alla fine il bootloader riesco ad installarlo nella partizione efi.
Ma se spengo la macchina virtuale e la riavvio, la nuova installazione su hdd virtuale non s'avvia.


Domandona:
Qualcuno di voi ha mai armeggiato con qemu o simili diavolerie, per testare installazioni?
Lo ha mai fatto cercando di simulare una macchina UEFI?

[rik70]

Per farla breve, devi per forza fare una cosa del genere:

Codice: Seleziona tutto

mkdir -pv /boot/efi/EFI/BOOT

cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi

Ovvero: prendere il file "grubx64.efi" creato dall'installazione di grub e copiarlo/spostarlo nella directory 'EFI/BOOT' rinominandolo "bootx64.efi".

[joe]

Stavo per leggere sto spiegone:

https://wiki.archlinux.org/index.php/GRUB/EFI_examples

Poi ho letto la risposta di rik70, ho provato la cosa e funziona!
Ottimo! Ora si avvia in UEFI con grub.

Certo non ci ho capito molto, cioè col metodo canonico non funziona, perché mai?
Perché occorre rinominare quella roba a mano?
Perché LILO, parlando di BIOS/MBR non rompeva le scatole e si posizionava correttamente nel MBR leggendo la semplice (o per lo meno razionale) configurazione in /etc/lilo.conf, invece ora con UEFI bisogna inventarsi soluzioni "esotiche" tipo questa copia a mano?

Sapete indicare qualche link per capire la logica che ci sta dietro?
Dallo spiegone che stavo per leggere mi pare di capire che si tratti di una situazione fuori standard, ovvero ogni produttore di firmware UEFI richiede un'impostazione specifica della relativa partizione EFI e dei pezzi del boot-loader che vanno sistemati e nominati "come vogliono loro".

Grazie della soluzione che funziona e grazie se vorrete aggiungere qualche dettaglio che penso possa tornare utile a tutti vista l'attuale presenza di UEFI un po' in tutte le moderne configurazioni.

[rik70]

Certo non ci ho capito molto, cioè col metodo canonico non funziona, perché mai?
Perché occorre rinominare quella roba a mano?
Perché LILO, parlando di BIOS/MBR non rompeva le scatole e si posizionava correttamente nel MBR leggendo la semplice (o per lo meno razionale) configurazione in /etc/lilo.conf, invece ora con UEFI bisogna inventarsi soluzioni "esotiche" tipo questa copia a mano?

Con UEFI, il Boot Manager del Firmware va a cercare in 'EFI/BOOT' della partizione ESP i file con estensione '.efi' e carica quello che trova. O almeno in teoria; in pratica nei sistemi a 64bit "vuole" il file "bootx64.efi".

Quando tu installi grub, grub-install invece lo piazza in un altra directory e gli da un altro nome(puoi eventualmente modificare questo aspetto a tuo piacimento);
poi invoca efibootmrg, che aggiunge all''EFI Boot Manager' del Firmware una nuova voce (quella di grub) e la imposta come predefinita.

Ovviamente questo non può funzionare con qemu, perché quando spegni la macchina virtuale tali modifiche non permangono.

La "rinominazione" e lo spostamento servono appunto allo scopo.

Inoltre, non tutti i firmware "gradiscono" queste modifiche; ecco perché ad esempio Windows in modalità Uefi segue lo standard e piazza il suo "loader" direttamente in BOOT/EFI/bootx64.efi senza apportare cambiamenti lato firmware.

[joe]

Vedo che nel frattempo ha risposto anche rik70... Grazie, stavo scrivendo anch'io per cui ormai completo il post...

Cercando di capirci di più, ho trovato due links interessanti e più o meno ho capito il motivo del mancato avvio della macchina virtuale.
Allora, da quanto ho capito, UEFI è composto da diverse parti tra cui 2 importanti per quello che serve all'argomento:
- una parte "codice" che viene utilizzata in sola lettura ed è il "motore" che fa apparire le varie opzioni di boot scegliere se avviare dal DVD o da USB o da vari dischi sata ecc ecc...
- una parte "memoria" non volatile collocata nella NVRAM del UEFI. Qui vengono "registrati" i vari bootloaders che saranno poi residenti nella partizione EFI.

L'inghippo in cui sono inciampato si presenta con QEMU usato liscio, senza virtmanager o sovrastrutture dedicate (che non ho provato ma immagino provvedano a rendere la situazione più simile a quanto accade nella realtà).
In pratica quando si installa Grub con grub-install, o anche ELilo o qualsiasi bootloader, nella realtà questo viene registrato nella NVRAM del UEFI, ma Qemu se non istruito opportunamente non ha questa possibilità. Ecco allora che al riavvio della macchina virtuale i bootloaders registrati nella sessione precedente, non risultano più noti al UEFI e non è possibile lanciarli e avviare così i vari sistemi.

Si può però procedere manualmente dalla EFI-Shell, di cui Io ho provato qualche comando:
si avvia qemu con ovmf, si preme ripetutamente ESC nonappena appare la schermata nera, si entra nelle opzioni di boot e si sceglie UEFI Shell.
Da quella riga di comando si può fare:

> fs0:
> cd EFI/GRUB/
> grubx64.efi

E si avvia grub. Idem per avviare altri bootloader installati nella partizione EFI. Qua un riferimento

https://unix.stackexchange.com/question ... g-qemu-kvm

EFI firmware saves boot options in NVRAM. QEMU currently does not preserve NVRAM, so boot options are lost once you close QEMU. Without boot options, the firmare tries to find \EFI\BOOT\BOOTX64.EFI to execute but it's not here, so it does not know what to boot and leaves control to you. What you need to do to boot the kernel in EFI shell is just enter a filesystem, navigate to a proper path, and execute a binary.

fs0:
cd EFI\fedora
grub.efi

or

vmlinuz.efi ...

Ok poi ho trovato anche questo:
https://blog.system76.com/post/13913859 ... enial-host

Qui si spiega come dotare Qemu, della persistenza. Così i bootloaders/kernel registrati vengono ripescati all'avvio e si può anche predisporre una priorità di avvio usando "efibootmgr".

Ecco lo script di avvio della macchina virtuale:

Codice: Seleziona tutto

#!/bin/bash

SYSDRV=$1
UEFI=uefi-code-nvram/OVMF_CODE-pure-efi.fd
NVRAM=uefi-code-nvram/OVMF_VARS-pure-efi.fd
#su -c "modprobe kvm-intel"
qemu-system-x86_64 \
        -m 1.5G \
        -enable-kvm \
        -drive if=pflash,format=raw,readonly,file=$UEFI \
        -drive if=pflash,format=raw,readonly,file=$NVRAM \
        -drive if=virtio,file=$SYSDRV

Ho copiato la parte "codice" di UEFI da /usr/share/ovmf-64/OVMF_CODE-pure-efi.fd
Ho copiato la parte "nvram" da /usr/share/ovmf-64/OVMF_VARS-pure-efi.fd
Li ho poi piazzati in una directory locale "uefi-code-nvram"... va be' queto è per ordine ma non era necessario. La parte nvrm deve comunque essere copiaincollata come un template che verrà poi modificato dalle registrazioni dei bootloaders. Questa parte poi verrà richiamata ad ogi avvio di quemo ed ecco che le modifiche apportate saranno così permanenti anche nelle sessioni qemu successive.

Ah dimenticavo... MA lo ha già detto anche rik...
Perché allora con la copia in EFI/BOOT/bootx64.efi l'avvio e il riavvio funzionano? Nonostante la registrazione non avvenga a livello UEFI/QEMU?
Semplice!
Perché quello è l'eseguibile di default che il UEFI è preimpostato ad avviare in mancanza di altro. Come mostrato però anche attraverso la UEFI Shell si può avviare quello che si desidera in realtà, mentre per farlo automaticamente serve registrare la cosa a livello di NVRAM, quindi va predisposta in quemu quella funzionalità.

[rik70]

@joe
Perfetto!

Con libvirtd:

- sezione XML del dominio:

Codice: Seleziona tutto

<loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE-pure-efi.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/debian-testing_VARS.fd</nvram>

Avviato l'OS, con efibootmgr si aggiunge la voce che interessa e s'imposta come predefinita

Codice: Seleziona tutto

efibootmgr -c -d /dev/vda -p 1 -l "\EFI\debian\grubx64.efi" -L "Debian"

che permane anche dopo lo spegnimento

Codice: Seleziona tutto

efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0005
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* Debian	HD(1,GPT,d1a6b7ce-445a-4fda-90e3-0f063fdd6baf,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0005* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)

pure dopo l'accesso alla shell/bootmanager Uefi(che va a riscrivere la NVRAM)

Codice: Seleziona tutto

efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0005,0002,0003,0004,0006
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* Debian	HD(1,GPT,d1a6b7ce-445a-4fda-90e3-0f063fdd6baf,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0002* UEFI QEMU DVD-ROM QM00001 	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)N.....YM....R,Y.
Boot0003* UEFI Misc Device	PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0)N.....YM....R,Y.
Boot0004* UEFI PXEv4 (MAC:52540065213B)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(52540065213b,1)N.....YM....R,Y.
Boot0005* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0006* UEFI HTTPv4 (MAC:52540065213B)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(52540065213b,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.....YM....R,Y.

[joe]

Ciao, bene efibootmgr.

Libvirtd... non lo conosco sinceramente. So che è un servizio per la gestione in comodità di più macchine virtuali, al quale ci si può collegare con varie interfacce, tipo virtmanager o virsh, ma non l'ho mai usato. Ho dato un'occhiata e di passaggio leggo che è consigliabile configurare la macchina virtuale con qualcosa tipo 'virsh edit $vmname'...

https://wiki.libvirt.org/page/FAQ#Where ... _config.3F

Detto questo metto anche quest'altro link, forse un po' datato nono so, ma mi ha incuriosito parecchio il discorso "spice":

http://www.debianitalia.org/guide/kvm/l ... rt-e-spice

A quanto si legge lì parrebbe una soluzione capace di far girare la macchina virtuale in modo molto più fluido e reattivo. Sempre che abbia capito bene, visto che ho letto un po' di corsa... Vedremo, magari prossimamente faccio qualche prova, se avete commenti in merito leggo sempre con piacere.

Devo correggere il mio scriptino di lancio qemu che ho riportato sopra:
ho lasciato un readonly di troppo dove invece serve l'utilizzo in scrittura delle NVRAM. In realtà mi pare avesse funzionato lo stesso, ma forse sto facendo confusione perché adesso non mi riconosce più neanche il disco virtuale come /dev/sda e infatti non si avvia più niente.
Dalla shell della busybox vedo che ci sono /dev/vda, e leggendo la tua configurazione sopra ne deduco che con l'opzione -drive if=virtio e senza l'opzione -bios che ho tolto, probabilmente vede il disco come /dev/vda e non come /dev/sda. Sto andando a naso... Sarebbe anche il caso di fare una ricerca in merito va be'. Ad ogni modo mettendo in fstab l'UUID delle partizioni si dovrebbe risolvere e avere una soluzione un po' meno ballerina.

Codice: Seleziona tutto

#!/bin/bash

SYSDRV=$1
UEFI=uefi-code-nvram/OVMF_CODE-pure-efi.fd
NVRAM=uefi-code-nvram/OVMF_VARS-pure-efi.fd
#su -c "modprobe kvm-intel"
qemu-system-x86_64 \
        -m 1.5G \
        -enable-kvm \
        -drive if=pflash,format=raw,readonly,file=$UEFI \
        -drive if=pflash,format=raw,file=$NVRAM \
        -drive if=virtio,file=$SYSDRV

Il problema è che così non si avvia più...
Mi manda in busybox per aggiustare la situazione ma non se ne esce.
Ho riavviato dalla iso live come se fosse un cdrom.

Lì ho notato che invece di /dev/sda il disco virtuale ora viene visto come /dev/vda.
Allora ho eseguito di nuovo il chroot.
Una volta nel sistema installato su disco virtuale, il comando mount mostrava nuovamente /dev/sda... Misteri.
Ad ogni modo ho ricreato la initrd. Prima a occhio, fallendo miseramente...
Infine col provvidenziale script /usr/share/mkinitrd_command_generateor.sh.

Questo ha prodotto il giusto comando, molto più elaborato del mio, per creare la initrd.
Fatto ciò ho riavviato. In fstab avevo anche messo gli UUID al posto del device che sembrava piuttosto ballerino.
Infine riavviato e tutto ha funzionato.

Come dire... Cose semplici vade retro.

Quello che conta è che adesso c'è una slackware-current installata su hard disk virtuale. In una macchina virtuale che emula un hardware basato su UEFI.

Prossimi passi:

1- capire perché slackpkg non funziona, non riesce a scaricare i pachetti... Invece riesco con links a collegarmi a vari mirrors, scaricare il pacchetto txz e installarlo con slackpkg.
Sospetto problemi di limitazione di rete nella macchina virtuale avviata come visto sopra. Cercherò info...

2- emulare una chiavetta usb virtuale. Con lo scopo di partizionarla e crearne un dispositivo di avvio per sistemi operativi. In particolare per win10, solo per curiosità in seguito ad una procedura analoga eseguita su chiavetta reale e PC reale che ha visto la chiavetta avviarsi così, senza mettervi bootloader. Possibile che in realtà ci fosse stato scritto in precedenza ms-sys... Ma non ricordo e voglio togliermi la curiosità. In pratica dato sistema virtualizzato slackware current scaricare iso win10, preparare a mano chiavetta usb virtuale e riavviare iso con la chiavetta virtuale in modo da far partire l'installazione di win 10.

[joe]

Aggiorno un attimo la situazione in merito ai due punti sopra.
Slackpkg non funzionava perché doveva essere aggiornato (slackpkg update). Me l'ero scordato...
Inoltre l'instradamento della macchina virtuale sembra avesse qualche problemino di connesissone alla rete, sia in termini di instradamento che di risoluzione dei nomi.
Il comando dhcpcd ha risolto tutto.


Per quanto riguarda l'emulazione di una chiavetta usb, niente, basta aggiungere la direttiva "-usb -usbdevice disk:nomefile" al lancio.

Codice: Seleziona tutto

#!/bin/bash

SYSDRV=$1
UEFI=uefi-code-nvram/OVMF_CODE-pure-efi.fd
NVRAM=uefi-code-nvram/OVMF_VARS-pure-efi.fd
#su -c "modprobe kvm-intel"
qemu-system-x86_64 \
        -m 1.5G \
        -enable-kvm \
        -drive if=pflash,format=raw,readonly,file=$UEFI \
        -drive if=pflash,format=raw,file=$NVRAM \
        -drive if=virtio,format=raw,file=$SYSDRV \
        -cdrom slackware64-live-xfce-current.iso \
        -usb -usbdevice disk:usbkey-virt.img

Ora sto armeggiando con la creazione della chiavetta in modo che sia un device avviabile di installazione di windows10, in formato compatibile con UEFI.
Qualche link a futura memoria, il primo è uno script che dovrebbe fare tutto automagicamente, a me più che l'automatismo mi interessava capire come funziona il meccanismo e lì spiega piuttosto bene le varie alternative di organizzazione della chiavetta.
Il secondo comprende il tool che dovrebbe essere adatto alla soluzione più moderna: compatibilità UEFI e utilizzo di filesystem NTFS per la partizione conenente i dati per l'installazione.
https://github.com/ValdikSS/windows2usb
https://github.com/pbatard/uefi-ntfs

Farò sapere come va a finire...

[joe]

È andata a finire che ho creato la chiavetta virtuale, sia facendo la copia dei files dalla ISO montata in loop, sia utilizzando lo script che crea automaticamente la chiavetta (windows2usb). In entrambi i casi avviando dalla chiavetta non parte niente, anzi rilevo un comportamento anormale.

A scanso di equivoci ho tentato il boot della macchina virtuale, sempre impostata in UEFI come sopra con OVMF, ma facendo partire direttamente con la ISO di Win10.
In pratica stessa cosa che ho fatto prima avviando con la ISO di LiveSlak.

In questo caso però rilevo lo stesso strano comportamento osservato nel tentativo precedente con la chiavetta virtuale di installazione di Win10.
Cosa accade:
- avvio, appare la "schermata Tiano Core", premo ESC, vado in boot manager e scelgo "Qemu DVD-Rom-blablabla", insomma il DVD in cui è caricata la ISO di Win10.
- parte con una schermata nera che subito ripresenta il Logo Tiano Core, come avviene all'avvio della macchina virtuale, ma in questo caso non si può più entrare nel menù premendo ESC. La cosa ha senso, infatti si è già scelto di avviare dal DVD. Il problema è che questa schermata resta lì per un po' troppo tempo.
- Alla fine insieme al logo Tiano Core, si osserva apparire la rotellina punteggiata di caricamento di windows! Per cui sembra che qualcosa in tutto quel tempo abbia macinato dopotutto.
- L'epilogo però è deludente, dopo pochi secondi da cui appare la rotellina coi puntini invece di completare un qualche caricamento del sistema di installazione di Windows10, ecco che la schermata di qemu se ne esce, sparisce e la macchina virtaule... non so, è come se fosse andata in crash, la sua finestra si chiude e stop, avevo lanciato da terminale lo script di avvio e questo è quanto ritorna:

Codice: Seleziona tutto

TODO /tmp/build/tmp-qemu/qemu-2.9.0/tci.c:849: tcg_qemu_tb_exec()
/tmp/build/tmp-qemu/qemu-2.9.0/tci.c:849: tcg fatal error
./uefi-dahdd3.sh: riga 15: 14504 Annullato               qemu-system-x86_64 -m 2G -drive if=pflash,format=raw,readonly,file=$UEFI -drive if=pflash,format=raw,file=$NVRAM -drive if=virtio,format=raw,file=$SYSDRV -cdrom $ISO -usb -usbdevice disk:$USBKEY

Nell'esempio sopra avevo lanciato senza KVM abilitato, per provare, ricordo anni fa che l'installazione di XP con kvm abilitato non funzionava.
Mi viene il dubbio sulla minima memoria richiesta... Ma non credo, lì avevo assegnato 2GB alla macchina virtuale. D'altra parte ne ho 4GB in tutto, non è che posso dare di più.

Se qualcuno ha già provato un'installazione di win10 in macchina virtuale impostata in UEFI con OVFM e ha soluzioni al problema benvenga!

[joe]

Ciao a tutti e un augurio di buone feste, o per lo meno serene insomma...

Volevo aggiornare la situazione su questo rompicapo natalizio.
In breve:
- ho aggiornato qemu alla versione 4.1.1, della quale è disponibile lo slackbuild su SBo per slackware stabile che sto usando.
- ho provato a lasciare un attimo perdere il discorso UEFI e sono riuscito ad avviare almeno il DVD di installazione di windows.

Ecco lo script (bios.sh):

Codice: Seleziona tutto

#!/bin/bash

SYSDRV=$1
ISO=$2
qemu-system-x86_64 \
        -m 2.5G \
        -cdrom $ISO \
        -enable-kvm \
        -drive if=virtio,format=raw,file=$SYSDRV \
        -boot d

E qua il comando di lancio dello script:

Codice: Seleziona tutto

sh bios.sh ssd/disco.raw ssd/Win10_20H2_v2_Italian_x64.iso &

Con questo il DVD di Windows10 viene avviato regolarmente. Coi suoi tempi, ma alla fine si presenta la finestrella "Installazione di windows".
Quindi in modalità bios (SeaBios se non sbaglio...) Qemu riesce ad avviare il DVD di windows10.

Domanda, perché impostando le due righe che richiamano OVMF invece va tutto a ramengo?
Lo script che ho provato è il seguente:

Codice: Seleziona tutto

#!/bin/bash

SYSDRV=$1
ISO=$2
UEFI=uefi-code-nvram/OVMF_CODE-pure-efi.fd
NVRAM=uefi-code-nvram/OVMF_VARS-pure-efi.fd

qemu-system-x86_64 \
        -m 2.5G \
        -enable-kvm \
        -drive if=pflash,format=raw,readonly,file=$UEFI \
        -drive if=pflash,format=raw,file=$NVRAM \
        -cdrom $ISO \
        -drive if=virtio,format=raw,file=$SYSDRV \
        -boot d

E relativo comando di lancio:

Codice: Seleziona tutto

sh uefi.sh ssd/disco.raw ssd/Win10_20H2_v2_Italian_x64.iso &

Il comportamento che ottengo è:
- se non premo nulla l'avvio da CD sembrerebbe ignorato e mi avvia da HDD
- se premo ESC all'avvio e vado nel menù UEFI di OVMF posso selezionare a mano il "Qemu DVD-ROM qualcosa" che fa aprtire da DVD
- a questo punto slata fuori la scritta in alto del DVD di windows "press any key to botto from DVD" (sembreremmo sulla strada giusta).
- invece ricompare il logo iniziale con scritto "Tiano Core", sta lì in attesa di qualcosa o in uno stato non meglio precisato... Attendiamo... Attendiamo
- alla fine parte da HDD e mi si presenta la schermata di Grub (sul disco virtuale usato avevo messo slackware da liveslak).

Il primo dubbio che mi è venuto allora è che per avviare da DVD con impostato il UEFI, qemu richieda un altro comando: il comando -cdrom e -boot d non sembrano sufficienti come nella modalità bios.
Questo dubbio me lo conferma anche un altro fatto: provando a sostituire l'immagine iso di windows con quella di slackware-live, anche lì mi rimanda all'avvio su HDD virtuale, mi compare il grub del disco e non il grub del DVD di live-slak.

Ero partito con l'idea di testare una chiavetta virtuale, ma non funzionando, ho preferito usare l'immagine iso come DVD in modo che vi siano meno variabili in gioco (partizionamento chiavetta, bootloaders nella sua partizione EFI ecc ecc...).

Quindi per concludere obiettivo numero 1:
- avviare ISO di slackware-live da qemu-4.1 in modalità UEFI (OVMF)
- senza selezionare il DVD-rom dal menù del UEFI

Se qualcuno volesse fare un test dell'operazione, benvenga!

[brg]

Il primo dubbio che mi è venuto allora è che per avviare da DVD con impostato il UEFI, qemu richieda un altro comando: il comando -cdrom e -boot d non sembrano sufficienti come nella modalità bios.

Perché quelle sono opzioni per il BIOS non per l'UEFI. L'UEFI non ha opzioni. Per modificare il comportamento di UEFI devi modificare OVMF, oppure entrare nel menù all'avvio e impostare allora il funzionamento.

[joe]

Grazie della risposta brg!

Ecco intanto giusto cominciare con la teoria del UEFI.
Ma per modificare OVMF in modo che parta prima dal CD?

Avevo scritto una risposta prima di leggere la tua con qualche altro tentativo che però non mi ha portato troppo lontano...
Metto qua sotto il messaggio comunque.

[joe]

Niente sembra che oggi non abbia fortuna... Non riesco neanche a postare il mesaggio che avevo scritto... mi dice che non ho i permessi per l'accesso a questa risorsa, bo..

[joe]

Provo a mettere il messaggio come allegato...

[joe]

Ok, così funge, ma che fatica! Ad ogni modo magari poi riprovo a mettere la risposta in chiaro... Non so perché quel messaggio dà noia al server del forum. Ci sarà bene un motivo...
Spero riusciate a leggerlo anche se la formattazione se n'è andata, comunque dovrebbe essere leggibile.