disperato erotico stomp

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.

Tutti i nodi vengono al pettine

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.

Fattosta, una volta messo 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 - almeno sulla chiavetta USB. Era solo nel virtualizzatore che non riusciva ad avviarsi.

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.
uefi-ovmf

e vado a selezionare il: Device manager:
uefi-device-manager

A questo punto, scelgo: secure boot configuration
uefi-secure-boot-configuration

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

Non ci resta che modificare lo stato e disabilitarlo:
uefi-current-state

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:

1
2
3
set root=(cd0)
set prefix=(cd0)/boot/grub
normal

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

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

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

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
1
2
// 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:

1
2
3
4
5
6
7
8
// 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!

finally we solved the last problems with gnome

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.

Ubuntu gnome

Is There Anybody Out There?

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?

distrowatch

macaroni penguins illustrating eggs on manjaro

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

macaroni penguins preparing new adventures...

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.

macaroni penguins

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

linuxmint-una

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

linuxmint Una

manjaro linux on board

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.

manjaro-kde

Potete trovare altre informazioni sul forum di manjaro

a bit more universal...

eggs in questo momento ha raggiunto praticamente la totalità delle distribuzioni basate su Debian e da queste derivate: Devuan, Ubuntu e le innumerevoli altre.

Un buon successo, per un software di sistema ed in particolare della rimasterizzazione del sistema stesso al fine di ottenere da un sistema installato una sua immagine installabile ed avviabile. Tuttavia da quando è stato pensato, la sua indole è stata sempre quella di essere per così dire “universale” ed allora come fare per includere le altre famiglie di Linux?

Vi sono almeno altre due famiglie Linux ampiamente diffuse: sono quelle di derivazione Fedora/Redhat e quelle di derivazione Arch. Ce ne sono anche altre, nondimento importati storicamente o che lo potrebbero diventare in seguito: penso a slackware, gnuix ed nixos in questo momento, ma sicuramente c’è e ci sarà, ancora dell’altro.

Bisognerebbe trovare qualcosa di comune a tutte esse, innanzitutto per distribuire il programma.

AppImage e flatpack potrebbero essere interessanti per questo. Se eggs fosse rilasciato come appImage, potremmo prescindere da apt e portarci direttamente su appImage alcuni degli strumenti di cui abbiamo bisogno:

  • dosfstools
  • parted
  • rsync
  • squash-tools
  • xorriso

In aggiunta, credo che i seguenti pacchetti siano universalmente installti:

  • coreutils (normalmente presenti)
  • cryptsetup (normalmente presenti)

Abbiamo quindi, per la famiglia Debian le seguenti necessità:

  • isolinux // indispensabile per boot
  • syslinux-common
  • live-boot
  • live-boot-initramfs-tools

Occorre capire come nella famiglia redhat ed arch tutto ciò potrebbe realizzarsi e dovrebbe essere piuttosto fattibile visto che sia redhat che arch hanno strumenti validi di rimasterizzazione.

Arch linux

Dalla pagina di archiso

The following packages need to be installed to be able to create an image with the included scripts:

  • arch-install-scripts
  • awk
  • dosfstools
  • e2fsprogs
  • erofs-utils (optional)
  • findutils
  • gzip
  • libarchive
  • libisoburn
  • mtools
  • openssl
  • pacman
  • sed
  • squashfs-tools

Il problema di Arch linux è che è si un sistema pulito e documentato, ma è … palloso!!!

Mandato alla malora Arch linux, ho scelto la prima distribuzione basata su Arch linux presente in distrowatch: EndeavourOS e non ho potuto che stupirmi.

Ho sempre utilizzato calamares per installare sistemi live e pensavo che fosse questo il modo, in EndeavourOS viene utilizzato in maniera diversa e permette - a partire dallo stesso disco di installazione, di installare l’interfaccia grafica che più ci aggrada.

Non dovendo andare troppo per il sottile, necessitando giusto di qualcosa di maneggiabile ho scelta xfce4 e dopo un breve minutaggio necessario a scaricare ed installare i vari pacchetti il sistema si è installato.

Da notare anche nella loro configurazione di calamares la presenza di un tasto per la visualizzazione della finestra di debug, utilissima a noi sviluppatori.

EndeavourOS

niente da dire… mi sto innamorando!

Pulito, bella grafica, snello. Me lo immagino installato su computer leggeri e datati…

EndeavourOS

Oggi ho provato a far girare eggs su Arch… risultati? Soddisfacenti, ma c’è lavoro da fare e, non voglio inguaiare la parte stable di eggs.

Sulla macchina di test, sono riuscito a far funzionare eggs dad -d ed iniziare la produzione. Ho però problemi con la comprensione di pacman, ad esempio sudo pacman -S calamares dovrebbe installare, appunto calamares, ma semplicemente non lo trova.

Una buona idea che replicherò sulla versione di eggs in linea, almeno sulla 14.18 che dovrà evolvere per abbracciare archlinux è quella di introdurre per ogni distribuzione il concetto di familyId, con tre possibilità: debian, fedora, arch.

Questo mi consente una migliore gestione dei processi di installazione, rimozione, controllo del pacchetto.

Un altro grosso problema è la non uniformità dei nomi dei pacchetti, così la famiglia debian ha dei nomi, la famiglia fedora degli altri ed anche la famiglia arch.

Dovrei, a priori tenere traccia di tutto quello che occorre - poche cose in verità - e organizzare una tabella a tre per ogni famiglia.

Per oggi basta così, s’è fatta ‘na certa…

Appunti sparsi

pacchetti Debian utilizzati attualmente

Abbiamo dei pacchetti comuni, alcuni già di norma installati, alcuni necessari semplicemente per la pacchettizzazione, altri necessari per comprimere e generare la immagine iso, boot etc. Li ho denominati common. Altri pacchetti invece, variano a seconda della architettura i386, amd64, armel o arm64. Altri pacchetti ancora variano a seconda della versione della distribuzione in uso. I pacchetti più “particolari” sono i pacchetti live-boot e live-config che sono perltro tipici di Debian e non presenti in altre distro.

common

  • coreutils // indispensabile whoami
  • cryptsetup // indispensabile
  • dosfstools // indispensabile creazione disco EFI
  • dpkg-dev // necessario per la creazione della repository locale yolk
  • isolinux // indispensabile per boot
  • live-boot
  • live-boot-initramfs-tools
  • parted // indispensabile
  • rsync // indispensabile
  • squashfs-tools // indispensabile
  • syslinux-common
  • xorriso // indispensabile

dipendenti dalla architettura

  • package: syslinux, arch: [‘amd64’, ‘i386’]
  • package: ‘syslinux-efi’, arch: [‘arm64’, ‘armel’]

dipendenti dalla versione

  • package: ‘live-config’, versions: [‘jessie’, ‘stretch’]
  • package: ‘live-config-systemd’, versions: [‘jessie’, ‘stretch’, ‘buster’]
  • package: ‘live-config-sysvinit’, versions: [‘beowulf’, ‘chimaera’, ‘daedalus’]
  • package: ‘open-infrastructure-system-config’,versions: [‘bionic’]

Pacchetti live

live-boot

live-boot contains the components to configure a live system during the boot process (early userspace). Do not install this package on your regular system, it is only meant to be used in a live image.

live-boot-initramfs-tools Live System Boot Components (initramfs-tools backend)

live-config

live-config contains the components to configure a live system during the boot process (late userspace).

distros that can be remastered with eggs

You can use eggs on all the following distributions, always having an easy installer available: krill a console line tool, but usable as GUI for the “older” distributions like Debian jessie and Debian strecth or the versatile graphical installer calamares for all the others. Of course You can always use krill on system without GUI, this is a clear advantage if you want to build easy-to-install liveCDs for server systems.

  • Debian: 8.x jessie, 9.x stretch, 10.x buster, 11.x bullseye (stable), bookworm (n development);

  • Devuan: 3.x beowulf, 4.x chimaera (stable), 5.x daedalus (n development);

  • Ubuntu 18.04 LTS bionic, 20.04 LTS focal, 21.10 hirsute, 21.10 impish, jammy (n development);

and all the derivates, including deepin, linuxmint, KDE neon and many, many others.

Distros derivated from Debian, Devuan and Ubuntu

krill installer
calamares installer

Prior to the release of eggs-8.17.11 a big effort was also made to review many old iso’s previously released from Debian jessie in naked and minino versions, to naked versions of stretch and buster with both amd64 and i386 architecture.

In this screenshot you can see the eggs krill installer in action on a Debian jessie derivative that does not support calamares minino-TDE
krill installer minino

Again calamares installing Linux Mint tricia i386, based on Ubuntu bionic and remastered with eggs-8.17.11.

calamares installer on linuxmint tricia 386

This is a latest addition Kali Linux a security distribution. Some people will turn up their nose at the idea of a remastered security distro and I can agree. But with eggs we can remaster it ourselves and decide in which way to modify it, so - all in all - the problem does not arise. Moreover it can be used directly live with our configurations, etc.

kali-remaster

Once the ISO image is obtained, the installation takes place with calamares in no time, moreover being a live system it can also perform its tasks directly.

kali-installing

This is what kali linux remastered looks like, of course you can apply any customization.

kali-installed

neon-user-20211028-132

In my adventure to create an updated remastering tool compatible with the Debian, Ubuntu, Devuan world I’m running into the following problem:

I can remaster practically everything from Debian Jessie to bookworm and from Ubuntu bionic up to the development version jammy - instead, I can not and I have not understood why - to do the same with the latest version of neon with plasma-5.23.
I also report that the problem does not occur, however, with Kubuntu 21.10 impish with the beta of plasma-5.23 installed.
From a neon system installed, the ISO builds normally and is bootable, but when I go to boot from the liveCD obtained, the system does not come to show the monitor and moreover giving ALT-CTRL F2, F3, etc can not open the console.

Someone, could give me some clues or suggest me a way to debug?

Contact

ubuntu 22.04 jammy
debian 12 bookworm
neon-user-20211028-132