Copiare sistema da immagine virtuale a partizione fisica

[joe]

Domanda un po' incasinata, ma forse abbastanza banale alla fine...

Ho due SSD (su un vecchio cassone ancora basato su BIOS, quindi no UEFI):
- il primo ospita Slackware, ospita anche una partizione per grub con tutto l'occorrente per l'avvio.
- il secondo per dati, partizione unica ext4

Ho anche una macchina virtuale che uso con libvirt/virt-manager in cui è virtualizzato windows 7,
l'immagine del disco virtuale è in formato qcow.

Siccome avrei necessità di fare un paio di test con windows installato fisicamente sul disco, quindi in multiboot con slackware in pratica, e siccome ho appunto due dischi, pensavo che potrei piazzare una partizione da circa 30 GB sul disco dati, mettervi dentro windows e delegare il dualboot al BIOS, senza scomodare il grub di slackware ecc...

Poi per "semplificarmi" la vita volevo fare un esperimento:
siccome ho già un sistema windows installato in macchina virtuale, mi chiedevo se fosse possibile copiarne ad esempio il volume di sistema "C:" e piazzarlo nella partizione fisica da 30 GB di cui sopra. Vado a memoria ma il sistema virtualizzato dovrebbe essere sui 20 GB, quindi al limite poi con partimage o anche dal disk manager di win si dovrebbe riuscire ad estendere per aderire ai 30 GB.

Il punto su cui ho qualche dubbio è proprio come copiare la partizione di sistema dall'immagine QCOW (ma anche se fosse RAW) alla partizione reale su disco.

Per il momento mi fermo qui in attesa di qualche vostro commento.

[brg]

Ho fatto una cosa del genere con Xubuntu. Lo avevo su di una macchina virtuale e da lì l'ho copiato in una partizione fisica. Non so se la stessa cosa sia fattibile con Windows, cioè non so se Windows abbia bisogno di crearsi qualche partizione nascosta particolare o di inserire dei dati particolari nel MBR o nella partizione di sistema.

Comunque per copiare da un disco virtuale ad uno fisico, bisogna prima montare il disco virtuale, cioè montare l'immagine del disco nell'albero delle directory; poi fare una copia di basso livello con dd; poi eventualmente rimaneggiare le partizioni per far tornare le dimensioni. A grandi linee.

Se ti interessano più dettagli, mi ero fatto un promemoria delle operazioni compiute e posso riportarlo qui.

[joe]

Sì, sarebbe interessante, anche senza entrare esageratamente nel dettaglio: in particolare se ho ben capito, più che "montare" l'immagine del disco si tratta di "agganciarla" al sistema come fosse un dispositivo tipo "/dev/nbd0"... mi riferisco all'impiego del modulo "nbd", così al volo ad esempio avevo trovato questa soluzione:

https://unix.stackexchange.com/question ... cow2-image

A quel punto si può fare anche il mount delle partizioni (/dev/nbd0p1 oppure p2, p3, ecc...).
Nel mio caso potrei forse anche fare la copia del file system, ovvero:

• creo sul disco di destinazione la partizione di 30GB, e la formatto in NTFS
• poi aggancio l'immagine del disco virtuale CQOW via NBD
• eseguo il mount della partizione "C:", quella di sistema del windows da copiare
• eseguo la copia con un bel "cp" liscio
• e a questo punto dovrei ritrovarmi windows sulla partizione fisica dell'SSD nel suo bravo filesystem NTFS

A questo punto il problema si riduce, si fa per dire, a come farlo partire.
Così a braccio se non ricordo male si dovrà passare per "bcdboot".
La complicazione, o meglio la mia ignoranza in merito, riguarda l'organizzazione del disco di destinazione, che attualmente ha tabella delle partizioni GPT e un'unica partizione, l'avevo preparato così perché l'idea era quella di utilizzarlo per dati e per estendere pezzi del mio sistema principale Slackware e fare spazio sulla sua partizione di root:

Codice: Seleziona tutto

# fdisk -l /dev/sdc
Disk /dev/sdc: 465,76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: ecc-ecc-ecc...

Dispositivo Start      Fine   Settori   Size Tipo
/dev/sdc1    2048 976773134 976771087 465,8G Linux filesystem

Nell'altro disco, quello di sistema slackware diciamo avevo dovuto adottare un partizionamento più complicato specie nella parte iniziale:

Codice: Seleziona tutto

Dispositivo     Start      Fine   Settori   Size Tipo
/dev/sda1        2048      4095      2048     1M BIOS boot
/dev/sda2        4096    413695    409600   200M EFI System
/dev/sda3      413696 438951935 438538240 209,1G Linux filesystem
/dev/sda4   479912639 480112639    200001  97,7M Linux filesystem

Lasciando perdere la "EFI System" che su questo PC di fatto non serve perché non supporta UEFI...
La cosa che manca al secondo disco è la partizioncina iniziale "BIOS boot", in cui se ben ricordo dovrebbe andare ad installarsi il boot code di Grub, almeno nel mio caso avevo installato grub.
Per le macchine UEFI credo che questo non serva perché Grub va a piazzarsi nella partizione "EFI System" e il boot non è gestito dal primo pezzo del disco.
Nella partizione "sda4" c'è solo la configurazione di Grub e file annessi (invece di essere in /boot/grub l'ho separata: in caso di multiboot se si buttasse via la partizione di slackware, continuerebbe a stare in piedi il multiboot).

Mi viene in mente che forse potrei modificare il grub.cfg e aggiungere una sezione per l'eventuale nuovo windows, in modalità chainload o come si chiama... forse è più facile che andare a modificare la configurazione del disco dati. Alla fine, anche ai tempi delle vecchie configurazioni BIOS + MBR si aveva il PC con windows e volendo fare il dualboot, si piazzava lilo nel MBR andando a rasare il bootloader di windows...

In soldoni, se abbiamo già Grub che avvia le varie partizioni di sistema, potrebbe bastare semplicemente aggiungervi la partizione di windows senza armeggiare con "bcdboot" o altri amenicoli microsoft che potenzialmente potrebbero incasinare le partizioni esistenti.

Chiedo conferme, perché sono anni che non ne ho a che fare con dualboot win+linux.

[brg]

Allora sinteticamente, dopo avere montato il disco virtuale su una directory, diciamo /mnt/srg:

1. ho copiato i file da una partizione installata su qemu ad una partizione reale montata in /mnt/dst:

   Codice: Seleziona tutto

   cp -afv /mnt/srg/* /mnt/dst

2. da un sistema operativo Linux funzionante ho cambiato root:

   Codice: Seleziona tutto

   mount -o bind /dev /dst/dev
   mount -o bind /sys /dst/sys
   mount -o bind /proc /dst/proc
   chroot /mnt/dst
   

3. ho installato grub nella partizione:

   Codice: Seleziona tutto

   chattr -i /boot/grub/i386-pc/core.img
   grub-install --target=i386-pc --recheck --debug --force /dev/sda2
   chattr +i /boot/grub/i386-pc/core.img
   

4. ho rigenerato il menù di grub con grub-mkconfig:

   Codice: Seleziona tutto

   grub-mkconfig -o /boot/grub/grub.cfg

5. ho modificato a mano i dischi indicati in /boot/grub/grub.cfg (perché ovviamente non corrispondevano a quelli generati col chroot);
6. ho installato grub nel MBR, quando ho fatto l'aggiornamento di sistema.

Da tutto questo puoi capire che il grosso del lavoro è stato far partire il sistema operativo, dopo averlo copiato. A te in realtà di tutto questo ti interessano giusto il passo 1 ed il passo 0, cioè il montaggio della partizione virtuale. In realtà non mi ricordo, non me lo sono scritto, se ho usato NBD oppure se ho convertito la partizione in RAW e poi l'ho montata come dispositivo di loop: mi è capitato di usare entrambi i metodi in passato e non mi ricordo in questo caso specifico che cosa ho fatto.

[joe]

OK, leggendo l'inizio mi stavo proprio chiedendo quello... cioè come hai fatto a montare la "partizione virtuale".
Va be' sì, non sono cose che si fanno tutti i giorni, anche a me capita di scordamele alla grande.

In loop, non so se ti dice niente, ma siccome l'immagine contiene di fatto un intero disco virtualizzato e non una semplice partizione o un ancor più semplice file system, se ben ricordo non è possibile (e non avrebbe senso) montarlo in loop direttamente.
Mi pare di ricordare qualche esperimento di lustri fa, che prevedeva per lo scopo il comando "losetup" o "kpartx" o partx come si chiamava. In pratica questi tools servivano a registrare nel kernel il nuovo dispositivo "fake".
Però non ricordo di averli utilizzati su immagini create con libvirt, qemu o simili... è probabile che la conversione da QCOW2 a RAW delle immagini disco sia necessaria per poi maneggiarle con losetup o partx, ma quello è il meno.

Niente, farò qualche prova. Grazie ancora per le risposte in ogni caso.

[ponce]

anch'io qui, per montare immagini qcow2 ho usato praticamente sempre una procedura simile a quella descritta qui (con nbd, come brg)

https://gist.github.com/shamil/62935d9b456a6f9877b5