Possiamo utilizzare la nostra immagine iso in molteplici situazioni:

• sperimentare le possibilità della nostra iso creando all'interno di una installazione di Proxmox VE una VM abilitata per la virtualizzazione nested;
• utilizzare egg-of-debian-bullseye-pve per avviare un server Proxmox e montare una VM dello stesso.
• installazione Proxmox VE completa di Workstation;

Primi passi​

Per sperimentare, la possibilità più semplice è quella di creare una VM con processore host, allo scopo di permettere la virtualizzazione nested.

Andiamo quindi a creare la nostra macchina, non servirà neppure un volume di installazione, in quanto utilizzeremo la VM solo in modalità live.

Creazione di real-storage​

Una volta avviata la nostra live con proxmox, dovremo naturalmente create uno storage reale, dove avremo i dischi e le iso delle nostre macchine virtuali.

Per simulare la presenza di uno storage sulla nostra live, andremo a montare con sshfs lo storage della installazione ospitante, normalmente presente in '''/var/lib/vz```

mkdir /real-storage
sshfs root@192.168.61.2:/var/lib/vz /real-storage

Vediamo cosa contiene il nostro storage:

dump  images  private  snippets  template

Non ci resta che montare questo real-storage sulla nostra live, attraverso l'interfaccia di Proxmox-VE.

Selezioniamo data center, quindi "Storage" e clicchiamo su Add. Andremo ad aggiungere lo storage come directory.

Abbiamo visto che il nostro "real storage" contiene dump images private snippets template per cui nel nostro storage configuriamo:

Disk Imange, ISO image, tralasciando il resto.

Queste sono le nostre immagini delle VM dell'ospite

E quest'altre le varie immagini iso presenti sull'host

Creare una VM sulla live utilizzando lo storage-real​

A questo punto non ci resta che copiare la configurazione della macchina che ci interessa, dall'installazione reale alla nostra home:

scp root@192.168.61.2:/etc/pve/qemu-server/300.conf .

ed otterremo il seguente file di configurazione:

bios: ovmf
boot: order=scsi0;ide2;net0
cores: 2
efidisk0: local:300/vm-300-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: local:iso/archlinux-2022.02.01-x86_64.iso,media=cdrom
memory: 8192
meta: creation-qemu=6.1.1,ctime=1644734076
name: kisslinux
net0: virtio=96:2F:E5:8A:35:3D,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local:300/vm-300-disk-1.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=81f92f87-08cd-4e1b-bc0a-bc4f16d2f409
sockets: 2
vga: qxl
vmgenid: fa898e0a-1d56-4e1c-bbda-1aa489d5dae4

andiamo a sostituire, allo storage local lo storage real-storage, come nell'esempio seguente:

bios: ovmf
boot: order=scsi0;ide2;net0
cores: 2
efidisk0: real-storage:300/vm-300-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: real-storage:iso/archlinux-2022.02.01-x86_64.iso,media=cdrom
memory: 8192
meta: creation-qemu=6.1.1,ctime=1644734076
name: kisslinux
net0: virtio=96:2F:E5:8A:35:3D,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: real-storage:300/vm-300-disk-1.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=81f92f87-08cd-4e1b-bc0a-bc4f16d2f409
sockets: 2
vga: qxl
vmgenid: fa898e0a-1d56-4e1c-bbda-1aa489d5dae4

Copiamo la configurazione su /etc/pve/qemu-server ed opla, la nostra macchina è apparsa.

Per renderla avviabile, dal momento che non abbiamo ancora creato un bridge per la rete, per semplicità rimuoveremo la stessa.

La nostra immagine sta facendo girare una VM del sistema ospitante!

A che serve? Ancora non lo sò, ma è davvero carino e potente.

Per chi volesse sperimentare sull'argomento, è a disposizione una egg-of-debian-bullseye-pve con la quale è stato eseguito l'esperimento ed, aventualmente, sono disponibili anche immagini di VM.

E' da qualche tempo che sto pensando di rendere eggs utile per effettuare backup,

In effetti non sarebbe troppo difficile, eggs non effettua il salvataggio dei dati utente, per una decisione di progetto: impedire che dati privati vengano esposti in pubblico.

Pur tuttavia, un collega indiano, qualche tempo fa mi propose di utilizzare eggs per spostare delle macchine server da una serverfarm ad un'altra, in particolare dalla sede a Kerala a quella in Germania e viceversa.

Naturalmente i dati non dovrebbero essere esposti su internet, trattandosi anche di dati privati.

Immaginai che eggs, una volta finito il lavoro necessario alla costruzione di una iso, controllasse la dimensione dei dati da salvare dalle rispettive home degli utenti e server, quindi costruisse un volume LUKS di adeguate dimensioni, e ci copiasse questi dati. Infine copiasse nella iso il volume luks stesso.

In effetti già da qualche tempo, eggs ha questa "capacità". La procedura però - poco testata - aveva dei problemi che, finalmente, sto cercando di risolvere: in primo luogo la stima dei dati, tra blocchi e dimensioni risultava a volte errata e, quindi, il backup veniva interrotto; inoltre, il backup avveniva solo sotto la directory /home, limitando quindi la possibilità di salvare dati dei server.

Immaginando unaa soluzione, abbiamo due casistiche differenti: creare una iso del nostro server con una configurazione di base e che, quindi contiene necessariamente anche le home dei servizi, ed un'altra nella quale abbiamo un server con dati reali e quindi privati, nella quale quindi, gli stessi devono essere presenti in modalità criptata.

Nel primo caso, server con una configurazione di base, creaimo la iso direttamente: nessun backup è necessario, in quanto i dati delle home dei servers vengono comunque copiati nella iso.

Per il secondo caso - backup - invece, dobbiamo:

Prima fase: analisi ed esclusione dei dati privati​

• analizziamo /etc/password allo scopo di rilevare le varie home significative. C'è anche un nuovo comando in eggs che permette di farsi subito un'idea: eggs analyze
• creiamo una lista di esclusione aggiuntive per le home degli utenti e servizi rilevati.

Seconda fase: creazione del filesystem.squashfs​

Procediamo normalmente per la creazione del filesystem.squashfs compresso, naturalmente utilizzeremo se del caso le nuove esclusioni per i dati privati.

Terza fase: backup dei dati​

• dopo la costrunzione del filesystem.squash si torna ad analizzare /etc/passwd e decidere le dimensioni necessarie:
• preparazione di un un file per il volume luks-eggs-backup
• creazione e montaggio del volume luks-eggs-backup e copia delle home sia dei server che degli utenti nella cartella demoninata: ROOT del volume stesso;
• salvataggio dei file: /etc/passwd, /etc/shadow ed /etc/groups nella root del volume luks;
• chiusura e smontaggio del volume luks e copia del file risultante nella iso

A questo punto ho aggiunto un ulteriore comando ad eggs: eggs syncfrom.

Questo comando non fa altro che realizzare il processo inverso e, se chiamato da un sistema live, sostituisce nel sistema di destinazione dei file cruciali per il suo funzionamento e, cioè /etc/passwd, /etc/shadow ed /etc/groups, quindi, carica tutte le home salvate in precedenza.

Naturalmente, potrebbe essere conveniente inviare i dati da un posto ad un altro in due differenti file, ovvero, da una parte la normale iso contenente la configurazione di base e dall'altra il volume di backup.

Dovremmo, quindi, andare ad utilizzare il comando syncfrom su una macchina installata e fornire come parametro il percorso per il volume luck-eggs-backup precedentemente salvato. Naturalmente in tal caso NON potremo sostituire i file /etc/passwd, /etc/shadow ed /etc/groups, quindi la macchina accetterà soltanto i dati presenti sulle home di servizi ed utenti.

Il sistema, dovrebbe, comunque funzionare, presentare le stesse configurazioni di base ma andrebbe a sostituire le home precedenti con i nuovi dati. In teoria, questo dovrebbe fornire un aggiornamento ed allineamento con il sistema salvato.

A questo punto è nato anche un ulteriore comando: eggs syncto che, senza creare la iso del sistema, crea solamente il volume di backup.

It's amazing how after so much effort to create a unique remastering tool, it turns out well.

I've just released the eggs 9.0.10 version, the first one running on Debian both in standard and UEFI BIOS mode.

Well, just after publishing it, I restored a VM with manjaro xfce - the last version - give the folloging commands:

• sudo pamac upgrade
• sudo pamac install base-devel
• git clone https://github.com/pieroproietti/penguins-eggs
• cd penguins-eggs
• makepkg -sri
• sudo eggs calamares --install
• sudo eggs config
• sudo eggs dad -d
• sudo eggs produce --fast

After that I exported the resulting iso in my host and put it in another VM enabled with UEFI.

That's the results:

Sono due giorni che sto combattendo con UEFI. Ho sempre cordialmente odiato UEFI, purtroppo mi ci tocca convivere!

Per di più utilizzando e - non potendo fare altrimenti delle VM - vengono aggiunti anche i problemi della virtualizzazione.

In effetti, l'anno scorso dopo un duro rincorrere i codici del buon refracta-snapshot-base di fsmithred di cui potete vedere questa intervista del 2019. Refracta, in qualche modo ha fatto la Storia - visto che da questa base si sono sviluppati almeno altri tre progetti: l'installer di Devuan dello stesso autore, quello di MX-linux mx-remaster ed il mio penguins-eggs.

Leggendo, sforzandomi di capire la logica, e ritraducendo il tutto in un misto di typescript e comandi di terminale - più gestibile per i miei gusti - ero riuscito a farlo funzionare.

Non uso molto UEFI però, normalmente sulla stazione di lavoro composta da Proxmox VE sul quale ho installato una interfaccia grafica cinnamon ed i strumenti di sviluppo, le macchine nascono con BIOS standardd e l'UEFI ha rappresentato sempre - come dire - una inutile "rottura". Così non mi sono accorto di quando era successo il "fattaccio".

Sono andato a tentoni, cercando di ritrovare una immagine funzionante, ma ne faccio e ne cancello così tante che non c'è stato verso.

In effetti avevo anche un problema sulla virtualizzazione, o meglio qualche cambio della stessa, di cui non mi ero reso conto.

Avendo però attualmente un collega, che sta sviluppando una distribuzione con interfaccia Android, l'esigenza di utilizzare un notebook Microsoft, ci siamo trovati di fronte al problema,

Non mi capacitavo del perchè era sempre rimasto alla versione 8.17.x di eggs. Mi riferiva di avere problemi con la versione corrente, ma non avevo compreso che il problema era proprio la sua necessità del funzionamento UEFI, a me le nuove versioni andavano, a lui no. Io d'altra parte ero impossibilitato dal compremdere, in UEFI semplicemente non mi funzionavano ne' le versioni della serie 8.x, ne quelle della 9.x e quindi, non conoscevo quando s'era rotto il codice.

In effetti era successa una cosa diversa: l'emulazione di Proxmox andava riconfigurata, si può avviare con UEFI ma sono disabilitando il secure boot.

Ieri, preso dal panico che l'amico dovesse rinunciare alla collaborazione in ragione del fatto che non riuscivo ad assicurargli l'avvio UEFI, ho cominciato ad indagare.

Il primo passo è stato richiedere allo stesso una "ultima" iso funzionante.

Con sorpresa, l'ultima iso funzionante era proprio quella che mi aveva appena condiviso.

Quindi, una volta segnato il punto è cominciata la caccia!

Per prima cosa ho provato con una chiavetta USB e, finalmente scopro che in effetti l'immagine che mi era stata inviata funziona in UEFI dalla chiavetta USB. Era solo dall virtualizzatore che non riuscivo ad avviarla.

Una volta assicuratomi di questo e, dopo la meritata dormita notturna, fresco al risveglio ho cercato di capuire che problemi avessi su Proxmox dove la stessa immagine non veniva avviata.

Dopo una oretta di bestemmie varie, ho compreso che il problema risiedeva nella configurazione interna delle VM UEFI, ho fatto i seguenti passi:

Avvio la macchina virtuale, precedentemente configurata con BIOS: OMVF (UEFI) e la avvio premendo il tast ESC.

e vado a selezionare il: Device manager:

A questo punto, scelgo: secure boot configuration

Mi trovo la seguente schermata, nella quale come si può vedere, lo stato corrente di Secure Boot è enabled.

Non ci resta che modificare lo stato e disabilitarlo:

Adesso le nostre immagini potranno essere avviate con UEFI.

Mi resta ancora da capire, perchè le distro originali Debian/Ubuntu/etc funzionano comunque. anche con il Current Secure Boot State enable, ma questo ce lo portiamo appreso per una prossima fase. Si accettano però suggerimenti.

Inizio della comparazione del codice 8.17.x con la versione 9.0.x

La versione 9.0.x ha subito diverse riscritture rispetto alla versione originale e, tornare indietro, è discretamente impossibile. Per cui mi sno concentrato sulle differenze tra le due versioni, comparando i file cruciali per il boot UEFI: grub.template e grub.theme.cfg con quelli dell'altra versione.

Mi sono subito accorto che, addirittura, manco li avevo aggiornati, erano ancora con i vecchi parametri che, nella versione 9.x, ho dovuto riunire in un unico paramtro kernel_paremeters per gestire meglio le varie famiglie di linux.

Il processo è durato almeno due ore buone, perchè l'unico modo che conosco per controllare grub è quello di generare una nuova iso e testarla. Ho scoperto oggi grub-emu, un emutatore di grub discretamente funzionante, ma alla fine non l'ho trovato pratico.

Sistemato, con alterne fortune il template di grub ed il codice per il suo riempimento ho notato di avere comunque errori.

La macchina si avvia, ma va in grub rescue. Però immettendo:

set root=(cd0)
set prefix=(cd0)/boot/grub
normal

e dando invio. Pur senza caricare il tema - nel quale ho poi scoperto altri problemi - esegue correttamente il boot in UEFI.

A domani per il definitivo bugfix ed il completamento dell'articolo.

Se qualcuno vuole darci una occhiata, questi sono i file di configurazione:

• grub.template
• grub.theme.cfg

mentre il codice che compone i kernel_parameter si trova in ovary.ts, nella fuzione makeEfi() dalla linea 1335

Conclusioni

Con la versione eggs-9.0.10 possiamo finalmente dire: la stagione di caccia è finita!

Le ragioni del non funzionamento erano molteplici:

• problematiche di configurazione delle VM utilizzate che mi hanno impedito di rendermi conto immediatamente del problema;
• problematiche legate alla difficoltà di creare degli splash compatibili con grub;
• questa istruzione, in makeEfi() di ovary.ts

// make a tarred "memdisk" to embed in the grub image
await exec(`tar -cvf ${memdiskDir}/memdisk ${memdiskDir}/boot`, echo)

che si portava dietro tutto il path di memdiskDir, ed stata così modificata:

// make a tarred "memdisk" to embed in the grub image
/**
* NOTE: it's CRUCIAL to chdir before tar!!!
*/
const currentDir = process.cwd()
process.chdir(memdiskDir)
await exec(`tar -cvf memdisk boot`, echo)
process.chdir(currentDir)

Va bene, la rampa di lancio è stata approntata, si resta in attesa dell'arrivo dei missili e del conto alla rovescia.

Buon viaggio in UEFI a tutti!

Actually, it was a long story.

Before, to enable a link on the gnome desktop, it was enough to mark it with the right to run chmod a+x penguins-eggs.desktop, but since some time, it was necessary to use gio.

Either because I didnt use gnome much, or because I must be so confused that I didnt understand how this program works, until now gnome links always remained to be enabled.

Finally, the necessity to develop with eggs an important distribution made me look at the problem that can be said to be solved.

These are currently the 10 most clicked distros on distrowatch, to date we can already remaster most of them!

• MX Linux No
• EndeavourOS No
• Manjaro Yes
• Mint Yes
• Pop!_OS Yes
• Ubuntu Yes
• Debian Yes
• Garuda No
• elementary Yes
• Fedora No

MX Linux has its own remastering tools. I tried eggs on it, but in the end there is already what you need: the combination of mx-snapsnot and mx-installaer, and work great!

On Garuda and Endeavour I have made some attempts. On Garuda the mkinitcpio configuration fail for me and on EndeavourOS - strange to say - I didn't find Calamares. It should probably be extremely easy to make eggs compatible with both, but it needs the cooperation of some hackers from the respective distros.

But the best part will be to bring eggs in Fedora! Someone on line?

You have to know that appetite comes with eating, so surprised by how quickly eggs was adopted by manjaro, I tried my hand at cinematography.

I made two videos, in the first we'll see the ease of installation of eggs in manjaro, its configuration and the production of an iso image.

The second video will show how to install the image obtained in another computer.

I hope I've managed, at least with sympathy!

If you want to continue torturing yourself, this is my channel.

![ubuntu](/images/ubuntu-20-04.png) 

We have just finished the release of eggs for manjaro linux, it has been a nice undertaking and a nice discovery, a system how to say: fast, updated and performing.

What opportunities for the future and growth of eggs?​

eggs as backup system​

A dear friend of mine suggested me to propose it as a backup tool, in fact - server side - it is already possible to create a complete backup of an installation and reinstall it.

What's more, it is also possible to transfer a server for example from a node in India to one in Germany, without having to expose the data.

In fact the backup is done by eggs copying the ENTIRE system except the /home folder, then a LUKS volume is created with our pass phrase that will be required during the installation.

Without the knowledge of the pass phrase, you will be able to restore the system but not our data.

This security might not be necessary for a home backup, and you could add a flag to save a user's home for personal use as well: carry the complete system on a flash drive and so on.

eggs as a tool for creating vertical deployments​

Although it started as a personal tool, eggs has grown in recent years and is already used by some Linux distributions derived from Debian, Devuan or Ubuntu.

With the inclusion of manjaro we have a tool that allows us to create our own custom version of the system in an extremely fast and professional way, on a myriad of derived distributions.

In the long run it is more constructive to use the original material and have the possibility to handle and adapt it to our needs than to take for example the tools of one and recreate your own. It's simply faster!

The road to a school or corporate distro is paved and has been beaten since the days of systemback, now there are new possibilities and a better level.

eggs on other architectures arm64, armel​

With the transition from node 8.x to node 16.x, we had to give up the long-standing i386 compatibility. We could take the opportunity to test the arm64 and armel architectures, in this we are also helped by the fact that manjaro has its own development group on this architecture.

Conclusions​

I believe that this tool, the ability to "reproduce" the system may appeal to many and many may adopt it.

On the other hand, the concept of population diversification, reproduction and selection is not new and, according to observation of nature, quite powerful.

So it remains to be understood what the roads may be, but they are certainly open.

Yes, I think we found our wonderfull mascot: ironic, fat and - of course - italian. Not only, as eggs, inside contain mainly krill!

You never forget your first love

To tell the truth it's not quite true that linuxmint was my first love, initially I loved Knoppix and its KDE3 interface more and it didn't make me feel lonely in the unknown country.

But with the switch to KDE4 for a long time I found in cinnamon the favorite desktop and learned the name of Clement Lefebvre and his famous Linux Mint distribution.

So I have always considered Linux Mint even if derived from Ubuntu as a primary distribution and on the occasion of the release of version Una 20.3 I immediately made it compatible with eggs.

Linux Mint Uma remastered with eggs

E quindi uscimmo a riveder le stelle

Il precedente post era del 24 novembre 2021, mi ero appena immerso nella riscrittura di eggs al fine di includere altre famiglie di Linux oltre a quelle di discendenza Debian, Devuan ed Ubuntu.

Giusto dopo un mese di lavoro, ho cominciato a vedere i primi risultati e sono stato contattato da Stefano Capitali di manjaro che, interessato ad eggs mi proponeva un suo aiuto.

Grazie all'esperienza di Stefano che mi ha dato le principali indicazioni, l'abbrivio ed è inoltre l'autore del pacchetto, giusto per l'epifania, la Befana ci ha portato il regalo della prima versione di eggs funzionante su Manjaro Linux.

Potete trovare altre informazioni sul forum di manjaro