Da qualche giorno sto impegnandomi, sarà il caldo, a portare penguins-eggs su Alpine Linux.

Naturalmente non è un processo semplice, Alpine è una distribuzione non derivata da Debian o da Arch e, pertanto, abbastanza diversa.

Per fare esperienza e saggiare le mie capacità, ho iniziato con il crearmi una macchina di sviluppo, il mio famigerato colibri, avvero una macchina abbastanza leggera con xfce, code, nodejs e pnpm per lo sviluppo di penguins-eggs.

Lo scopo ormai può dirsi riuscito, dispongo di una VM configurata perfettamente allo scopo ed è tracciato tutto quanto il percorso sul documento WAY-TO-ALPINE.md.

A che punto siamo con la creazione di una ISO?

Se avete già letto WAY-TO-ALPINE.md avete già una risposta: filesystem.squashfs completo, ISO avviabile da BIOS, mancanza di un initramfs che monti il filesystem.squashfs ed esegua il chroot in eggs.

A chi posso rivolgermi per una collaborazione?

Pure se sto continuando ad andare avanti, è evidente che mi servirebbe la collaborazione di una persona esperta di Alpine Linux, per trovare la soluzione.

Se qualcuno è in linea batta un colpo, avere penguins-eggs su Alpine Linux potrebbe facilitare la diffuzione della Distribuzione e permetterne una customizzazione a portata degli utenti finale. Inoltre, data la sua leggerezza sarebbe possibile effettuare nuomerosi test.

Mi serve aiuto però... magari anche da uno sviluppatore.

Nella puntata precedente abbiamo visto come rimasterizzare una MicroSD per RaspberriPi, creando una immagine .img.

Possiamo fare questo a partire da una immagine ISO per arm64 creata con eggs su una VM arm64?

Proviamo

Ho scaricato egg-of_debian-bookworm-naked_arm64_2024-04-14_1821.iso, la monto ed estraggo i file.

Sulla ISO ci sono 4 cartelle:

• grub
• efi
• isolinux
• live

Isolinux, qua non serve proprio, le altre due non sono sicuro. Quello che ci occorre è il contenuto di live:

• filesystem.squashfs
• initrd.img-6.1.0-20-arm64
• vmlinuz-6.1.0-20-arm64

In soldoni dalla partizione bootfs dovremmo far partire vmlinux che a sua volta utilizzerà initrd-img, questo dovrebbe montare quindi filesystem.squashfs come in effetti succede su una VM.

filesystem.squashfs è 469M, diciamo che con una immagina da 1G dovremmo avere spazio a sufficienza.

Andiamo a creare un raspi.img da 1G, suddiviso in due partizioni: bootfs e rootfs.

Per non sbagliare, partiremo da una immagine esistente e sicuramente funzionante.

Scaricare immagine raspi 2024-07-04-raspios-bookworm-arm64-lite.img.xz

decomprimere l'immagine​

unxz 2024-07-04-raspios-bookworm-arm64-lite.img.xz -k

Ridenominazione dell'immagine​

mv 2024-07-04-raspios-bookworm-arm64-lite.img raspi.img

La nostra immagine root=PARTUUID=a3f161f3-02

sudo losetup -fP raspi.img
sudo losetup -a

Ridimensionare la partizione​

sudo kpartx -av /dev/loop1 # loop0 è usato dall'immagine ISO

troviamo:

add map loop1p1 (252:5): 0 1048576 linear 7:1 8192
add map loop1p2 (252:6): 0 4481024 linear 7:1 1056768

montiamo rootfs

sudo mount /dev/mapper/loop1p2 /mnt/rootfs

copiamo il tutto

sudo rsync -aAXv   /media/artisan/naked/live/ /mnt/rootfs/

Andiamo a montare bootfs

sudo mount /dev/mapper/loop1p1 /mnt/bootfs

La configurazione su ISO

Queste sono le linee di configurazione di grub.cfg nella ISO live

linux /live/vmlinuz-6.1.0-20-arm64
append initrd=/live/initrd.img-6.1.0-20-arm64 boot=live components locales=en_US.UTF-8 cow_spacesize=4G

e questo è il cmdline.txt funzionante, della chiavetta precedente:

console=serial0,115200 console=tty1 root=PARTUUID=a3f161f3-02 rootfstype=ext4 fsck.repair=yes rootwait initrd=/live/initrd.img-6.1.0-20-arm64 boot=live components locales=en_US.UTF-8 cow_spacesize=2G

Qui non abbiamo /live/, quindi dovremmo, forse, aggiungere a cmdline:

initrd=/initrd.img-6.1.0-20-arm64 boot=live components locales=en_US.UTF-8 cow_spacesize=2G

semplificando, riscrivo in questo modo:

initrd=/initrd.img-6.1.0-20-arm64 console=serial0,115200 console=tty1 root=PARTUUID=a3f161f3-02 rootfstype=ext4 fsck.repair=yes rootwait boot=live locales=en_US.UTF-8

smontiamo tutto

sudo umount /mnt/bootfs
sudo umount /mnt/rootfs

sudo kpartx -d /dev/loop1

A questo punto raspi.img dovrebbe essere pronta per essere registrata su usb.

Questo è il boot dell'immagine prodotta

Noto che in init line 246 segnala l'assenza di /scripts/live... Ma in effetti questo file è presente, difatti facendo l'analisi di initrd.img-6.1.0-20-arm64 lo troviamo.

Analisi initrd.img-6.1.0-20-arm64

Il nostro file initrd.img-6.1.0-20-arm64 è compresso con zstd, possiamo rilevarlo con il comando:

file initrd.img-6.1.0-20-arm64

A questo punto possiamo decomprimerlo:

zstd -d -k  initrd.img-6.1.0-20-arm64 -o initrd.img

Quindi creiamo una directory content per riversare i dati:

mkdir contents
cd contents
cpio -id < ../initrd.img

contenuto di initrd.img-6.1.0-20-arm64

ls 
bin  conf  etc  init  lib  run  sbin  scripts  usr

ls scripts
bin  conf  etc  init  lib  run  sbin  scripts  usr

quindi, il file /scripts/live esiste...

Perchè non lo trova?

file /scripts/live

Il file /scripts/live esiste ed esiste /bin/live-boot

# Live system filesystem mounting			-*- shell-script -*-

. /bin/live-boot

live_top()
{
	if [ "${live_top_used}" != "yes" ]; then
		[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/live-top"
		run_scripts /scripts/live-top
		[ "$quiet" != "y" ] && log_end_msg
	fi
	live_top_used=yes
}

live_premount()
{
	if [ "${live_premount_used}" != "yes" ]; then
		[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/live-premount"
		run_scripts /scripts/live-premount
		[ "$quiet" != "y" ] && log_end_msg
	fi
	live_premount_used=yes
}

live_bottom()
{
	if [ "${live_premount_used}" = "yes" ] || [ "${live_top_used}" = "yes" ]; then
		[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/live-bottom"
		run_scripts /scripts/live-bottom
		[ "$quiet" != "y" ] && log_end_msg
	fi
	live_premount_used=no
	live_top_used=no
}


mountroot()
{
	# initramfs-tools entry point for live-boot is mountroot(); function
	Live
}

mount_top()
{
	# Note, also called directly in case it's overridden.
	live_top
}

mount_premount()
{
	# Note, also called directly in case it's overridden.
	live_premount
}

mount_bottom()
{
	# Note, also called directly in case it's overridden.
	live_bottom
}

L'initrd è corretto, ho usato lo stesso della chiavetta usb, il file /script/live esiste purtroppo non riesco a superare questo scoglio.

Suggerimenti?

Lavorare con taspberry è bellissimo, tuttavia dal punto di vista della rimasterizzazione abbiamo un problema: la mancanza di grub e la presenza di uboot.

Non sarebbe nemmeno male, ma eggs è strutturato per lavorare con grub ed isolinux, calamares lo stesso, quindi sinora le immagini realizzate per amd64 hanno girato esclusivamente su una versione di Proxmox VE come macchine virtualizzate su un Raspberry 4.

In questo modo abbiamo a disposizione una modalità di installazione standard ed in effetti inizializzando il lettore di CD con la notra immagine ISO riusciamo ad installare regolarmente il sistema con calamares.

Tuttavia, abbiamo bisogno di far girare il nostro lavoro su hardware reale e non emulato e ci scontriamo con l'assenza di un lettore CDROM, l'assenza di grub, etc.

Ho quindi provato a creare una immagine .img per rapberry raspi.img partendo dall'immagine lite, e metterla su chiavetta USB per vedere cosa succede.

Scaricare immagine raspi 2024-07-04-raspios-bookworm-arm64-lite.img.xz

decomprimere l'immagine​

unxz 2024-07-04-raspios-bookworm-arm64-lite.img.xz -k

Ridenominazione dell'immagine​

mv 2024-07-04-raspios-bookworm-arm64-lite.img raspi.img

La nostra immagine root=PARTUUID=a3f161f3-02

Aggiungere lo spazio necessario​

Poichè il filesystem rootfs della mia raspberry ha circa 6GB di dati, mentre l'immagine lite ha circa 2,1 GB di spazio, occorre ingrandire l'immagine. Utilizzeremo il comando qemu-img resize:

qemu-img resize -f raw raspi.img +5G

Associa il file .img a un dispositivo loop:​

sudo losetup -fP raspi.img

verifica​

sudo losetup -a

espansione della partizione con gparted​

sudo gparted /dev/loop0

Creazione dei dispositivi di mappatura delle partizioni:​

sudo kpartx -av /dev/loop0

Verifica i dispositivi di mappatura creati:​

ls /dev/mapper

monta rootfs​

sudo mount /dev/mapper/loop0p2 /mnt/rootfs

esegui copia​

sudo rsync -aAXv /zfs/raspi_backup/rootfs/ /mnt/rootfs/
sudo nano /mnt/rootfs/etc/fstab

Ed impostare fstab come segue:

Proc            /proc           proc    defaults          0       0
PARTUUID=a3f161f3-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=a3f161f3-02  /               ext4    defaults,noatime  0       1

monta bootfs​

sudo mount /dev/mapper/loop0p1 /mnt/bootfs

sudo rsync -aAXv /zfs/raspi_backup/bootfs/ /mnt/bootfs/

edit /mnt/bootfs/cmdline.txt​

sudo nano /mnt/bootfs/cmdline.txt

edita cmdline e rimetti la partizione corretta

console=serial0,115200 console=tty1 root=PARTUUID=a3f161f3-02 rootfstype=ext4 fsck.repair=yes rootwait splash quiet splash plymouth.ignore-serial-console

smonta​

sudo umount /mnt/bootfs
sudo umount /mnt/rootfs

Rimuovi i dispositivi di mappatura delle partizioni:​

sudo kpartx -d /dev/loop0

Rilascia il dispositivo loop:​

sudo losetup -d /dev/loop0

Scrittura dell'immagine su MMC o chiavetta

A questo punto non ci rimane altro che scrivere la nostra immagine su una microsd o una chiavetta USB. Utilizzeremeo rpi-installer selezionando immagine custom e quindi la nostra immagine raspi.img.

Terminata la scrittura non ci resta che avviare il nostro raspberry e goderci l'ebbrezza del boot con la nostra immagine.

Sto avendo sempre più problemi nello scaricare le ISO da sourceforge.

Non comprendo il motivo, ma la faccenda è grave perchè alla fine non permette agli utenti di provare le varie versioni, etc.

Sino a non molto tempo fa, avevo una percentuale di download settimanali in cui circa la metà erano ISO e l'altra metà i pacchetti di eggs.

Da qualche tempo, la percentuale delle ISO si è notevolmente abbassata, non ne capivo le ragioni ma trovandomi a volte a scaricare delle semplici immagini naked per aggiornarle, mi sono trovato con tempi di attesa lunghi.

Quanto lunghi? Diciamo che, paradosso faccio prima ad effettuare un upload sulla mia pagina sourceforge che a scaricare il file che ho immesso.

Occorre perciò trovare delle alternative e mi sto guardando intorno.

Meta.io​

Ho messo alcune ISO - per iniziare - su meta.io, le trovate sulla pagina download.

Le iso che trovate nella pagina, sono: colibri, voyager e LastOSLinux. La prima per sviluppo, particolarmente mirata alla creazione e mantenimento di penguins-eggs, la seconda una recente scoperta nella sua versione Debian e la terza il frutto di una collaborazioni in itinere con con il team di LastOS.

Per gli altri download al momento sempre sulla pagina surgeforge.

Tuxfamily.org​

Ho provata ad iscrivermi su tuxfamily.org il progetto è in attesa di esame.

Suggerimenti?​

Se avete suggerimenti o offerte di hosting potete scrivermi.

Oggi, dopo molto tempo, torno a scrivere qualcosa sul blog, tanto tempo è passato da fine gennaio, quando ho presentato PenGUI ancora in stato non funzionante.

Nel tempo l'ho corretta e vedo che attualmente marcia spedita a download su sourceforge, presto sarò libero da altri impegni e la potremo perfezionare.

Ma oggi voglio semplicemente descrivere le mie impressioni di utilizzo di Raspberry. Possiedo da tempo un Raspberry 4 che ho utilizzato per creare le ISO per ARM e per la compilazione di PenGUI su arm64 e, sto svrivendo attualment da una Raspberry PI con 8 GB di RAM connesso alla rete domestica.

Rete domestica un corno, perchè comprende una server Proxmox VE su amd64 sul quale sinora ho svolto il mio lavoro, una Pi 4 con 4 G di RAM, che mi funge sia da server per le macchine virtuali arm64 che da git domestico con l'ottimo Forgejo.

Naturalmente essendo col tempo diventato un esperto della customizzazione di sistemi operativi Linux, con sommo piacere opero su tutte e tre le macchine, più le svariate macchine virtuali con la mia customizzazione colibri.

Devo dire che è comodo, ho sempre una certa difficoltà - sarà anche l'età - a passare da un Desktop ad un altro. Per anni ho utilizzato di tutto, simo a stabilizzarmi su cinnamon di Linux Mint. Attualmente, anche per problemi di vista, mi viene comodo xfce che ha il vantaggio di ridimensionare i caratteri del terminale. Si, lo sò che basta installare un altro terminale su cinnamon e si campa tale e quale, ma mi trovo meglio ed è più leggero. Inoltre, da tempo ho "standardizzato" il mio ambiente di lavoro e lo posso installare con un sol colpo di eggs wardrobe wear colibri.

amd64

Su comune PC, parto dalla netinstall di Debian 12 bookworm che installo come dire "naked" ovvero con il minimo indispensabile e senza GUI,

arm64

Per rasberry sto utilizzando la versione lite di Raspberry Pi OS - basata su Debian 12 bookworm - senza interfaccia grafica, che customizzo successivamente utilizzando eggs.

L'ambiente che viene fuori è esattamente lo stesso, poi è chiaro che su raspberry mi troverò raspi-config ed il boot con uboot da configurare con /boot/firmware/cmdline.txt, mentre su PC avremo grub.

In sostanza, sto scrivendo dalla stessa tastiera e lo stesso monitor di sempre: tra farlo da raspberry Pi 5 o dalla mia quotidiana stazione di lavoro non cambia nulla.

I cavi, la vista e la vecchiaia

Odio attaccare e staccare i cavi, averne troppi, etc. Naturalmente sinora ho sempre staccato ed attaccato tastiera, mouse, monitor e cavo di rete da un PC ad un altro.

Ora, visto che tutto sommato mi viene comodo, sto provando ad utilizzare il nuovo Rasberry come unico computer da utilizzare direttamente. Si ha il vantaggio di non attacare e staccare cavi, abbassarsi per collegare la rete, etc. Il rasberry è naturalmete connesso in WIFI e va onestamente, per caricare e scaricare le ISO posso farlo con la rete cablata sul fisso e da Raspberry utilizzare quest'ultimo.

Ah, naturalmente al diavolo le MicroSD - sto lavorando con un drive ssd portatile attaccato alla USB3 ed alimentato direttamente dal Raspberry.

Vediamo come procede, per il momento, sarà un'oretta che il mio Pi 5 è attaccato. non scada affatto, ero molto preoccupato.

Era da molto tempo che mi era stata richiesta la possibilità di aggiungere una GUI ad eggs, sembra che finalmente sia giunta l'ora.

Ho cominciato questo progetto durante il periodo delle feste di Natale e fine anno, mi è servito tra l'altro per formarmi con la libreria QT che non avevo mai usato.

Adesso è passato un po' di tempo, ho maturato un po' di esperienza e quindi - come dire - posso vergognarmi di meno di quello che ho realizzato, in sostanza un aiuto per chi con eggs è alle prime armi.

Ho cercato di riempire i vari campi con lunghi, tediosi e spropositati tooltip ed ho fatto del mio meglio, comunque visto che questo progetto è opensource, può essere migliorato da ognuno e ciascuno può collaborare.

L'interfaccia è questa:

C'è una toolbar con quattro bottoni:

• dad per configurare eggs;
• produce per creare la ISO;
• kill per rimuovere le ISO generate e lo spazio di lavoro;
• readme un rimando alla sezione PenGUI sul README di eggs.

Non ho aggiunto troppi bottoni, per semplificare, difatti le operazioni che servono con eggs per rimasterizzare un sistema sono essenzialmente queste.

I menu

Tutte le altre opzioni, sono riportate nel menù, abbiamo:

• File

  • Calamares
  • Kill
  • Status
  • Cuckoo
  • Exit

• Edit

  • eggs.yaml
  • tools.yaml

• Tools

  • Clean
  • PPA
  • Skel
  • Yolk

• Wardrobe

  • Get
  • List
  • Show
  • Wear

• Help

  • Users' guide
  • Blog
  • Repository
  • Telegram
  • About

Francamente non mi sembra di aver dimenticato niente, l'unica esclusione - voluta - è Cuckoo che ho si inserito nel menu File ma è disablilitato.

Naturalmente PenGUI utilizza eggs per eseguire i sui compiti, quindi eggs deve essere installato, nel caso eggs non sia installato verrà visualizzato un messaggio ed, eventualmente aperto un browser per installarlo.

Bottoni della toolbar

dad​

Come in eggs il comando dad va a modificare la nostra configurazione che si trova in /etc/penguins-eggs.d ed in particolare nel file eggs.yaml.

La differenza è che qua avete un form da riempire, invece di una interfaccia CLI nuda e cruda.

Una volta inseriti i dati, verrà aperto un Terminale di root e si procederà alla copia degli stessi su /etc/penguins-eggs.d/eggs.yaml

eggs è pronto a produrre la ISO!

produce​

Nella form di produce è possibile inserire tutte le varie opzioni presenti nel comando di eggs, diciamo che la sua funzione è costruire il comando utilizzando una interfaccia grafica.

Una volta effettuate le scelte, premete sul bottone "Generate" ed il comando vi apparirà nel form stesso. A questo punto potete produrre la ISO semplicemente cliccando sul bottone adiacente, verrà anche qui aperto un Terminale di root ed egge verrà avviato con i parametri generati.

Kill​

Kill semplicemente richiama sudo eggs kill di eggs sempre attraverso un Terminale di root.

Readme​

Come descritto in precedenza è un semplice rimando alla sezione su PenGUI del README di penguins-eggs.

Scaricare ed installare PenGUI

PenGUI viene caricato sulla pagina di penguins-eggs su sourceforge, e precisamente potete scaricarlo dal link PenGUI.

L'installazione, trattandosi di un pacchetto Debian è piuttosto semplice e standard: dpkg -i pengui-0.2.9_amd64.deb.

Il pacchetto, inoltre viene caricato anche sulla PPA di eggs, per cui se la avete configurata, verrà aggiornato automaticamente ad ogni rilascio.

That's all peoples!

Buon divertimento.

Some time ago I received this message about an eggs problem with plasma:

I have an error on calamares installer.
when i want to install the iso. during the partitioning automatically. it has the following error:

job set the label on partition /dev/sda1 to root partition table of partition /sda/sda1 does not support setting names. job ignored

The error is caused by Plasma settings → Removable Storage → Removable Devices → Uncheck On Login and On Attach and solved problem, calamares installed the system fine.

The Prince of Persia also sent us a new splash screen

Il Ritorno dello Jedi è il terzo episodio di Guerre Stellari, uscito nel 1983.

Forse è l'età - per questo mi deve essere rimasto in testa - con le Guerre Stellari quello che devo dire non c'entra niente, però volevo raccontarvi la novità del gradito ritorno dell'architettura i386 su penguins-eggs.

penguins-eggs è un programma scritto in typescript quindi compilare è qui utilizzato in maniera un po' improria. Sarebbe più corretto scrivere come sono riuscito a generare nuovamente il pacchetto su l'architettura i386 non più supportata da node.

Qua dobbiamo ringraziare la sua Maestà Debian.

Cercando di aiutare un utente alle prese con LMDE 6 "Faye" ho notato che sulla macchina era presente node18, grazie alla versione pacchettizzata da Debian.

Su Debian bullseye è presente solo node12, ed essendo passato da tempo a node16 - non si può fare - ma qua, con la versione 18 mi è venuto il dubbio e l'idea di provarci.

Eggs è costruito con oclif, e genero il pacchetto con lo stesso framework che - tra l'altro - racchiude l'eseguibile di node nel pacchetto stesso.

Se su Debian node18 esiste, perchè non provare a sostituirlo con un semplice link?

Ha funzionato!

Nota La storia è naturalmente un po' più lunga e non priva di una certa fatica, ma è la stessa che mi ha portato - usando sostanzialmente lo stesso schema - ad ottenere una versione arm64 funzionante.

Ma di questo parleremo la prossima volta.

E come la mettiamo con Visual Studio code?

Non sò quante volte ho bestemmiato in turco la mancanza di code su i386, ho tentato con lite, un editor LUA un po' somigliante; ho smadonnato con sublime - bello, ma diverso - alla fine, non usando più di tanto i386, m'ero adattato a geany.

Ecco il sistema per installare l'ultima versione di code funzionante su i386.

wget https://az764295.vo.msecnd.net/stable/c7d83e57cd18f18026a8162d042843bda1bcf21f/code_1.35.1-1560349847_i386.deb 

sudo dpkg -i ./code*.deb

Era pure facile! A saperlo, però.

Il futuro dei colibri

Naked - la versione CLI - e Colibri sono le due ISO ufficiali che pubblico per ogni rimasterizzazione di Arch, Debian, Devuan ed Ubuntu.

Colibri è interessante per chi vuole cimentarsi con gli stessi strumenti che utilizzo per creare eggs, naturalmente raccomando la versione amd64, ma attualmente è possibile utilizzare sia arm64 che i386 senza troppe rinunce.

In sostanza viene installato il desktop XFCE - senza troppi fronzoli - nodejs, npm, pnpm e l'editor code o codium nel caso di arm64.

Avere lo stesso sistema di sviluppo su tutte e tre le architetture supportate aiuta non poco diurante il debug.

A quando una versione per RISCV?

Ad inizio dicembre dovrebbe arrivarmi un computer a scheda singola VisionFive 2 Quad-core RISC-V StarFive JH7110 quad-core RISC-V con ben 8GB di RAM.

Il progetto Proxmox-port, grazie al quale ho trasformato la mia Raspberry Pi 4 in un server Proxmox VE, promette bene anche per quanto rigurda l'architettura RISCV.

Vediamo che succede, ci spero!

How to build a reproductive, naked (CLI) system​

Note: This article is an updated version of the previous post addaura, the script now is extended to include derivatives.

We are going to describe how to go from a minimal standard installation to a complete remasterable system using get-eggs scripts.

This procedure work on Arch rolling, Debian (buster, bullseye, bookworm), Devuan (chimaera and daedalus) and Ubuntu (bionic, focal and jammy) and - actually - on derivatives.

Arch​

I started with latest version of archiso: archlinux-2023.09.01-x86_64.iso.

Then, used archinstall to get a minimal installation. On Disk configuration choose Use a best-effort default configuration layout, then btrfs or ext4, as you prefer.

Among the packages I added: git, lsb-release, others packages will be installed later by get-eggs.

At this point, we MUST configure network, I just choose the most basic: Copy ISO configuration to installation.

Finally select install and wait it finish. Archinstall will propose you to chroot to continue configuration, answer no and reboot.

Debian/Devuan/Ubuntu​

On Debian and Devuan we start with a common netinst, without install nothing except standard system utilies

When the installation finish, reboot the system.

After reboot, we now must install git and sudo. Log on your installed system, and:

• su
• apt install git sudo
• /usr/sbin/adduser artisan sudo

We can now logout, and we are ready to the next step.

The procedure its about the same on Devuan.

After reboot, we need just to install git to be ready: sudo apt install git.

On Ubuntu, we don't have net-install but we can use server edition, again without install nothing except the minimal base. Here, at the end of installation I use to remove packages cloud-init and needrestart as we are not interested on.

Get and run get-eggs (all)​

• git clone https://github.com/pieroproietti/get-eggs
• cd get-eggs
• sudo ./get-eggs.sh

That will happen​

eggs will be installed and configured properly for the chosen distribution.

Arch​

get-eggs.sh will install few packages bash-completion, dialog, man-db, nano, openssh and wget and will add AUR repository to pacman.conf.

Then will install penguins-eggs.

Debian/Devuan and Ubuntu​

get-eggs.sh will install new ppa for penguins-eggs, then will install eggs and its dependencies.

Get wardrobe and wear a costume (all)​

Once eggs was installed, I proceeded to load the wardrobe and "dress" the system with the colibri costume.

• eggs wardrobe get
• sudo eggs wardrobe wear colibri At this point after rebooting, I found myself in the colibri graphical system.

Installing calamares​

We can install calamares with the command: sudo eggs calamares --install.

Clean​

After that, we can clean cached packages with command: sudo eggs tools clean.

Remastering our custom system​

Well, we are ready to remaster the system, just a little reconfiguration and cleaning before:

• sudo eggs dad -d
• sudo eggs tools clean
• sudo eggs produce --max --addons adapt

That's all folks!

Videos

These videos were made simply using kazam on a window, live, no audio or editing, I would need help preparing something more professional.

• From archiso to colibri (Arch Linux)
• From netinstall to colibri (Debian)

Quando è uscita la Raspberry Pi 4 con ben 4 GB di RAM, l'acquistai,non poteva mancare alla mia esperienza!

Invece, per quasi due anni mancò e di brutto, nonostante avessi preso anche un case con disco rigido SSD da ben 250 GB.

Installai Raspian, poi qualcosaltro... Vidi che la potevo usare come un PC con prestazioni scarse, avevo di fronte a me un i7 con 16 core, 16 GB di memoria e finì a prendere prima polvere, poi ad essere custodita in un cassetto.

La nascita di eggs per ARM è strettamente legata ad un tentativo fatto più per scrupolo che per convinzione di aiutare un utente che voleve rimasterizzare Linux Mint Debian Edition 6, uscito a settembre.

Gli consigliai di provare con la versione di eggs per i386, che era rimasta a due anni prima, magari facendo qualche modifica in /etc/os-release per fargli accettare LMDE6.

Il bello che anche funzionò, ma non ero soddisfatto.

Notai pure che LMDE6 disponeva comunque di nodejs 18.x, ed il motivo per cui ero stato costretto ad interrompere la versione per i386 era che nodesource non aggiornava più le versioni a 16 bit, la cui ultima era node12.

Chissà se può funzionare, devo aver pensato.

E provai a far girare penguins-eggs con la versione di nodejs per i386.

Andava... allora non mi restava che fare il pacchetto!

Sostituendo all'eseguibile di node un link a /usr/bin/node ed immettendo nodejs come dipendenza del pacchetto, questo funzionava egregiamente - anzi - era più leggero della versione per amd64, visto che non contenteva il binario di node.

Naturalmente vi furono anche altre modifiche dovute alla differenza di processore.

La versione per arm64​

A questo punto, sono anni che produco una versione non funzionante di eggs per ARM, perchè non provare la stessa operazione su arm?

Già ma quale: armel, armxx o arm64?

Dopo qualche prova, capii che la versione giusta era arm64 e provai con lo stesso script modificato per i386. Naturalmente non funzionò al primo colpo... anzi.

Il fatto di non disporre di una Raspberry o meglio di non saperla usare mi costrinse a utilizzare Proxmox VE per emulare una macchina virtuale con ARM64.

Non è troppo difficile ma tediosamente lento... in qualche modo però mi dava il modo di "pensare" e spesso anche di cucinare o fare dell'altro.

Ad ogni modo, ottenuta la macchina virtuale, iniziarono le prove... un'oretta a tentativo per una naked su arm64 del peso di circa 400 MB... un po' spararsi sui cosidetti.

Ma andò bene, il bambino nacque pur senza una vera e propria mamma.

Dove far girare la ISO creata

All'epoca, parliamo di inizio mese, il fatto che Raspberry utilizzi di massima uboot al posto di UEFI mi era ignoto, così come l'esistenza di un progetto per avviare raspberry con UEFI.

Cercai intorno tra conoscenti e non, trovai il "prodotto" e finalmente potevo far girare la ISO.

Si, ma non vedeva la WIFI, attacca e stacca fili, la tastiera comperata per lavorarci comunque partiva DOPO che s'era avviata... frustrazioni a non finire.

Un giorno installai manjaro ARM in versione per Raspberry e capii che dovevo mangiarne di biada per correre come loro... Un gioiello, veloce e facile da usare!

Però a me interessava altro, lo scopo non era farmi un piccolo PC ma avere la possibilità di testarci Proxmox VE di cui avevo trovato due versioni non ufficiali proprio per Raspberry appunto.

Questo avrebbe naturalmente agevolato non poco lo sviluppo, disporre di un virtualizzatore basato sul processore arm64 stesso invece di faticare ad emularlo.

Proxmox VE 8 arm64

Questa è la configurazione di una VM per arm64 su una installazione x64.

agent: 1
arch: aarch64
bios: ovmf
boot: order=scsi0;scsi1;net0
cores: 4
efidisk0: local-lvm:vm-103-disk-0,efitype=4m,pre-enrolled-keys=1,size=64M
ipconfig0: ip=192.168.2.251/32,gw=192.168.2.1
memory: 4096
name: arm64-clean
nameserver: 192.168.2.1
net0: virtio=62:F1:E4:BD:B9:FB,bridge=vmbr0
numa: 0
ostype: l26
scsi0: local-lvm:vm-103-disk-1,size=32G
scsi1: none,media=cdrom
scsihw: virtio-scsi-pci
serial0: socket
smbios1: uuid=cb608992-87ee-4641-8caf-412d24748e1b
sockets: 1
vga: serial0