Newsgroup: it.comp.os.linux.iniziare
Titolo: DualBoot con solo UEFI = Chiarimento

Ciao a Tutti,
 
questa settimana, mi è capitato di installare Ubuntu Mate 20.04 LTS su 
un computer desktop Acer abbastanza recente di una Organizzazione di 
Volontari, che trasportano gli anziani nei vari centri ospedalieri, per 
analisi, visite specialistiche e terapie (anche oncologiche).
 
Essendo il computer recente, il bios ha solamente UEFI, l’opzione 
Legacy/CSM Mode è assente e facendo ricerche per risolvere il problema, 
ho scoperto che da gennaio 2020 Microsoft e Intel non permetteranno più 
il legacy mode, vedi thred:
https://www.dell.com/community/Windows-10/missing-option-quot-Enable-Legacy-Option-ROMs-quot-in-BIOS-setup/td-p/7381209
 
 
Poichè a casa non ho un computer recente per fare prove, sto cercando di 
costruirmi il mio tutorial, in base a quanto trovato in rete.
 
Esempio:
UEFI_Dualboot
A)
01 (uno) SSD = Win10 + Ubuntu
- restringere la partizione Windows
- con Gparted costruire …..
 
B)
02 (due) SSD
- 01 ssd = win10
- 01 ssd = ubuntu
 
Fin qui, mi è chiaro tutto, il dubbio nasce dove installare *Grub*
 
In quasi tutti i tutorial trovati, bisogna costruire una partizione da 
650Mb, 1Gb o 2Gb di Boot/EFI, nella partizione LINUX (sdb1) ma poi si 
legge che grub viene installato in sda o sdb, ma allora a che serve una 
partizione boot/efi Linux se poi non viene utilizzata?? Si sprecano solo 
dei Mb o Gb sul disco!! Questo è il mio dubbio, che ho bisogno di chiarire!
 
L’unico tutorial trovato in rete, con la spiegazione logica e razionale 
è questo: 
https://askubuntu.com/questions/726972/dual-boot-windows-10-and-linux-ubuntu-on-separate-hard-drives
 
 
Praticamente consiglia di installare grub in sdb1 (/Boot/EFI di Linux), 
in questo modo non va ad inficiare (sda) il disco o la partizione con 
Win10 e il suo bootloader ed eventualmente, in un futuro, è anche 
possibile togliere/sostituire il secondo disco con ubuntu che tutto 
funziona senza ripristinare nulla di win10.
#==============================================
[Vedi link precedente]
 
Che cosa ha fatto:
 
Tu hai installato Linux EFI bootloader nella nuova partizione EFI. Con 
questa procedura, Linux ha aggiunto una voce all’elenco del tuo EFI, nel 
sitemaUEFI/BIOS. Linux ha anche rilevato automaticamente il tuo 
Windows10 e aggiunto la relativa voce in grub. Il tuo computer, a questo 
punto, può automaticamente caricare Linux, a meno che tu scelga di 
caricare Windows (da menu Grub).
 
#==============================================
Che cosa non ha fatto:
 
Tu non hai in nessun modo alterato il tuo Windows 10 o il suo bootloader 
o addirittura toccato la partizione EFI di Windows. Ogni cosa è 
reversibile, semplicemente rimuovendo la voce UEFI di Linux dalle 
impostazioni UEFI/Bios. Come fare ciò varia da ogni fornitore.
#==============================================
 
Senza togliere nulla alle varie persone che hanno pubblicato i loro 
tutorial, le quali hanno dedicato la loro energia e il loro tempo a 
condividere il loro sapere, questa spiegazione, a mio avviso, è la più 
chiara trovata in internet….
 
Però come dicevo prima, non avendo un pc per fare dei test ho bisogno di 
chiarire questo dubbio.
 
Ringrazio anticipatamente qualsiasi persona, più esperta di me, per i 
suoi consigli.
 
Un cordiale saluto,
Nemo
 

 
 
dunque per il dual boot con uefi si usa la tabella delle partizioni gpt, 
che permette 255 (o 127? insommma, più di quelle che ti servono) 
partizioni primarie per ogni disco.
inoltre conviene installare prima windows, decidendo lo spazio per c:\, 
ma poi magicamente verranno create un paio di partizioni extra "di 
sistema", compresa una efi da circa 100 mega in fat32.
quando andrai a installare una distro linux, devi avere l'accortezza di 
individuare quella partizione efi e di montarla (senza 
formattarla!!!!!!) come /boot/efi.* poi il buon senso dice che ti 
conviene farti un partizionamento tipo /boot (in ext3, xfs, vedi tu, da 
2-3 giga, dipende da quanti kernel vuoi tenere installati 
contemporaneamente), una radice / (in btrfs, ext4, xfs, anche qui fai tu 
se apprezzi la differenza) da almeno 20-25 giga o anche molto di più a 
seconda di quanto sw dovrai installare e quanto poco vorrai ripulire, e 
sempre a tuo giudizio, una /home a parte.
 
insomma per la mia esperienza di dual boot di diversi anni, avere due 
partizioni efi non ha molto senso, dato che sono formattate in fat32 e 
c'è posto in abbondanza per metterci quei file che piacciono tanto ai 
bios moderni: se ci guardi dentro, vedrai che sono state create delle 
directory specifiche per i vari s.o. presenti nella macchina e con un 
po' di pelo sullo stomaco si possono cancellare gli avanzi delle 
eventuali distro provate e eliminate.
tutto questo verrà facilmente gestito da grub, che è fatto così bene da 
riconoscere windows, per cui dal menu di avvio del bios selezioni il 
grub di ubuntu, che a sua volta ti consentirà di far partire il 
bootloader di windows, il quale vede solo windows e lo fa partire 
normalmente.
 
*il concetto delle partizioni gestite da linux è che puoi montare una 
partizione di un disco separato (/dev/sdb1 per esempio che può essere un 
tera di fotografie scaricate dal cellulare /foto) come sottodirectory di 
una partizione, per esempio la tua radice che fisicamente è /dev/sda5.
in una macchina puoi avere hai un ssd più piccolo dove tenere i s.o. coi 
loro bei programmi e giochi e un hdd meaccanico bello grosso dove tenere 
i dati, ma quando partizioni e imposti i punti di montaggio, la 
gerarchia "logica" non è necessariamente uguale a quella fisica. una 
partizione può essere montata dove ti pare, poi il suo file system sarà 
una serie di directory e file dentro a una qualunque directory che hai 
scelto più o meno arbitrariamente. se se non ti piace, metti mano a 
/etc/fstab preservando i dati e il funzionamento della macchina senza 
grossi patemi d'animo.

> Nemo
 
 
Ciao, grazie per la tua risposta e pazienza nel leggere il mio lungo post!
 
 > quando andrai a installare una distro linux, devi avere l'accortezza 
 > di individuare quella partizione efi e di montarla (senza
 > formattarla!!!!!!) come /boot/efi.
 
Non capisco cosa intendi dire quando scrivi: individuare quella 
partizione efi e di montarla (senza > formattarla!!!!!!) come /boot/efi.
 
Ti riferisci alla partizione /boot/efi di Windows10?
 
Se si, non capisco, allora a cosa serve costruirne una identica per Linux.
 
Mi vengono spontanee altre domande da chiarire, ad esempio:
L'installazione non sarebbe più pulita se Grub fosse installato in 
/boot/efi di Linux ???
 
Se il proprietario del computer in un futuro decidesse di togliere o 
sostituire il secondo HDD/SSD la partizione di Windows 10 sarebbe pulita 
e non necessirerebbe di manutenzione, nel reinstallare il bootloader 
Windows.
 
Ho bisogno di chiarire questi concetti, altrimenti sono bloccato, sia 
per me stesso che per gli amici.
 
Poichè ho visto che è una corsa ad ostacoli, cioè le multinazionali 
ostacolano sempre di più l'installazione del software libero, bisogna 
imparare le procedure giuste per utilizzare la nostra distribuzione 
preferita.
 
Ciao,
Nemo
 
PS: quando installo Linux, creo sempre partizioni multiple, mi piace di 
più avere dei contenitori dedicati per / (root) e home, che avere una 
partizione unica miscielata alla Windows.
 
 


Forse ho trovato qualche risposta ai miei dubbi. Cercando su 
askubuntu.com
, sono arrivato alla guida ufficiale di Ubuntu:
https://help.ubuntu.com/community/UEFI#Setup_the_BIOS_in_EFI_or_Legacy_mode
 
 
[…]
 
Creating an EFI System Partition
If you are manually partitioning your disk in the Ubuntu installer, you 
need to make sure you have an EFI System Partition (ESP) set up. This 
partition holds EFI-mode boot loaders and related files.
     • If your disk already contains an ESP (eg if your computer had 
Windows 8 preinstalled), it can be used for Ubuntu too. Do not format 
it. It is strongly recommended to have only 1 ESP per disk.
     • An ESP can be created via a recent version of GParted (the 
Gparted version included in the 12.04 disk is OK), and must have the 
following attributes:
         ◦ Mount point: /boot/efi (remark: no need to set this mount 
point when using the manual partitioning, the Ubuntu installer will 
detect it automatically)
         ◦ Size: minimum 100Mib. 200MiB recommended.
         ◦ Type: FAT32
         ◦ Other: needs a "boot" flag.
 
#=====================================================0
Per cui ricapitolando i due scenari:
 
Scenario A - 01 (un) solo HDD o SSD
 
sda = Win10
sda1 = 100 Mb = Fat32 = Boot/EFI
sda2 = 	  ???  = System Recovery
Sda3 = ntfs = c:\win10
 
sdb = Ubuntu
sdb1 = 2 Gb = Fat32 = Boot/EFI = NON NECESSARIA
sdb2 = Ext4 = / (Root)
sdb3 = Ext4 = Home
sdb4 = Swap (per HDD)
 
Installare Grub in sda1 (/boot/efi = win10).
 
[
https://help.ubuntu.com/community/UEFI#Setup_the_BIOS_in_EFI_or_Legacy_mode
]
 
     • If your disk already contains an ESP (eg if your computer had 
Windows 8 preinstalled), it can be used for Ubuntu too. Do not format 
it. *It is strongly recommended to have only 01 ESP per disk*
 
#======================================================
 
Scenario B - 02 (due) HDD o SSD
 
1)   Disco 1 = sda = Win10
sda1 = 100 Mb = Fat32 = Boot/EFI
sda2 = 	  ???  = System Recovery
Sda3 = ntfs = c:\win10
 
2)   Disco 2 = sdb = Ubuntu
sdb1 = Fat32 = Boot/EFI
sdb2 = Ext4 = / (Root)
sdb3 = Ext4 = Home
sdb4 = Swap (per HDD)
 
Installare Grub in sdb1 (/boot/efi = ubuntu).
 
PS: Ora ho le idee un po' più chiare.
PPS: In base a quello che ho letto dovrebbe funzionare, poi è tutto da 
provare.
 
Ciao,
Nemo
 
 

 Installare Grub in sda1 (/boot/efi = win10).
 
 
Ma questo scenario non presenta un solo hard disk:
 
- sda primo disco
 
- sdb secondo disco
 
Secondo me non hai le idee troppo chiare.
 
Al netto delle guide che spulci ti do un consiglio:
fai una prova pratica!
 
Se non hai un PC con UEFI installa una macchina virtuale.
Puoi farlo facilmente con:
 
- Qemu/KVM + libvirt + virt-manager + OVMF
 
Cerca sul tubo questa roba trovi video fatti bene e
semplici anche in italiano mi pare. Si capisce ance con
quelli in inglese comunque.
 
 
Qemu/KVM è il programma di virtualizzazione vero e proprio,
basta che lo installi e attivi il modulo del kernel kvm,
kvm_intel o kvm_amd a seconda della CPU che hai.
Stop di questo non ti serve sapere altro.
 
libvirt serve a mettere in piedi un servizio a cui si
collega l'interfaccia vera e propria, basta che lo installi
e lo avii come servizio. Può darsi che faccia tutto da solo.
 
Infine virt-manager è l'interfaccia grafica con cui hai a che
fare.
Qui ti crei un sistema simile a quello vero su cui dovrai
installare i sistemi win e ubuntu.
 
Ti crei una nuova macchina virtuale aggiungi un disco virtuale di almeno
20 GB con storage collegato in SATA, in cui puoi installare win10 avviando
la macchina virtuale da ISO di win110 e sceglindo modalità UEFI (vedi in
seguito), dando il minimo spazio possibile a win tipo 12 GB.
 
Poi vai avvii la macchina virtuale con la iso di ubuntu e vai ad installarlo
nello spazio rimanente di 7 8 GB, se sai già che non ci sta dai più spazio
alla macchina virtuale già in partenza, tipo 30 GB di storage..
 
Ora, il punto: come fare a virtualizzare un sistema UEFI?
 
Con OVMF.
 
Lo installi e quando crei la macchina virtuale, scegli di rivedere
la configurazione prima dell'avvio, qui imposti tutte le voci in
particlare nella scheda generale, metti UEFI scegliando ad esempio:
 
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
 
Lo trovi già nel menù a tendina.
 
Così hai una macchina virtuale con un solo disco e vedi come si
crea il tutto, se sbagli non c'è problema. Tanto è solo roba
virtuale.
 
Se vuoi mettere due dischi, meglio ancora.
Sul disco di Linux farai una partizione EFI da mezzo giga o anche 1GB
a seconda di quanto spazio hai, dovrebbe andar bene già 200 MB...
 
Come dicevi grub dovrebbe fare tutto da se, basta che gli dici di
installarsi nella partizione EFI del disco in cui metti linux, così
lasci stare quello in cui c'è windows. È una soluzione bella pulita.
 
In questa configurazione, grub si va ad installare non più nel MBR
del disco, né nella partizione "BIOS" da usare su sistemi ibridi, con
Mobo non uefi, solo vecchio BIOS, ma disco partizionato con tabella GPT.
Nel tuo caso di sistema UEFI, avremo grub installato nella partizione
EFI creata come un'altra partizione qualunque, con fdisk dai il codice 1
o comunque devi scegliere quella "EFI System". Con gdisk "EF00"...
Va formattata in vfat o fat32.
 
Ripeto se hai la possibilità prova da macchina virtuale così quando
avrai sottomano il PC vero, fai tutto rapidamente senza sbagliare.
 
Grub, verrà impostato per far partire sia ubuntu, rilevando kernel
in /boot e vari altri files tra cui intird ecc...
Rileverà anche windows credo, e ne imposterà la voce in chaniload cioè
passando la palla al bootloader di win che si trova sul corrisppondente
disco, sempre quello di win...
 
Infine dovrai impostare il BIOS/UEFI in modo che avii la macchina dal
disco di linux, farà partire la partizione EFI con dentro grub che
poi ti mostrerà i vari sistemi da scegliere.

 
 
Grande la tua idea!!!!!!!!!!!!!!!
 
Non sapevo dell'esistenza di OVMF e quindi non pensavo minimamente di 
fare prove con una macchina virtuale!!!
 
Questa settimana inizio i miei test.
 
Grazie e Buon Anno!!!!
Nemo
 
 
PS: cambiando motore di ricerca (startpage) ho trovato delle guide 
ufficiali, in italiano, di Grub e Uefi, le quali portano a delle risorse 
per installare o correggere l'installazione di Grub:
 
Rescatux e Super Grub2  
https://www.supergrubdisk.org/
 
rEFInd    
http://www.rodsbooks.com/refind/
 
 
 
Risorse:
https://itigic.com/it/rescatux-linux-to-repair-and-recover-any-pc/
 
 
 

 rEFInd    
http://www.rodsbooks.com/refind/
 
 
Ci ero inciampato anche io se ricordo bene, non ricordo benissimo il
contenuto così su due piedi.
 
Tanto per avere un'idea della vitualizzazione con virt-manager:
https://www.youtube.com/watch?v=2WDASJ0ye0A
 
 
La cosa è molto semplice come vedi.
Più complicato è capire come istruire grub ad installarsi dove
vuoi tu. Ma non troppo più difficile dopotutto:
---------------
https://www.gnu.org/software/grub/manual/grub/grub.html#Installing-GRUB-using-grub_002dinstall
 
---------------
On EFI systems for fixed disk install you have to mount EFI System
Partition. If you mount it at /boot/efi then you don’t need any special
arguments:
 
# grub-install
 
Otherwise you need to specify where your EFI System partition is
mounted:
 
# grub-install --efi-directory=/mnt/efi
----------------------------------------
 
Quindi in fase di installazione:
 
- ti assicuri di avere la partizione EFI formattata in FAT32/vfat
- la monti in /boot/efi
- mount /dev/sda4 /boot/efi
- grub-install
 
Vedrai che in ti crea un insieme di dirs e subdirs:
 
/boot/efi/EFI/GRUB
 
lì dentro ci metterà il bootloader, un file chiamato grubx64.efi.
Ecco, quando avvierai il PC, il bios/uefi dovrebbe riconoscere
automaticamente il bootloader grub in sda4.
Potrebbe anche dare priorità al bootloader che vede in sda1, quello
di windows...
 
Dal wiki di arch:
 
GRUB is the bootloader while efibootmgr is used by the GRUB installation
script to write boot entries to NVRAM:
 
Quindi, con grub-install viene installato grub nella partizione EFI.
Ma il Bios/UEFI come fa a saperlo?
 
Lo sa perché grub-install alla fine richiama anche il tool efibootmgr
che ha proprio il compito di registrare nella memoria non volatile del
BIOS/UEFI, sulla sua NVRAM, dov'è GRUB e gli altri bootloaders e quale
avviare per primo.
 
efibootmgr può eventualmente essere usato per dare priorità a grub, se
non facesse già tutto da solo:
 
https://askubuntu.com/questions/485261/change-boot-order-using-efibootmgr
 
 
Saggiamente lì suggeriscono anche il piano B, cioè usare "bcdedit" in
caso di rogne...
 
Io ho provato a fare qualcosa di simile, per impostare grub da liveslak,
dopo averla installata su disco virtuale (che di suo utilizza ELILO, ma
tanto per vedere come funziona...).

 
 
Intanto, *grazie* di tutto!
Neno

 confusione???
 
Non lo so, non dovrebbero ma da quanto ho capito ogni BIOS/UEFI Firmware
è un po' fatto a modo suo, per cui potrà dipendere da quello, nel dubbio
segui pure quelle indicazioni. Se lo scrivono avranno un senso pratico.
Tuttavia così facendo si accetta di far coabitare grub col bootloader di
windows.
Ad ogni modo se un domani windows ti rasa GRUB per qualche motivo,
potrai sempre reinstallarlo da ubuntu, usando i comandi da terminale
che ti avevo mostrato sopra, presi dal manuale di GRUB. Ovviamente non
ti si avvierà ubuntu e dovrai farlo dalla live col DVD o chiavetta, non
è detto che debba essere la live di ubuntu, basta che ci sia disponibile
grub.
Esempio in liveslak che ho provato non c'è (sempre perché slackware di
default usa ELILO, per cui si deve aggiungere... Per una live non è una
scelta ottima secondo me perché potresti trovarti ad utilizzarla in
situazioni offline, ma va be').
 
Comunque è una formalità, tieni conto che stiamo parlando di installare
il "bootloader eseguibile", non di riconfigurare grub. La configurazione
se ne sta tranquilla in /boot/grub/grub.cfg, credo anche ubuntu la
posizioni lì.
 
In pratica farai:
 
mount /dev/sda1 /boot/efi
grub-install
 
E ubuntu dovrebbe tornare avviabile.

 vai al menù a tendina e vedi quali opzioni ti fa scegliere.
 
Ho provato la procedura guidata e ho visto che il menù a tendina
in realtà fa parte dell'intefaccia di partizionamento.
 
Io partivo con un disco vuoto (virtio /dev/vd* ) quindi all'inizio
c'era solo:
 
/dev/vda
 
Poi ho creato a mano la partizione EFI System Partition e a quel
punto nella tendina è comparsa anche la partizione EFI creata.
Così l'ho scelta e via...
 
/dev/vda1
 
Ora non ricordo già più ma il punto di mount lo sceglie già in
automatico settato a /boot/efi.
Ti confermo che l'installazione è andata a buon fine incluso grub,
dalla procedura non si vede nulla ma poi funziona regolarmente.
 
Ecco cosa viene installato nella partizione sda1 di EFI:
--------------------
# ls -lR /boot/efi/
/boot/efi/:
total 1
drwx------ 4 root root 512 gen  5 22:54 EFI
 
/boot/efi/EFI:
total 1
drwx------ 2 root root 512 gen  5 22:54 BOOT
drwx------ 2 root root 512 gen  5 22:54 ubuntu
 
/boot/efi/EFI/BOOT:
total 3753
-rwx------ 1 root root 1341560 gen  5 23:11 BOOTX64.EFI
-rwx------ 1 root root 1222800 gen  5 23:11 fbx64.efi
-rwx------ 1 root root 1277024 gen  5 23:11 mmx64.efi
 
/boot/efi/EFI/ubuntu:
total 4201
-rwx------ 1 root root     108 gen  5 23:11 BOOTX64.CSV
-rwx------ 1 root root     117 gen  5 23:11 grub.cfg
-rwx------ 1 root root 1681280 gen  5 23:11 grubx64.efi
-rwx------ 1 root root 1277024 gen  5 23:11 mmx64.efi
-rwx------ 1 root root 1341560 gen  5 23:11 shimx64.efi
-------------------------------------------------------
------------------
# tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── mmx64.efi
    └── ubuntu
        ├── BOOTX64.CSV
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi
 
3 directories, 8 files
----------------------
 
Nelle impostazioni UEFI quando avvii la macchina virtuale
leggi proprio "ubuntu" tra le voci che è possibile scegliere.
 
Una prova ulteriore da fare sarebbe quella del tuo caso reale:
- crei un disco virtuale da 20 o meglio 30 GB
- installi win10
- installi ubuntu piazzando il bootloader nell0unica partizione EFI che
  ci sarà già, quella del bootloader di win.
- dovrebbe filare tutto liscio
 
Come spazio win10_x64 occupa 11.7 GB circa.
Ubuntu come l'ho installato io senza aggiungere roba in fase
d'installazione siamo a circa:
-------
# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           184M  1,4M  183M   1% /run
/dev/vda2       9,7G  6,2G  3,1G  67% /
tmpfs           919M     0  919M   0% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           4,0M     0  4,0M   0% /sys/fs/cgroup
/dev/vda1        93M  7,8M   85M   9% /boot/efi
tmpfs           184M  164K  184M   1% /run/user/1000
----------------------------------------------------
 
~ 6.2 GB
 
Con 30 GB di disco virtuale vai tranquillo per far la prova.


Ciao,
grazie per tutte le preziose informazioni che mi hai dato. Quello che mi 
piace di Linux è che, ogni giorno, si impara sempre qualcosa di nuovo, 
mentre in Windows è tutto un "click and go" e la pappa è subito pronta e 
facile.
 
Per partizionare il disco fisso (HDD/SSD) in Linux, io utilizzo sempre 
Gparted (*), mentre in Win ho visto usare:
 
MiniTool Partition: 
https://www.minitool.com/
 
MiniTool Portable: 
https://www.partitionwizard.com/partitionmagic/portable-partition-magic.html
 
Paragon: 
https://www.paragon-software.com/free/pm-express/#resources
 
 
Questa mattina, ho guardato con attenzione il video di KVM, che mi hai 
segnalato e oltre ad essere bellissimo nella risoluzione, ho imparato 
delle cose nuove che mi piacciono molto, come ad esempio utilizzare 
win10 senza product key, ma in generale posso provare/avere qualsiasi 
distro. Voglio provare Qubes la quale non è live, in questo modo, con 
una macchina virtuale, la posso installare in KVM. Devo trovare delle 
guide più approfondite per questa risorsa.
Prima utilizzavo VirtualBox, che è closed-source, ma ora mi sono 
appassionatoa KVM.
 
Purtroppo, dopo aver installato KVM e provato ad installare una nuova 
macchina virtuale di Win10_x64.iso, il tentativo è fallito, sia per la 
lentezza, che per lo spazio disponibile del disco (virtuale).
 
Dove sono ora, sto utilizzando un computer poco performante, è un P4 
Dual-Core AMD a 64 bit con un SSD da 80 GB e nella Root ho solo 16 GB di 
spazio libero disponibile, comunque, domani pomeriggio farò un'altra 
prova di installazione su un computer reale. Il responsabile 
dell'Associazione di Volotari, che aiutano gli anziani, vuole fare una 
prova su un altro computer e quindi, poi ti dirò il risultato!!
 
(*) A proposito di Gparted, mi sono comperato una chiavetta da 64 Gb, in 
alluminio (no plastica), che se cade non si rompe e dopo averci 
installato Ventoy: 
https://www.ventoy.net/en/index.html
 
la chiavetta usb è diventata avviabile, dopo di che ho copiato 
all'interno una serie di distribuzioni a 32 e 64 bit (immagini.iso):
- Boot-repair-disk.iso
- Clonezilla.iso
- Emmabuntus.iso (distro ricca di software)
- g4l.iso (Ghost4Linux)
- Gparted.iso
- Linux-Lite.iso
- Pmagic_2013-08-01.iso (dal 2014 è a pagamento)
- Rescatux.iso
- Rescuezilla.iso
in questo modo mi sono costruito il mio coltellino svizzero per le 
emergenze.
 
Intanto *grazie mille* per tutte le informazioni che hai condiviso. Ora 
ho le idee un pò più chiare.
Domani pomeriggio, faccio la prova reale, che poi ti saprò dire.
 
Un cordiale saluto,
Nemo

 appassionatoa KVM.
 
VB non e` closed source.
Esiste una versione, comunemente distribuita,
che viene regolarmente compilata dai sorgenti.
 
In generale VB e` piu` pratico e "giocattoloso",
ma fa il suo sporco lavoro...
 
bye,
 
-- 
 
piergiorgio


Confermo, io su slack_14.2 non riuscivo a far girare Qemu per lo
scopo, ovvero avvio di win10 in UEFI con OVMF. Non riusciva ad avviare
neanche la ISO, arrivavo alla richiesta "press key for CD boot", ma
poi non progrediva e infine restituiva la EFI shell...
Per la cronaca ho risolto installando l'ultimo kernel, che al suo
interno contiene evidentemente una versione del modulo kvm/kvm_intel,
in cui sonostati risolti alcuni bug. Non sono così sicuro, ma questa
operazione di compilazione ultimo kernel 5.10.4, ha prodotto l'effetto
di avviare Qemu con la iso di win in UEFI, e si riesce ad arrivare in
fondo alla procedura d'installazione.
 
Nel frattempo, prima di risolvere con KVM, ho provato VirtualBox,
Più o meno mi pare simile.
L'ultima volta che lo provai mi pare non avesse il supporto per
la virtualizzazione a livello nativo della CPU, o forse ero io ad
avere un PC con CPU che non supportava quelle istruzioni.
Adesso invece ho visto che c'è in accoppiata il modulo/pacchetto:
virtualbox_kernel.
 
È equiparabile a KVM usato con virt-manager insomma...
Solo che è un attimo più speditivo (forse in certe cose anche
più limitato, ma non conosco abbastanza la virtualizzazione per
dirlo).
 
 
Comunque...
La differenza tra usare una macchina virtuale con i moduli che
sfruttano la CPU reale e non farlo è abissale. Senza di loro la
lentezza dei sistemi virtualizzati (guest) è esasperante e li
rende inutilizzabili di fatto.
Per chi ha PC vecchi con CPU che non supportano le istruzioni in
questione (cercare su google in merito) non provateci neanche.
 
Nel mio caso anche io ho un PC vetusto e le prove le ho fatte su
questo:
 
- CPU: Intel Core 2 Duo E8200 2.66 GHz
- RAM:   4 GB
- SSD: 250 GB
 
Per fare prove, con un po' di pazienza ci può stare, ma direi che
siamo già al limite. Sicuramente non va bene se dovessi fare un
uso più serio di sistemi virtualizzati.
Purtroppo con quella scheda madre sono già praticamente al limite,
più RAM non la supporta, credo che si potrebbe mettere una CPU
Core 2 Quad, ma quanto si migliorerebbe? Non varrebbe la pena credo
neanche svitare le viti dell cassone... Ma questo non c'entra con
la discussione, era solo per dare un'idea di un hardware che si
può usare al limite per fare qualche prova ancora passabile di
virtualizzazione.
Con PC più scarsi sconsiglio.
Inutile dire... o si ha un PC dismesso anche messo peggio del mio
su cui fare prove senza incasinare PC di uso quotidiano, oppure,
va bene la virtualizzazione ma solo se il PC quotidiano è messo
almeno almeno come il mio o possibilmente anche un po' meglio.
Le nozze coi fichi secchi d'altra parte riescono di rado! ;)

 spazio libero disponibile,
 
Ummm...
Perchè non incolli qui l'output di:
 
1) uname -p
 
2) free -h
 
3) df -h
 
Così ci capiamo.


#===================
    Buone Notizie
#===================
 
Ciao, oggi pomeriggio, su un computer reale, un HP Elite Desk, con 
processore Intel Core i5pro con 8 Gb di Ram, con 02 (due) SSD, sono 
riuscito (al primo colpo) ad installare Ubuntu Mate 20.04 LTS, 
naturalmente in UEFI mode only.
 
Il primo SSD da 240 Gb con Win10 e il secondo SSD da 120 Gb ho 
installato Ubuntu.
 
Procedura:
 
- Il primo disco fisso con Windows10 (sda) NON è stato toccato.
 
Dopo aver disattivato nel Setup (Bios) i vari parametri di “Secure boot” 
e “Fast boot”, ho effettuato il boot con la mia chiavetta multi-boot e 
ho caricato in ram la distribuzione Ubuntu.
 
Con Gparted, ho selezionato il secondo SSD e creato la tabella di 
partizionamento GPT, dopo di che ho creato le seguenti partizioni:
 
sdb1 = 01 Gb = Fat32 = EFI
sdb2 = 50 Gb = Ext4 = Root
sdb3 = 50 Gb = Ext4 = Home
sdb4 = 20 Gb = Non allocato (Over-Provisioning solo con SDD)
 
Infine ho installato il bootloader Grub in sdb1 = Boot/Efi di Ubuntu.
 
Alla fine della procedura di installazione, ho riavviato la macchina ed 
è andato tutto bene: è apparso grub con le varie opzioni di scelta del 
vari sistemi operativi.
 
A questo punto, ho aggiornato il sistema, installato alcuni software e 
riaggiornato ancora il tutto. Infine, ho sistemato gli ultimi dettagli 
(wallpaper, formato della data, ecc), quindi con Timeshift ho effettuato 
un backup del sistema per un eventuale ripristino alle condizioni 
iniziali di un Fresh Install.
 
Il tutto in 02 ore e 10 minuti circa.
 
Sono contento!!
 
Per cui, ora vengono i ringraziamenti…. a Joe, che con la sua passione e 
dedizione nello spiegare i concetti del nuovo UEFI e Grub, con spirito 
di condivisione, ha stimolato la mia curiosità, dissipando la maggior 
parte dei dubbi.
 
Ora ceno con calma, poi leggo le vostre risposte.
Un cordiale saluto e *grazie ancora* !!!
 
#=====================================================
Mi interessa molto il discorso di virtualizzare Win10 e Linux sullo 
stesso disco virtuale, con KVM.
Per cui le caratteristiche del mio computer dataso, sono le seguenti:
 
1) uname -p
x86_64
 
2) free -h            total        used        free      shared 
buff/cache   available
Mem:          3,7Gi       491Mi       2,2Gi        30Mi       1,0Gi 
  2,9Gi
Swap:         1,4Gi          0B       1,4Gi
 
 
3) df -h
File system     Dim. Usati Dispon. Uso% Montato su
udev            1,8G     0    1,8G   0% /dev
tmpfs           381M  1,4M    380M   1% /run
/dev/sdb1        30G   14G     14G  50% /
tmpfs           1,9G     0    1,9G   0% /dev/shm
tmpfs           5,0M  4,0K    5,0M   1% /run/lock
tmpfs           1,9G     0    1,9G   0% /sys/fs/cgroup
/dev/loop0       55M   55M       0 100% /snap/core18/1705
/dev/loop1       56M   56M       0 100% /snap/core18/1944
/dev/loop2       32M   32M       0 100% /snap/snapd/10492
/dev/loop3       32M   32M       0 100% /snap/snapd/10707
/dev/loop4      128K  128K       0 100% /snap/software-boutique/54
tmpfs           1,9G  4,0K    1,9G   1% /tmp
/dev/loop5       15M   15M       0 100% /snap/ubuntu-mate-welcome/524
/dev/loop6       15M   15M       0 100% /snap/ubuntu-mate-welcome/575
tmpfs           1,9G     0    1,9G   0% /var/tmp
/dev/sdb2        30G   14G     15G  48% /home
tmpfs           381M   28K    381M   1% /run/user/1000
#=====================================================
 
 
 

 /dev/sdb2        30G   14G     15G  48% /home
 
Vedi, hai 30 GB liberi.
Ma sono spezzati su due partizioni diverse, e se volessi
fare ad esempio una macchina virtuale da 20GB non potresti.
 
Fare tante partizioni con punti di montaggio differenti,
ha un senso, ma per ambiti particolari. Per uso desktop,
se già si ha poco spazio come nel tuo caso, meglio una
root unica tutto in "/" e via, ovviamente lasci a parte
la partizione EFI, quella non c'entra ma è poca roba.
 
Potresti spstare quanto più possibile su altro disco
se ne hai uno, tipo esterno o anche intrno, magari un
HDD, anche lento ma capiente...
 
Ma prima vediamo il processore, se già quello è messo
male non ne vale la pena.


Ciao, io ho digitato al prompt come:
utente ($) uname -p e anche come
root (#) sudo uname -p e anche
utente ($) sudo -s
[sudo] password di nemo:
root@nemo:/home/nemo# uname -p
ma mi restituisce sempre x86_64
Comunque, scrivo qui di seguito l’output dei comandi che mi hai consigliato.
 
#------------------------------------------------------------------------
nemo@nemo:~$ lscpu
Architecture:                    x86_64
CPU op-mode(s):             32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                  40 bits physical, 48 bits virtual
CPU(s):                            2
On-line CPU(s) list:         0,1
Thread(s) per core:          1
Core(s) per socket:          2
Socket(s):                        1
NUMA node(s):              1
Vendor ID:                       AuthenticAMD
CPU family:                    15
Model:                             107
Model name:                   AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
Stepping:                         1
CPU MHz:                         1000.000
CPU max MHz:                 2100,0000
CPU min MHz:                 1000,0000
BogoMIPS:                        4189.40
Virtualization:                    AMD-V
L1d cache:                        128 KiB
L1i cache:                        128 KiB
L2 cache:                         1 MiB
NUMA node0 CPU(s):               0,1
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:          	    Not affected
Vulnerability Mds:             	  Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers 
and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, STIBP 
disabled, RSB filling
Vulnerability Srbds:             	Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic 
sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx 
mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl cpuid pni c x16 
lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch vmmcall lbrv
 
#------------------------------------------------------------------------
nemo@nemo:~$ cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping	: 1
cpu MHz		: 1000.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp 
lm 3dnowext 3dnow rep_good nopl cpuid pni cx16 lahf_lm cmp_legacy svm 
extapic cr8_legacy 3dnowprefetch vmmcall lbrv
bugs		: fxsave_leak sysret_ss_attrs null_seg swapgs_fence amd_e400 
spectre_v1 spectre_v2
bogomips	: 4189.40
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
 
processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping	: 1
cpu MHz		: 1000.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp 
lm 3dnowext 3dnow rep_good nopl cpuid pni cx16 lahf_lm cmp_legacy svm 
extapic cr8_legacy 3dnowprefetch vmmcall lbrv
bugs		: fxsave_leak sysret_ss_attrs null_seg swapgs_fence amd_e400 
spectre_v1 spectre_v2
bogomips	: 4189.41
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
 
#------------------------------------------------------------------------
Certe volte per avere dettagli sulla macchina, io utilizzo anche il 
comando $inxi -Fxz
 
System:
   Kernel: 5.4.0-59-generic x86_64 bits: 64 compiler: gcc v: 9.3.0
   Desktop: MATE 1.24.0 Distro: Ubuntu 20.04.1 LTS (Focal Fossa)
Machine:
   Type: Desktop System: Hewlett-Packard
   product: HP Compaq dc5750 Small Form Factor v: N/A serial: <filter>
   Mobo: Hewlett-Packard model: 0A64h serial: <filter> BIOS: 
Hewlett-Packard
   v: 786E3 v02.10 date: 01/25/2007
CPU:
   Topology: Dual Core model: AMD Athlon 64 X2 4000+ bits: 64 type: MCP
   arch: K8 rev.F+ rev: 1 L2 cache: 1024 KiB
   flags: lm nx pae sse sse2 sse3 svm bogomips: 8378
   Speed: 1000 MHz min/max: 1000/2100 MHz Core speeds (MHz): 1: 1000 2: 
1000
Graphics:
   Device-1: AMD RS482/RS485 [Radeon Xpress 1100/1150]
   vendor: Hewlett-Packard DC5750 Microtower driver: radeon v: kernel
   bus ID: 01:05.0
   Display: x11 server: X.Org 1.20.8 driver: ati,radeon
   unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz
   OpenGL: renderer: ATI RS480 v: 2.1 Mesa 20.0.8 direct render: Yes
Audio:
   Device-1: AMD SBx00 Azalia vendor: Hewlett-Packard DC5750 Microtower
   driver: snd_hda_intel v: kernel bus ID: 00:14.2
   Sound Server: ALSA v: k5.4.0-59-generic
Network:
   Device-1: Broadcom and subsidiaries NetXtreme BCM5755 Gigabit 
Ethernet PCI
   Express
   vendor: Hewlett-Packard DC5750 Microtower driver: tg3 v: 3.137 port: 
1100
   bus ID: 3f:00.0
   IF: enp63s0 state: down mac: <filter>
   IF-ID-1: virbr0 state: down mac: <filter>
   IF-ID-2: virbr0-nic state: down mac: <filter>
Drives:
   Local Storage: total: 307.42 GiB used: 27.12 GiB (8.8%)
   ID-1: /dev/sda vendor: Maxtor model: STM3250820AS size: 232.89 GiB
   ID-2: /dev/sdb vendor: Intel model: SSDSA2M080G2GC size: 74.53 GiB
Partition:
   ID-1: / size: 29.19 GiB used: 13.72 GiB (47.0%) fs: ext4 dev: /dev/sdb1
   ID-2: /home size: 29.67 GiB used: 13.39 GiB (45.1%) fs: ext4
   dev: /dev/sdb2
Sensors:
   System Temperatures: cpu: 29.0 C mobo: N/A
   Fan Speeds (RPM): N/A
Info:
   Processes: 176 Uptime: 44m Memory: 3.72 GiB used: 903.2 MiB (23.7%)
   Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: inxi.sh
   inxi: 3.0.38
 
#------------------------------------------------------------------------
 
Mentre sui dettagli dei dischi e partizioni, uso il seguente comando:
# lsblk -n -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL;
*********************************************************
Le partizioni sono le seguenti:
=========================================================
NAME  FSTYPE   SIZE  MOUNTPOINT   LABEL
=========================================================
loop0  squashfs    55M /snap/core18/1705
loop1  squashfs  55,4M /snap/core18/1944
loop2  squashfs  31,1M /snap/snapd/10492
loop3  squashfs  31,1M /snap/snapd/10707
loop4  squashfs    16K /snap/software-boutique/54
loop5  squashfs  14,9M /snap/ubuntu-mate-welcome/524
loop6  squashfs  14,9M /snap/ubuntu-mate-welcome/575
sda             	232,9G
├─sda1 ntfs    29,3G                        Win7
└─sda2 ntfs     203,6G                      Archivio200
sdb                    74,5G
├─sdb1 ext4     29,8G /
└─sdb2 ext4     30,3G /home
sr0            	   1024M
 
#------------------------------------------------------------------------
 
Quali sono i minimi requisiti hardware per avere una buona o accettabile 
virtualizzazione?

 virtualizzazione?
 
Dipende.
 
Se devi virtualizzare un ARM su un x86 allora
serve una CPU capace.
 
Se devi virtualizzare un x86 su un x86, allora
direi che un multicore sia sufficiente.
 
Generazioni relativamente recenti di CPU x86
supportano la virtualizzazione in maniera piu`
"protetta", ma questo non e` una necessita`.
Dipende da cosa serva ed in che ambiente sia
previsto funzioni.
 
bye,
 
-- 
 
piergiorgio

 virtualizzazione?
 
Dipende dallo scopo come ti ha già risposto Piergiorgio, se devi testare
una ISO perché vuoi accertarti che fa il boot, allora va già bene il tuo
PC. Se vuoi capire come creare una versione d'installazione di un
sistema e poi avviarlo in macchina virtuale, allora ci può stare.
 
Se vuoi far girare un software, magari pesante in un sistema
virtualizzato allora lascia perdere. Se devi simulare una rete di
PC con N macchine virtuali, che fanno varie cose, anche lì mi sa
che ti serva qualcosa di più del tuo ferro vecchio.
 
Come sempre in queste cose, parti da uno scopo, e poi cerca informazioni,
anche qui, ma forse trovi pareri più informati anche su it.hardware o su
qualche forum dedicato all'argomento virtualiazzazione.

 
 
Poichè la discussione si sta spostando su un argomento diverso da quanto 
scritto in oggetto, in quanto l’installazione con Uefi sembra risultare 
risolta, io terminerei questo thread, con la parola:
** Risolto **
 
Ma, avrei un’ultima domanda:
 
Per convenzione, esistono delle guide ufficiali open-source da 
consultare, in base ai vari argomenti, prima di iniziare a fare ricerche 
nei vari forum, blog di tutto il mondo?
 
Se abitassimo vicini, vi offrirei una birra o una pizza, ma posso dirvi 
solo Grazie di tutto!
Un cordiale saluto,
Nemo

 Un cordiale saluto
 
Non preoccuparti tanto per il momento dover rimettere la mascherina
ad ogni sorso e ad ogni morso non sarebbe il massimo in ogni caso!! :( :(

 Aspettati una grossa lentezza, e ricordati di attivare in ogni salsa,
 
Per quale motivo dovrebbe esservi
"una grossa lentezza"?
Se virtualizza x86 su x86 va veloce
tanto quanto la CPU sottostante.
 
Quello che crea problemi sono le
periferiche, dischi, rete, etc.
Questi potrebbero risultare piu`
lenti del PC nativo.
 
Ha un dual core, un core per la
virtualizzazione, un altro per il
resto.
 
bye,
 
-- 
 
piergiorgio


Grazie mille di tutto!!!!!!!!!!!!
Nemo


Con 4GB di ram, dedicandone 1.9 al guest non vai veloce, ma dipende
sempre cosa uno ci deve fare, poi capisci bene che dedicando parte
della CPU alla virtualizzazione, e parte al sitema host, che anche
lui fa cose... La coperta diventa più corta.
Io vedo una bella differenza tra il sistema nativo senza macchine
virtuali al lavoro e quello virtualizzato. Non solo, ma anche l'host
ovviamente va a rilento quando il guest richiede più potenza di
calcolo.
 
Con una CPU più potente noti meno questo degrado probabilmente, ma
col mio Core 2 Duo è evidente (e credo anche o con l'Athlon 4000+).
 
Disabilitando KVM comunque è davvero un altro pianeta. Avrà il suo
perché anche la virtualizzazione software d'altro canto, ma se non
se ne ha motivo è da evitare assolutamente tanto è esasperante.

 se ne ha motivo è da evitare assolutamente tanto è esasperante.
 
Continuo a non vedere il problema.
Il codice x86, che sia nativo o
virtualizzato, sempre uguale va.
 
Quello che crea problemi e` l'I/O.
Questo perche` il sistema deve andare
avanti ed indietro a mappare le funzioni
di I/O dalla virtualizzazione al sistema
reale, senza avere un hypervisor che
semplifichi la vita.
 
D'altro canto, il punto della questione e`
quanto I/O si faccia...
 
bye,
 
-- 
 
piergiorgio