Per rendere penguins-eggs pienamente compatibile con openKylin, sono stati necessari interventi mirati per gestire le peculiarità introdotte dalla distribuzione rispetto a una normale derivata Debian o Ubuntu. Le modifiche hanno riguardato in particolare la fase di avvio (initramfs), l'installazione del bootloader (GRUB) e la gestione grafica in macchina virtuale.

Ecco il riepilogo dettagliato delle modifiche e delle relative motivazioni tecniche.

1. Il blocco del bootloader e l'ESP Lock di openKylin​

La peculiarità di openKylin: In openKylin, /usr/sbin/grub-install non è il consueto script shell di GNU GRUB, bensì un wrapper in Python 3 scritto dal team di sviluppo della distribuzione. Questo script effettua un controllo di sicurezza preventivo confrontando l'UUID della partizione montata in --efi-directory con un valore cablato nel codice (2C9D-17A5). Quando un installer (come krill o Calamares) partiziona un nuovo disco generando un UUID casuale, il wrapper di openKylin interrompe il processo con un errore bloccante:

Refusing to update an ESP belonging to another installation

Cosa è stato modificato in eggs:

• Ripristino del vero grub-install: Durante l'installazione (install.bash.tmpl), eggs verifica la presenza del binario originale (/usr/sbin/grub-install.openkylin-original o tramite gestione dpkg-divert) e lo ripristina al posto del wrapper Python, consentendo a krill e Calamares di scrivere regolarmente il bootloader EFI sul nuovo disco.
• Pulizia degli hook OEM: Vengono rimossi automaticamente gli hook residui dell'installer OEM di openKylin:
  • /etc/grub.d/42_openkylin_multiboot
  • /etc/openkylin-installer
• Esclusioni di remastering: Gli stessi percorsi sono stati inseriti tra le esclusioni predefinite in create-exclude-list.go, evitando che artefatti e blocchi dell'installer del sistema sorgente finiscano nell'immagine ISO live.

2. Generazione dell'Initramfs e moduli Live​

La peculiarità di openKylin: Essendo una derivata Debian con forti personalizzazioni del kernel e del set di pacchetti base, la generazione dell'initramfs richiedeva l'inclusione esplicita dei componenti per lo stack live e per il supporto dei controller di archiviazione in ambiente virtualizzato (KVM/QEMU/Proxmox). Inoltre, il pacchetto BusyBox per l'initramfs può presentarsi nei repository con nomenclature differenti.

Cosa è stato modificato in eggs:

• Iniezione dei moduli kernel live: In remaster.bash.tmpl, prima di invocare mkinitramfs/update-initramfs, eggs forza in /etc/initramfs-tools/modules i moduli indispensabili per montare l'overlay e avviare il sistema live:
  • virtio_pci, virtio_blk, virtio_scsi (storage e virtualizzazione)
  • isofs, overlay (filesystem della live)
• Dipendenze di pacchettizzazione: In build.go, il campo delle dipendenze per la famiglia Debian è stato aggiornato con busybox-initramfs | busybox-static, garantendo la corretta risoluzione dei pacchetti necessari alla creazione dell'initramfs live anche sui repository di openKylin.

3. Riconoscimento e Sensing della Distribuzione​

Cosa è stato modificato in eggs:

• Mappatura nativa: In distro.go, openkylin è stata mappata esplicitamente come distribuzione di prima classe appartenente alla famiglia debian.
• Ereditarietà delle configurazioni: In index.yaml, openkylin è indicizzata per ereditare dinamicamente le ricette, i template e i moduli di provisioning della famiglia debian.

4. Display e Disallineamento del Mouse (eggs adapt / UKUI)​

La peculiarità di openKylin: Nell'ambiente desktop UKUI (basato sul compositore KWin) eseguito in macchina virtuale tramite protocollo SPICE, il ridimensionamento della finestra con xrandr non ricalcolava la matrice delle coordinate del puntatore, provocando uno scarto visivo tra la posizione del cursore grafico e l'effettiva area di clic.

Cosa è stato modificato in eggs:

• Riavvio automatico dell'agent SPICE: Nel comando eggs adapt, subito dopo l'esecuzione di xrandr, viene riavviato automaticamente il servizio spice-vdagent (sia a livello di demone di sistema se eseguito da root, sia a livello di istanza utente tramite pkill -x spice-vdagent && spice-vdagent), riallineando all'istante le coordinate del mouse senza dover terminare la sessione grafica.

5. Validazione Continua in CI ("The Furnace")​

Per garantire che nessun aggiornamento futuro comprometta la compatibilità raggiunta, openKylin è stata integrata nella pipeline di Continuous Integration automatica su Proxmox VE tramite un workflow dedicato (furnace-openkylin.yml), che esegue regolarmente il remastering end-to-end e il test di avvio su snapshot pulito.

1. Supporto RISCV64​

Il supporto e la build per l'architettura riscv64 sono stati creati e integrati nel codebase.

Compilazione & Packaging (build.go:42-46)​

• L'architettura riscv64 è gestita nel builder con le sue dipendenze specifiche (tra cui gdisk e genimage).
• Nella pipeline CI (.github/workflows/hammers.yml) è presente il job per debian-riscv64 con cross-compilazione (gcc-riscv64-linux-gnu, qemu-riscv64-static).

Remastering & Bootloader​

• Gestione DTB e rilevamento SpacemiT K1 / MuseBook M1 durante il remastering (coa/pkg/cmd/remaster.go).
• Copia e mapping dei binari UEFI (BOOTRISCV64.EFI) in bootloader-copy.sh:53-64 e GRUB target riscv64-efi per i template Debian, Arch, Fedora, openSUSE e Alpine.
• Boot UEFI puro con xorriso per riscv64.

Installer Krill & Hardware Dedicato​

• Supporto specifico per il layout a 6 partizioni e bootfs per SoC SpacemiT K1 / MuseBook in partition.go:35-45.
• Supporto scansione NVMe e flash U-Boot (spacemit/).

2. Supporto ARM64 (aarch64)​

Anche arm64 è completamente supportato e integrato.

Compilazione & CI ("The Furnace")​

• In hammers.yml:217-266 è presente la pipeline dedicata debian-arm64 che compila con cross-toolchain (gcc-aarch64-linux-gnu, libcrypt-dev:arm64, QEMU qemu-aarch64-static) e produce il pacchetto .deb nativo:

  make package GOOS=linux GOARCH=arm64 CC=aarch64-linux-gnu-gcc RUNNER=qemu-aarch64-static
  

Builder & Dipendenze (build.go:40-41)​

• Gestione delle dipendenze Debian per arm64, armhf, armel con genimage e grub-efi-arm64-bin.
• Il nome del pacchetto Debian rispetta la convenzione nativa arm64.

Bootloader & Remastering​

• Generazione e copia dei binari UEFI BOOTAA64.EFI (grubaa64.efi) via bootloader-copy.sh:58-75.
• Modalità Pure UEFI boot in xorriso.go:69.
• Target GRUB arm64-efi integrato nei moduli template di installazione per tutte le distribuzioni (Debian/Ubuntu, Arch/Manjaro, Fedora, openSUSE, Alpine).
• Filtro di compressione xz ottimizzato per evitare filtri BCJ x86 su arm64.

3. Generazione delle Immagini (ISO vs Raw Image)​

Su ARM64 (Pronto)​

• I moderni sistemi e schede ARM64 (server, VM QEMU/KVM, Mac Apple Silicon con Asahi/Linux, Raspberry Pi con firmware UEFI EDK2, Oracle Ampere, ecc.) utilizzano lo standard UEFI (AArch64).
• La pipeline ISO con xorriso (Pure UEFI boot, BOOTAA64.EFI) è già predisposta e funzionante nativamente.

Su RISCV64 (Da perfezionare)​

• Le board RISC-V attuali (come SpacemiT K1 / MuseBook M1) non utilizzano un firmware UEFI standard per il boot da ISO CD-ROM tradizionale: usano U-Boot/OpenSBI con Device Tree (.dtb) e richiedono immagini raw disco (.raw / .img) a partizioni multiple (bootinfo, fsbl, env, opensbi, uboot, bootfs, rootfs) tramite genimage.
• Nel codice è già presente la logica che intercetta riscv64 (generate-plan.go:142-165) per sostituire lo step xorriso con make-img (genimage), ma resta da perfezionare e testare:
  • La creazione di un'immagine effettivamente avviabile sia come ISO ibrida UEFI (per hardware RISC-V UEFI-compliant) sia come immagine raw disco (.img flashabile) per SBC e laptop come SpacemiT K1 / MuseBook.

Supporto hardware

Prima di concludere, voglio condividere una realtà molto concreta dello sviluppo open-source indipendente.

Oggi il nostro software è letteralmente più avanti dell'hardware che ho sulla scrivania. Nel nostro codebase, il supporto per ARM64 e RISC-V 64 è già scritto, compilato e integrato. Abbiamo preparato le pipeline di cross-compilazione, i bootloader Pure UEFI — BOOTAA64.EFI e BOOTRISCV64.EFI — e persino il supporto al partizionamento dedicato per le prime schede RISC-V come lo SpacemiT K1.

Tuttavia, generare e validare filesystem live, compressioni squashfs e installer bare-metal tramite emulazione software è un'operazione proibitiva, che si scontra con i limiti dell'emulazione proprio dove serve testare il comportamento reale della macchina.

Chiudo quindi questo intervento con una richiesta diretta ai produttori di hardware e ai partner dell'ecosistema presenti qui oggi. Per portare il remastering universale di Debian, Arch, Fedora, openSUSE e openKylin sulle vostre architetture, a penguins-eggs mancano solo due macchine reali sul banco di prova:

Un sistema RISC-V conforme allo standard RVA23 e BRS (Boot and Runtime Services) — come il nuovo SpacemiT K3 — per validare sul ferro il boot diretto da ISO UEFI standard.

Un sistema ARM64 conforme a SystemReady per la verifica nativa delle ISO AArch64.

Il codice è già pronto. Se ci mettete a disposizione il silicio, io mi assicurerò che qualsiasi utente o sviluppatore Linux possa rimasterizzare, clonare e installare il proprio sistema sul vostro hardware con un solo comando.

Grazie.