Determinazione della grandezza del volume luks-users-data
A questo punto manca ancora la pre-determinazione della grandezza del volume luks-users-data che sarà determinata:
Qui sono riportate le specifiche del formato Luks2
Binary Header size 4M
tipo di formattazione ext2. Per ext4 aggiungere 128MB per journal
dati da copiare
Per determinare lo spazio ho così proceduto;
determino lo spazio delle home degli utenti
aggiungo 4MB per l’header
se la grandezza è inferiore a 32MB imposto la grandezza a 32MB
aumento lo spazio del 10%
Ha funzionato per dimensioni da pochi byte sino a 2GB. Probabilmente il 10% può essere ridotto a 5% per dimensioni superiori a 1GB, mentre occorrerà aumentarlo almeno al 15% per dimensioni inferiori a 512MB.
Eggs viene rilasciato sia come pacchetto npm - versione originale - sia come pacchetto Debian di più semplice utilizzazione.
Sia per l’uno che per l’altro caso, per il funzionamento di eggs occorre caricare i pacchetti deb che effettivamente “svolgono” il lavoro. Tale compito per i pacchetti di eggs npm, veniva svolto dalla classe pacman, mentre nelle versioni di eggs pacchetizzate come pacchetto Debian le dipendenze sono poste in /DEBIAN/control.
I pacchetti che svolgono il lavoro “sporco”
I pacchetti Debian necessari ad eggs per svolgere il suo lavoro, anzi, sono questi pacchetti che essenzialmente svolgono il compito.
Tali pacchetti possono essere di differente tipologia, variando a seconda dell’architettura e della versione di Linux che stiamo utilizzando per la riproduzione.
Andiamo a vedere le problematiche che ne risultano.
pacchetti indipendenti e che possono essere rimossi
In questa lista ci sono pacchetti che in casi normali - non vengono utilizzati da altri progammi, ma solo da eggs e, che quindi possono essere correttamente rimos
squashfs-tools
xorriso
live-boot
live-boot-initramfs-tools
dpkg-dev
syslinux-common
isolinux
pacchetti di cui non è prevedibile l’uso da altri programmi o quasi sicuramente usati
Pacchetti che possono essere presenti anche senza eggs e di cui è difficile individuare la rimozione o meno.
cryptsetup
dosfstools
net-tools
parted
rsync
whois
Pacchetti che dipendono dall’architettura
Attualmente eggs supporta i386, amd64, arm64 ed armel.
Vi sono delle differenze su quali pacchetti è necessario e possibile installare
syslinux per amd64, i386
syslinux-efi per arm64, armel
Pacchetti che dipendono dalla distribuzione/versione di Linux da rimasterizzare
live-config
Pacchetti che dipendono sia dalla distribuzione/versione di Linux da rimasterizzare che dal tipo di init (systemd/sysvinit)
live-config-systemd
open-infrastructure-system-config in Ubuntu bionic
live-config-sysvinit
Ovviamente gestire il tutto richiede una certa complessità e ci sono stati casi in cui alcune versioni di eggs non sono state compatibili con tutte le versioni di sistema operativo installato.
Come ho proceduto sinora
Sino alla creazione dei pacchetti deb realizzati sulla spinta di UfficioZero ed altri, tutti i pacchetti venivano caricati da eggs attraverso il comando:
sudo eggs prerequisites
Da allora però parecchia acqua è passata sotto i ponti e, sostanzialmente credo di non sbagliare se nella totalità dei casi eggs venga installato come pacchetto deb.
I pacchetti .deb di eggs
La creazione del pacchetto deb di eggs è basata su oclif-dev e produce un pacchetto deb SENZA dipendenze e script di pre e post installazione.
L’unica differenziazione presente è, quindi, esclusivamente l’architettura: i386, amd64, arm74 o armel.
Perrisbrewery e l’introduzione di script e dipendenze
Queste dipendenze e gli script sono però importanti per garantire l’aggiornamento e la rimozione del pacchetto e sono stato costretto ad inserirli, da qua è nato il progetto compagno di eggs perrisbrewery.
Perrisbrewery è, come dire, un assistente che non fa altro che prendere il pacchetto debian originato da oclif e variabile unicamente dalla architettura ed andare ad inserire le dipendenze e gli script necessari.
Sinora ho cercato di limitare le tipologie di pacchetto, evitando di specificare la versione, in quanto questo - sia per me che per chi ha introdotto eggs nelle proprie repositories - può generare molto lavoro.
D’altra parte però la versione del sistema operativo su cui eggs sta girando, non essendo conosciuta nel momento della compilazione, deve essere valutata al runtime e, richiedere, l’analisi e l’installazione dei pacchetti specifici per la distribuzione/versione in uso.
Tre possibili alternative
Abbiamo, quindi, tre possibili strade:
rilasciare eggs esclusivamente come pacchetto non, era l’idea originale, ma comporta disporre di nodejs pre-installato e l’impossibilità della corretta rimozione di eggs e dei prerequisiti;
creare pacchetti .deb distinti ma solo per architettura, Comporta una ulteriore configurazione al runtime, necessaria per stabilire se i pacchetti dipendenti dalla versione o dal tipo di init (systemd/sysvinit) siano presenti o meno;
creare pacchetti distinti sia per architettura che per distribuzione/versione;
Considerata la comodità della pacchettizazione per l’utente finale, la possibilità di specificare direttamente nel pacchetto le dipendenze e gli script, la soluzione occorrente è l’ultima e cioè creare pacchetti distinti sia per architettura che per distribuzione/versione.
La birreria va espansa mentre il pacman va ridotto
Attualmente, poichè sinora ho scelto la soluzione ibrida, abbiamo due punti dove vengono decise le dipendenze da installare: perrisbrewery e pacman.
Lo svantaggio della installazione delle dipendenze con pacman è che quest’ultimo, i pacchetti richiesti da eggs non vengono registrate come dipendenze e, quindi, non è possibile rimuoverle in sicurezza. Forse questo potrebbe essere evitabile con qualche hatch.
Inoltre, avere due decisori per le dipendenze genera una inutile duplicazione di codice, da aggiornare ad ogni modifica dell’uno o dell’altro. In una parola, questo approccio è scomodo.
Dovremmo quindi pensare ad ampliare perrisbrewery che riceve attualmente in ingresso i pacchetti .deb di oclif ed introduce dipendenze e script.
perrisbrewery dovrebbe prevedere, quindi, in uscita per ogni architettura le versioni possibili e, generare, di conseguenta un pacchetto per ogni versione di distribuzione.
Immaginiamo, per il momento di continuare con l’uso di sourceforge per distribuire eggs. Attualmente tutti i pacchetti risiedono in due cartelle:
La fabbrica di birra necessiterebbe di ulteriori punti vendita
Non disponendo di risorse adeguate a gestire un repository ho gestito il rilascio utilizzando un server che se interrogato, risponde con le versioni disponibili e rilascia un indirizzo da dove scaricarle, nel nostro caso sourceforge.
Questo servizio è denominato basket, da cestino per le uova.
L’interrogazione avviene tramite usa una url specifica:
e, poichè chiamarlo a mano sarebbe lungo - si passa da quattro versioni differenti ad una ventina - fare in modo che venga automatizzato l’inserimento.
Stiamo come stiamo che stiamo bene
Ragionando sul problema, m’è venuto un dubbio: ma se rimanessimo così? Quali sarebbero i problemi?
Essenzialmente avremo: pacchetti comuni e dipendenti da architttura SEMPRE rimuovibili.
Tutti questi pacchetti sono comuni, non dipendono ne’ da architettura e neppure dalla versione e possono quindi essere previsti con la suddivisione attuale. Per essi avremmo la possibilità di rimozione perchè accettati come dipendenze di eggs.
squashfs-tools
xorriso
live-boot
live-boot-initramfs-tools
dpkg-dev
syslinux-common
isolinux
cryptsetup
dosfstools
net-tools
parted
rsync
whois
Pacchetti che dipendono dall’architettura
Anche questi pacchetti, pur non essendo comuni, essendo prevista una suddivizione per architettura finiscono nele dipendenze, come tali possono essere facilmente rimossi se rimangono orfani.
syslinux per amd64, i386
syslinux-efi per arm64, armel
Pacchetti che dipendono dalla versione
Il problema esiste solo per questi pacchetti che, alla fine non sono poi molti e non da luogo ad incertezze.
live-config (OK Debian/Devuan ma non Ubuntu bionic)
live-config-systemd (OK Debian/Devuan ma non Ubuntu bionic)
open-infrastructure-system-config Ubuntu bionic
live-config-sysvinit
Ci restano solo i pacchetti dipendenti da versione ed init
Solo i pacchetti derivanti dalla versione o dallinit andrebbero valutati. Alla fine si tratta di solo questi pacchetti che, dipendento più o meno da live-config, potremmo anche scegliere di rimuovere brutalmente senza timore di danni:
live-config
live-config-systemd
live-config-sysvinit
open-infrastructure-system-config in Ubuntu bionic
pacman e perrisbrewery
Rimane come è, salvo NON distinguere rimovibili e non rimovibili, in quanto essendo i pacchetti inclusi nelle dipendenze sono sempre rimovibili in automatico tramite apt.
Potrebbe però essere definito un file lib/dependecies.ts che esporti le nostre dipendenze e che venga utilizzato sia da config, pacman che in perrisbrewery e che contenga:
/** * dependecies for init * * We need for buster derivate with sysvinit MX-LINUX and probably others * */ export const depInit = [ { package: 'live-config-systemd', init: 'systemd' }, { package: 'live-config-sysvinit', init: 'sysvinit' } ]
implementazione
Con la versione 8.0.27 ho provveduto a realizzare l’opzione ibrida, ovvero rimanere con una distinzione dei pacchetti deb solo a livello di architettura ed utilizzando pacman - a runtime - per caricare gli ulteriori pacchetti necessari dipendenti dalla versione e/o dall’init.
Il codice risulta più compatto, la complassità si riduce soprattutto per la presenza del lib/dependencies.ts che è condivisa tra il comando config, la classe produce ed il pacchetto perrisbrewery.
Mi era rimasto il dubbio: eliminare il comando config.
Tale comando, pur essendo chiamato config comprende anche la chiamata a pacman per l’installazione dei pacchetti che dipendono dalla versione o dall’init. Alla fine, quindi, è già automatizzato. eggs config, inoltre, viene chiamato pure all’interno di post installazione - ma non può, in questa fase - installare pacchetti, per cui si limita ad emettere dei suggerimenti.
Quindi, alla fine ho deciso di rilasciare questa nuova version così com’è, in fondo sarà più semplice anche per gli utenti, che non si ritroverranno di fronte ad una pletora di pacchetti che, sostanzialmrnte, differiscono solo per le dipendenze.
Il comando config. viene automaticamente eseguito da produce per controllare se manca qualcosa ed in questa sede giò è autolatizzato
test
Non ho fatto moltissimi test, mi sono limitato a buster e bulldeye naked ed a linuxmint i386, ma dovrebbe essere ok anche per altre distro.
Per molto tempo, sino a qualche settimana fa, non ho aggiunto una opzione di backup ad eggs per un preciso motivo: non volevo che inavvertitamente un utente potesse mettere a rischio i suoi dati.
Tuttavia la possibilità di effettuare il backup delle aree utente mi è stata richiesta anche nel campo del backup/spostamento di server e, quindi, è stata aggiunta.
Sempre, attraverso lo stesso canale, mi è stata richiesta la possibilità di cryptare con LUKS le iso create ed eventualmente l’installazione stessa.
In effetti, mai avevo considerato il rischio insito in un laptop dimenticato presso un cliente, una sala riunioni, etc. Oppure la semplice chiavetta USB smarrita, magari creata con l’optione backup e che, quindi, contiene oltre al sistema operativo stesso la nostra home utente, con dati che possono essere più o meno riservati.
Huston: we have a problem!
C’è un problema serio, quindi, proprio come in Apollo 13: garantire o limitare la possibilità di accesso ai nostri dati nel caso un terzo abbia accesso al dispositivo: notebook, chiavetta USB, DVD, etc.
LUKS
Linux Unified Key Setup, abbreviato LUKS, è un metodo di cifratura dei dischi rigidi. Le sue specifiche sono state scritte da Clemens Fruhwirth nel 2004 ed è stato originariamente pensato per Linux.
Con LUKS è possibe criptare l’intero filesystem o una parte di esso.
In questo primo momento, ho pensato a “mettere una pezza” solo ad una parte del problema e, cioè garantire che un backup di un nostro server che - necessariamente finisca in rete, non foss’altro che per la sua installazione - esponga direttamente i nostri dati utente.
Per fare questo sono state necessarie alcune modifiche ad eggs, in particolare è stato aggiunto un ulteriore livello nella creazione della iso e cioè:
preparare un volume luks, formattarlo e montarlo;
copiare sul nostro volume criptato i dati degli account degli utenti e le loro home directory;
smontare il volume criptato e chiuderlo;
spostare il volume criptato nella cartella live della iso di destinazione
Quindi avremo una live che si avvia normalmente, eventualmente con l’autologin ed il solo utente live, ma che contiene al proprio interno sia gli accout degli utenti che i dati degli stessi.
In sede di installazione avviene il processo opposto - al momento solo per l’installer krill - ma sto pensando di aggiungere un modulo per calamares - dopo la fase di unpacking del file system, nel caso venga rilevato il volume criptato, si procede al restore dei dati:
si apre il volume criptato e viene richiesta la passphrase immessa;
si monta il volume ed i dati in esso contenuti vengono copiati nel sistema in installazione;
a questo punto non resta che smontare il volume criptato e proseguire come nel caso normale.
Naturalmente tutte queste fasi sono automatizzate, l’unica cosa da fare è digitare la passphrase e ricordarla poichè non sarà possibile recuperarla.
A fine dell’installazine il nostro “uovo” sarà diventato un pulcino esattamente come il padre.
Forse sarebbe più corretto parlare di clonazione, in stile pecora Dolly, più che di backup ma questo è un altro discorso.
I vantaggi di questo approccio
I dati utente non vengono mai esposti direttamene e la password non viene mai registrata e passa in rete solo al momento dell’installazione.
Questo risolve il problema per le nostre iso che - anche solo per l’installazione - in rete ci dovranno comunque finire.
Per quanto concerne, invece, l’installazione del sistema direttamente su di un file system cifrato - che risolverebbe il problema dello smarrimento di un notebook - è essenzialmente un caratteristica dell’installazione stessa e, se ci sarà interesse, potrà essere aggiunta in future versioni di krill.
Considerazioni
Questo è un progetto originale, nato inizialmente da necessità personali e dalla voglia di mettersi in gioco o, comunque, di rimanerci una volta abbandonata l’attività professionale per raggiunti limiti di età.
Indubbiamente mi sta dando molte soddisfazioni e, grazie ad esso, oltre a non aver assunto l’aspetto arruginito di un binario morto sul quale non passano più i tram, ho appreso diverse tecniche che non conoscevo precedentemente. Tuttavia, lo scrivere e mantenere un programma come eggs è piuttosto impegnativo sia in termini di tempo - sostanzialmente non meno di otto ore a giorno, spesso sabato e domenica compresi - sia dal punto di vista tecnico - occorre rimanere aggiornati e cercare di cogliere e comprendere quanto di nuovo esce a riguardo, infine, c’è anche un aspetto economico: necessità di avere almeno un server virtuale in uso sia per il blog per la diffusione delle versioni, oltre naturalmente ad avere bisogno di adeguato hardware dove creare. testare, etc. Attualmente utilizzo una stazione di lavoro basata su Debian buster con l’addizione di Proxmox VE e l’aggiunta di una interfaccia grafica, la macchina ha ormai cinque anni e, come dire, missile non lo è più!
Inotre, per poter testare le versioni per arm, ci sarebbe bisogno pure di hardwre fisico. Adesso le varie prove adesso vengono effettuate sempre su Proxmox VE emulando con qemu l’architettura arm64 e, naturalmente, faccenda lenta è.
Sinora - e sono appunto quattro, cinque anni - ho portato avanti lo sviluppo sostanzialmente da solo, però eggs nel frattempo è cresciuto ed diventato uno strumento maturo, utilizzato sia in ambienti professionali UfficioZero, scolastici guadalinex e minino-TDE o sviluppate da appassionati TeLOS. Alcune distro/remix realizzate con eggs sono presenti o comunque sottoposte anche su distrowatch (UfficioZero e TeLOS) e, comunque vengono scaricate in ogni parte del mondo.
eggs in sostanza può essere interessante per il lavoro di molti: da chi desidera realizzare una propria remix, a chi vuole un modo per installare la propria faticosamente creata ed, infine, per salvare, spostare o clonare le proprie infrastrutture informatiche, traferendole magari da hardware fisico a virtuale, da locali a remote e viceversa.
Inoltre - ed è un particolare di non poco conto - eggs è estremamente versatile a riguardo delle architetture sulle quali può girare. Difatti, essendo scritto in javascript utilizzando nodejs, è possibile rilasciarlo ed è attualmente rilasciato per quattro differenti architetture: amd64, i386, arm64 ed armel. Altre possono essere aggiunte in futuro a seconda degli sviluppi dell’IT ed in particolare dell’uscita di nuovi processori, penso soprattutto all’architettura RISC-V dalla quale spero e mi aspetto sorprese.
Sarei quindi felice di trovare persone interessate, disponibili per delle collaborazioni, a delle sponsorizzazioni del progetto. Anche eventualmente a finanziare delle nuove features di cui si potrebbe aver bisogno e migliorare, quindi, il progetto stesso.
D’altra parte il progetto è grande. comprende la grande famiglia di Debian/Devuan/Ubunte e derivate, e potrebbe essere anche esteso portandolo magari su distribuzioni diverse come Funtoo o Arch, etc.
In short: I removed the old CLI installer with the new krill installer with all it’s armamentary and experiences: react components for visualization (only for eggs install and eggs info) and same configuration for GUI and CLI installer.
I’m using actually node-8.17.0 to can build for all the architectures (i386, amd64, armel, arm64)
State of art of krill (eggs install –cli)
krill is nice and usable, yes there are things to clean but at last install quite fast the system and others modifications can be made directly on the installed system.
I think is quite more usable compared to the old eggs CLI installer, expecially for not deep technicals persons.
The real lack of krill actually is who cannot install the system in UEFI or, better, the system is installed but not booting. We must to solve this situation becouse arm boot only in UEFI not BIOS standard.
State of art of eggs on arm64
To test eggs against arm64 I’m using Proxmox VE, configurated via command line to support processor arm64 via qemu.
Depiste the hidden possibility it work enought well and lead me progress on support this two architectures (armel and arm64).
Actually we are in eggs 8.0.6 and eggs is installable on both the architectures and run well, but again distant to effective reproduction of the system, becouse we need to create uefi boot for iso and wait the support of krill to install on iso too.
Wanting help
It is long time I’m working alone, when started I was not sure to be successfull in create eggs. Now eggs exist and probably it is the most advanced software in the master/remaster field.
You can use it with a lot of distros and architectures and be able to install with the fantastic GUI calamares installer or with krill in CLI environments.
There is the possibility - and really quite near - to be able to start our method of “reproduction” in arm64 too. Think to the rasberry world or similar hardware.
Again, peoples from funtoo asked me if it is possible to bring eggs in funtoo. The answer was yes, but we must change something - the class called pacman - but, now, entirely based on apt.
But to realize that We need a community of developers, with different interests, distros and hardware.
That’s why I’m bothering you now, there is a real possibility of having a standard linux “reproduction” method for all systems and distros or at least, for most of them.
NEVER BEFORE SEEN IN THE WILD, CAMARONES REGRESSES AND BECOMES KRILL!
Krill is a Linux CLI system installer - still in development - that claims to be compatible with the great Calamares.
I’m trying to use Calamares’ configuration files and “steal” what I can, from idea to code.
Of course it won’t be the same thing - Krill is a different species - but it wants to be nice enough to users, just like Calamares is, and usable in desktop computers < 2 GB and any CLI-only system.
krill 0.0.2
krill 0.0.1
Krill is written in typescript and will be released ad Debian package.
Help
If you are interested to this project, and want to contribuite, please don’t esitate to contact me.
New ideas are boiling in the pot, I’m trying to improve the eggs interface using react but always staying within the CLI.
If any of you is able to help me in this task will be certainly welcome. What is required is some experience in react that I personally lack.
Thanx to our friends from TeLOS Linux i recently discover Jitsi Meet and fall in love immidiatly, so actually you can contact me at PenguinsEggsMeeting. Of course, I’m not always on line, but can be interesting for you and me this possibility to meet in conference, share the desktop, in a so easy form.
Last but not least, from the actual version 7.8.47 the new Ubuntu 21.04 hirsute come in the supported versions. You can find the resulting iso in the ubuntu section of our project.
I choose usually to make little improvments and release immidiatly and was a good way.
But now I’m trying to bring eggs to be compliant with Debian packagement system, I thought it was a joke. It isen’t!
So lately I had major troubles in packaging than in add news feathures, but finally I can say it work, it almost work.
I managed to had same time ago a flag in produce, called –final. I think to change this flag in future and choose –release. The scope of –final is to configure calamare to remove himself, eggs and all the dependecies from the system installed.
Initially I don’t like so much this, becouse in same way is a stop to the reproduction, but I’m a pratical man and I realize who peoples need, expecially peoples who take so much cure in build little or large systems. Lately a friend from Canada is working in a iso 14 GB compressed and, someone from India, surpass him! This also lead me also to use zstd - where possible - for fast compression, and revisited eggs info to check the situation before to produce and varius checks, in produce, made before to start disk compression.
Well we have this working, simply eggs produce –release let you to have a clean installation, removing eggs, calamares and their dependecies and select for max compression.
It’s short to say but it was a long history.
eggs calamares
This command install, remove and configure calamares GUI installer used to install the live.
Install and removing calamares from eggs
I was used with LXDE or cinnamon before, for long time I didn’t use KDE, LXQT and so on. Calamares is not a KDE project, but its fundaments are based on it. From the first times I installed it I saw it was necessary also to install two others libraries qml-module-qtquick2 and qml-module-qtquick-controls, running mostly in in gnome2, gnome3 it was not a problem to uninstall them and give an apt autoremove, until the day I realize who removing this libray remove all LXQT and problably KDE too!
It was a big problem, I think who probably someone - using eggs - had this problem… I really sorry for that. Pardon!
From this version, finally I don’t remove this libraries and KDE and LXQT are safe.
eggs produce
Produce, probably is the most important command of eggs and the command with more options.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
eggs produce the system produce an egg: iso image of your system
USAGE $ eggs produce
OPTIONS -b, --basename=basename basename -f, --fast fast compression -h, --help show CLI help -m, --max max compression -n, --normal normal compression -p, --prefix=prefix prefix -s, --script script mode. Generate scripts to manage iso build -v, --verbose verbose -y, --yolk -y force yolk renew --addons=addons addons to be used: adapt, ichoice, pve, rsupport --release release: configure GUI installer to remove eggs and calamares after installation --theme=theme theme for livecd, calamares branding and par
flag –release
I introduced a new flag in produce, the flag –release.
Really is an old/new flag, the original name was sterilize (because it remove the reproductive system during the installation) and lately was called –final.
eggs is a specialized software, not really for common use, I expect who eggs’s users are deeply involved in Linux and want customize their systems for many purpouses: from share with friends to share with the community, so I choose to write a program more for developers than final users. For this people –release sound as release the system: compress it at the max and remove any sign of the live system after the system is installed.
flag –addons take place of –adapt, –ichoice, –pve, –rsupport
To let to customize a bit the resulting iso in the time I had themes and addons.
Themes are of course themes, now with theme you can customize the result of your boot in livecd, the branding of calamares and the partions schema. (mostly this feathures are, of course, based on the great flexibility of calamares), eggs just try to arrange a tool who use this great project and ler You to customize your effort).
Addons are at the moment, just coming from eggs - from me - and are links to adapt resolution in VM, to an local proxmox-ve server - to realize a proxmox customizate workstation and server - mostly for developers and me! ichoice let tho choice the installer of the system. Most peoples will prefere calamres installer and are right, but in machine short of RAM, install with cli-installer can be an option, and sometime, to only possible option if not change hardware. –addons rsupport bring a link to dwangent, who need to be installed before. This can be a pratical way to help users also from the live.
Customizing live system and calamares theme
I want to write more about create and customize themes in next days.
Da un paio di giorni - ormai una settimana fa - sto cercando di far funzionare versioni “antiche” Debian con eggs.
Per il momento mi è riuscito di arrivare sino a Debian stretch ed ad Ubuntu xenial, niente da fare invece con Debian jessie che, pure avrei in animo di rendere compatibile.
Il tutto è nato dal tentativo - non riuscito - di installare una distro moderna pur se leggera su un vecchio pc con arhitettura amd64 e “solo” due gigabyte di RAM.
Lo avevo preparato bene, forse quattro o cinque anni fa, con Debian jessie e cinnammon e l’avevo rimesso in moto cercando di installare qualcosa di più aggiornato.
L’intenzione era quella di installare So.Di.Linux Orizzonti 2025 per un ragazzo che va o dovrebbe andare a scuola. So.Di.Linux è una distribuzione basata su Linux Mint con mate come interfaccia grafica, in teoria avrebbe dovuto girare con due GB in pratica era impossibile da installare con Calamares, poca memoria RAM
Ho ovviato al problema installando con l’installer a riga di comando, ovviamente si è installato ma sono incappato in una scheda grafica nvidia vecchia e non più aggiornata e sono stato costretto a desistere.
Precedentemente sulla macchina era installato Debian jessie con una delle prime versioni di cinnamon ed era discretamente usabile. Ancora di più lo sarebbe stato installandoci xfce, mate, lxqt, etc.
Questo mi ha portato a ripensare alle versioni supportate, sinora avevo sempre cercato di andare avanti senza mai voltarmi le spalle e rendendo incompatibili con eggs versioni vecchie, ma tutto sommato, ancora utilizzabili di Debian ed ubuntu,
Compatibilità di eggs
Debian
Debian 8 jessie OK, ma senza la compressione fast (zstd), no calamares (vedi nota)
Debian 9 stretch OK, ma senza la compressione fast (zstd), no calamares (vedi nota)
Debian 10 buster OK
Debian 11 bullseye OK
Devuan
Devian beowulf OK
Ubuntu
Ubuntu xenial OK, ma senza la compressione fast (zstd), no calamares (vedi nota)
Ubuntu bionic OK
Ubuntu focal OK
Ubuntu groovy OK
Derivate
Naturalmente è possibile rimasterizzare anche le derivate dalle distribuizioni sopra menzionate: LinuxMint dalla versione tricia (basata su bionic) a quelle odierne (ulyana ed ulyssa), deepin, netrunner-core e netrunner-xoxo, ed innumerevoli altre.
Nota su Debian 9 stretch (*)
In questa versione non è possibile utilizzare l’algoritmo zstd per la compressione fast, procedere con compressione normale.
Nota su Debian 8 jessie (**)
Su Debian 8 jessie non è possibile utilizzare eggs per la mancanza di overlayfs nel kernel 3.16.x tale caratteristica è resente solo dalla versione 3.19 del kernel. Ho dovuto quindi sostituire il kernel originale con altro di provenienza ubuntu in versione 3.19, in effetti avevo precedentemente installato un kernel bpo debian, questo permetteva la generazione della iso ma purtroppo aveva dei problemi a convivere con la restante parte di jessie.
A questo punto, risolto il problema di overlayfs lato kernel che mi impediva di creare la iso, mi sono scontrato con il fatto che i pacchetti live di jessie utilizzano aufs e non overlayfs, per cui la iso era perfettamente avviabile ma non riusciva comunque a montare filesystem.squashfs.
Ho risolto, installando live-boot dalla versione stretch, finalmente abbiamo la nostra live avviabile.
Rimaneva però un ulteriore problema, il pacchetto eggs utilizza un pacchetto npm che va compilato e che si rilevava incompatibile con la versione di libstdc++
E’ stato, quindi, stato necessario ricompilare il pacchetto eggs su jessie e, finalmente, TUTTO FUNZIONA!
In attesa di sostituire il pacchetto drivelist di eggs con altro, vi segnalo che se in questo momento aggiornate eggs con la versione standard eggs non riuscirà ad installare la iso.
In this video I will give a demonstration of creation a remix starting from almost nothing - my remixes called naked - who consists in the clean debian netinstall plus addiction of eggs.
Can be interesting not only for desktop remixes but for server remixes too.
I hope you’ll enjoy it.
I can’t make this videos in english, but if You are interest to publish similar demonstrations in english or others languages, I will be happy to collaborate with you. Please, contact me at: piero.proietti@gmail.com
