Clark's Home page

Tecnicismi vari di un Sysadmin Linux ma anche qualcosa della sua vita

FrankenWindows —

In tutta onestà non so in che categoria inserire questo post.
È sicuramente un tecnicismo, ma è una cosa così folle che non so dove metterlo dovrei creare una categoria voodoo immagino.
Antefatto:
ad agosto cambieremo i server in azienda e dovremo migrare tutte le VM dal vecchio ambiente di produzione al nuovo, non sono previste modifiche alle VM semplicemente verranno copiate sul nuovo ambiente di produzione e riaccese.
I dinosauri come il sottoscritto fanno sempre dei test prima di fare cose molto serie come una migrazione, l’ambiente di test serve esattamente a quello.
Quindi aggiornato l’ambiente di test a daedalus (Devuan 5) ho provato col solito sistema del dd a copiare una macchina Linux e una macchina Windows in ambiente di test per vedere se tutto funzionava a dovere e parafrasando una simpaticissima Signora che seguo su una web radio e che fa un programma di dediche/richieste “rottura che va rottura che arrivaaaa” puntualmente… Prima sorpresa, la grammatica dei file di configurazione è cambiata da xen versione 4.14.6 (Devuan Chimaera) a xen versione 4.17.5 (Devuan Daedalus) e naturalmente la cosa non è documentata sul sito ufficiale xenproject.org.
Quindi per portare un esempio reale e vale a dire una macchina Windows che si chiama corsaro2 il file di configurazione era:

# start

name = “corsaro2”
boot = “c”
#boot = “d”
builder = ‘hvm’
firmware= ‘uefi’
device_model_version = ‘qemu-xen’ <– questa riga non fa partire la macchina
device_model_override = ‘/usr/bin/qemu-system-x86_64’ <– questa riga non fa partire la macchina
vif = [ ‘mac=00:16:3e:7d:91:16, bridge=xenbr0, model=e1000’ ]
#disk = [ ‘phy:/dev/xen1/corsaro2,xvda,w’, ‘file:/home/xen/cdrom/WIN10ELTS.iso,xvdc:cdrom,r’ ]
#disk = [ ‘phy:/dev/xen1/corsaro2,xvda,w’, ‘file:/home/xen/cdrom/PV-8.2.2.iso,xvdc:cdrom,r’ ]
#disk = [ ‘phy:/dev/xen1/corsaro2,xvda,w’, ‘file:/home/xen/cdrom/clonezilla.iso,xvdc:cdrom,r’ ]
disk = [ ‘phy:/dev/xen1/corsaro2,xvda,w’ ]
memory = 8192
vcpus = 4
on_poweroff = ‘destroy’
on_reboot = ‘restart’
on_crash = ‘restart’
vga = ‘stdvga’
videoram = 16
sdl = 0
vnc = 1
vnclisten = “0.0.0.0”
vncdisplay = 16
vncpasswd = ”
vncunused = 0
serial = ‘pty’
tsc_mode = “native”
keymap = ‘it’
usbdevice = ‘tablet’

diventa:
# start

name = “corsaro2”
boot = ‘cd’
type = ‘hvm’
vif = [ ‘mac=00:16:3e:7d:91:16, bridge=xenbr0’ ]
acpi = ‘1’
apic = ‘1’
usb = ‘1’
vncconsole = ‘1’
#disk = [ ‘phy:/dev/xen1/corsaro2,hda,w’, ‘file:/home/xen/cdrom/WIN10ELTS.iso,hdc:cdrom,r’ ]
#disk = [ ‘phy:/dev/xen1/corsaro2,sda,w’, ‘file:/home/xen/cdrom/clonezilla.iso,hdc:cdrom,r’ ]
disk = [ ‘phy:/dev/xen1/corsaro2,sda,w’ ]
memory = 8192
vcpus = 4
on_poweroff = ‘destroy’
on_reboot = ‘restart’
on_crash = ‘restart’
vga = ‘stdvga’
sdl = 0
vnclisten = “0.0.0.0”
vncdisplay = 16
vncpasswd = ”
vncunused = 0
serial = ‘pty’

eliminate le due righe incriminate
e fatta partire la macchina mi collego via vnc per vedere che tutto sia a posto e trovo la macchina in crash, mi dico qualcosa sarà andato storto nel dd è una macchina windows forse è meglio usare clonezilla e così faccio per ottenere alla fine lo stesso risultato.
Mentre sono collegato via vnc mi rendo conto che la macchina fa reboot ogni 30-40 s uh? M.C.C.?
Guardo, cerco, limo la configurazione, mi procuro un mal di testa di quelli fotonici ma non ne esco.
In rete non trovo niente di simile e quindi decido di iscrivermi alla ML Xen-users e chiedo li spiegando cosa mi succede.
La prima risposta che ricevo è da fermarmi il cuore per 5 minuti, si è un problema noto con Debian 12 e derivate c’è un bug aperto dal 2022 e a tutt’oggi irrisolto https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050030.
In parole povere il pacchetto che fornisce il firmware UEFI è buggato e quindi la macchina crasha di continuo.
Mi tengo per me le considerazioni sugli sviluppatori/manutentori di Debian e vi lascio immaginare la sequela di anatemi e oscenità varie e assortite che ho detto con una velocità che avrebbe fatto vergognare una mitragliatrice leggera.
Visto che non sono in grado di scrivere un firmware funzionante ne conosco qualcuno che lo sappia fare dovevo trovare una soluzione.
Le possibilità sono:
a) restare su chiamera anche per i prossimi 3 anni a noi non cambierebbe la vita ma non risolveremmo il problema lo sposteremmo solo nel tempo e nel 2028 data prevista per il prossimo cambio server useremmo un SO di sette anni col serio rischio che non riconosca l’hardware di quell’epoca
b) rifare le macchine windows che hanno uefi con una versione di win10 ELTS che non usi uefi come avvio (la versione 2019 di ELTS usa ancora bios) però si tratta di reinstallare tutti i software del caso che non abbiamo fatto noi ma aziende esterne, quindi ripagare un lavoro già fatto.
Parecchio scoraggiato e vista l’ora mi avvio verso casa, ovviamente ci rimugino sopra e mi viene un idea da matti, verifico con diskpart una macchina windows uefi e vedo che ha tre partizioni, ne verifico una senza e ne ha due mi dico ma se io con clonezilla copio solo la partizione con il sistema operativo e i programmi da una macchina con uefi e sempre con clonezilla la forzo sulla partizione più grande di una macchian creata apposta con il sitema operativo che parte con bios?

Non funzionerà mai ma tanto con le VM anche se va male butto via e rifaccio, detto e fatto il giorno dopo in ambiente di test mi creo le condizioni per provare e contro ogni mia aspettativa la cosa funziona.
Di seguito i passi che dopo alcune prove hanno dato il risultato desiderato
Sulla macchina da esportare:
a) sfc /scannow
b) chkdsk /f (e successivo riavvio)
c) spegnere la macchina e riavviarla facendola partire dalla iso di clonezilla
d) clonare la partizione più grande e salvarla via ssh da qualche parte.
Sulla macchina in cui importare:
a) con lvm creare un volume di pari dimensioni o meglio leggermente maggiore (ho usato 5GB)
b) installare la macchina con win10 ELTS 2019
c) spegnere la macchina appena finita e riaccenderla con clonezilla
d) fare restore della partizione clonata sulla partizione di dimensione maggiore
e) riaccendere la macchina e ripetere le operazioni sfc /scannow e chkdsk
Ripeto contro ogni mia aspettativa e giuro su quanto ho di più sacro non ci avrei scommesso una lira che fosse una la macchina parte senza nessun problema.
Dal che mi viene da pensare che è solo l’installatore “nuovo” a richiedere l’uefi, ma poi Windows se non lo trova si comporta normale e ci aggiungerei un per mia grande fortuna.
Da oggi in poi potete tranquillamente chiamarmi Doctor Frederaik Frankenstin

 

 

 


Categorised as: filesystem | virtualizzazione | Windows | Work

Comments are disabled on this post


Comments are closed.


Hide picture