2 posts tagged with "oadc2026"

1. How I first came across openKylin​

As the author of penguins-eggs—a polymorphic remastering tool written in Go that turns running Linux systems into installable live ISOs—I am constantly looking for distributions that push the boundaries of the Linux ecosystem across x86_64, ARM64, and RISC-V.

I first came across openKylin while exploring the Chinese open-source landscape and its strong focus on independent desktop development and RISC-V hardware. Testing penguins-eggs on openKylin was a natural challenge: I wanted to verify if my family-based detection engine (which parses /etc/os-release to map distributions to core families like Debian, Arch, Alpine, and openSUSE) could seamlessly adapt to a flagship independent distribution.

2. How I used penguins-eggs to create two editions: Naked and XFCE4​

Using penguins-eggs alongside its declarative provisioning engine (penguins-chef), I applied a modular approach to openKylin, first creating the naked version, just a remaster of the server edition capable to be installed, then creating colibri my custom workstation where I can develop penguins-eggs in my same familiar context but using different distros:

• The naked Edition (Pure CLI Seed): By stripping away the graphical layer down to a minimal, rock-solid core, I generated an ultra-lightweight command-line live ISO installable via Krill (our TUI system installer). This "Darwinian" seed contains only the essential structural genome of openKylin, making it ideal for servers, containers, virtual machines, or as a clean starting point for developers to build their own custom systems.
• The xfce4 Edition (Lightweight Desktop): Starting from the minimal naked base (or directly remastering the system via YAML recipes), I dressed openKylin with XFCE4 and the Calamares graphical installer. This edition offers a fast, traditional, and low-resource desktop environment that runs smoothly even on older hardware or resource-constrained virtual machines, while preserving full compatibility with openKylin's underlying repositories and kernel.

Furthermore, with the --clone flag (a "Lamarckian" remaster), any user working on these editions can encapsulate their personal /home and custom configurations into a protective ISO membrane, ready to be restored onto a new machine if their hardware fails.

I was also sorry to see that Plasma, GNOME, and other desktop environments are no longer supported; while I find it a real pity from my perspective, I fully understand the reasoning behind this choice.

3. The challenges encountered and how I tackled them​

While openKylin belongs to the Debian family at its core, it introduces specific security and architectural mechanisms that required tailored engineering inside penguins-eggs:

• Bypassing the Bootloader ESP Lock: In openKylin, /usr/sbin/grub-install is replaced by a Python 3 wrapper that checks the EFI System Partition against a hardcoded UUID (2C9D-17A5), aborting third-party installations (Krill or Calamares) with the error: Refusing to update an ESP belonging to another installation. I solved this by having eggs automatically restore the original GNU GRUB binary (/usr/sbin/grub-install.openkylin-original) during installation, while removing OEM installer hooks (/etc/grub.d/42_openkylin_multiboot and /etc/openkylin-installer) and excluding them from the live ISO.
• Live Initramfs & Virtualization Modules: To guarantee reliable live booting across bare metal and hypervisors (KVM/QEMU/Proxmox), I configured eggs to explicitly inject virtio_pci, virtio_blk, virtio_scsi, isofs, and overlay modules into /etc/initramfs-tools/modules before generating the initramfs, and updated package dependencies to support busybox-initramfs | busybox-static.
• Fixing Mouse Offset in Virtual Machines (eggs adapt): When resizing a VM display via xrandr under SPICE, the cursor coordinate matrix did not recalculate automatically, causing a pointer offset. I updated eggs adapt to restart spice-vdagent immediately after running xrandr, realigning the mouse cursor on the fly without logging out.

4. What we achieved so far: the results of this work​

Today, openKylin is supported as a first-class citizen in penguins-eggs:

1. Native Support & Inheritance: openkylin is natively mapped in distro.go and indexed in index.yaml to dynamically inherit Debian family templates, scripts, and wardrobe costumes.
2. Continuous Automated Testing ("The Furnace"): openKylin is integrated into my automated Proxmox VE CI pipeline (furnace-openkylin.yml), where every commit is validated through an end-to-end remastering process and a clean-snapshot boot test.
3. Freedom to Remaster: Any openKylin developer or user can now generate custom naked servers, lightweight xfce4 or ukui customized workstations, or full personal backups in minutes with a single command (sudo eggs produce).

Bringing a universal remastering engine beyond x86_64 requires adapting not just the compiler toolchain, but the entire boot sequence, partition layout, and image generation pipeline. Here is the current technical status of RISCV64 and ARM64 (aarch64) support inside penguins-eggs, along with our roadmap for bare-metal validation.

1. RISCV64 Architecture Support​

Support and build pipelines for the riscv64 architecture are already written, compiled, and integrated directly into the penguins-eggs codebase:

• Compilation & Packaging (build.go): The builder natively handles riscv64 and its architecture-specific dependencies, including gdisk and genimage. In our CI pipeline (.github/workflows/hammers.yml), a dedicated debian-riscv64 job cross-compiles the binary suite using gcc-riscv64-linux-gnu and qemu-riscv64-static.
• Remastering & Bootloader: During the remastering phase (coa/pkg/cmd/remaster.go), eggs includes dedicated logic for Device Tree Blob (DTB) management and hardware detection for SpacemiT K1 / MuseBook M1 systems. It maps and copies UEFI binaries (BOOTRISCV64.EFI) in bootloader-copy.sh, supports the riscv64-efi GRUB target across Debian, Arch, Fedora, openSUSE, and Alpine templates, and configures pure UEFI boot via xorriso.
• Krill Installer & Dedicated Hardware: For bare-metal installation, our TUI installer (Krill) implements the specific 6-partition layout and bootfs structure required by SpacemiT K1 / MuseBook SoCs (partition.go), complete with NVMe bus scanning and U-Boot flashing routines (spacemit/).

2. ARM64 (aarch64) Architecture Support​

The arm64 architecture is fully supported and integrated across all stages of the build and remastering lifecycle:

• Compilation & CI ("The Furnace"): In hammers.yml, a dedicated debian-arm64 pipeline compiles the project via cross-toolchain (gcc-aarch64-linux-gnu, libcrypt-dev:arm64, and qemu-aarch64-static) to produce native .deb packages:

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

• Builder & Dependencies (build.go): Dependency resolution for arm64, armhf, and armel is natively configured with genimage and grub-efi-arm64-bin, strictly adhering to standard Debian architecture naming conventions.
• Bootloader & Remastering: eggs handles the generation and copying of BOOTAA64.EFI (grubaa64.efi) via bootloader-copy.sh:58-75 and enables Pure UEFI boot mode in xorriso.go:69. The arm64-efi GRUB target is integrated across all supported distribution families (Debian/Ubuntu/openKylin, Arch/Manjaro, Fedora, openSUSE, and Alpine), while xz SquashFS compression is automatically tuned to avoid x86 BCJ filters on ARM64.

3. Image Generation: Hybrid ISO vs. Raw Disk Image​

While the high-level remastering philosophy remains identical across architectures, the final bootable artifact must adapt to how different platforms handle firmware and storage:

• On ARM64 (Production-Ready): Modern ARM64 platforms—including servers, QEMU/KVM virtual machines, Apple Silicon Macs running Linux, Raspberry Pi boards with EDK2 UEFI firmware, and Oracle Ampere instances—rely on standard AArch64 UEFI. Consequently, our standard xorriso pipeline (Pure UEFI boot via BOOTAA64.EFI) works natively out of the box. Anche disponendo solo di una comune Raspberry 4, ho fatto numerosi test nel passato configurandola come un server proxmox grazie al progetto cinese

• On RISCV64 (Bridging Raw Images and UEFI ISOs): Current first-generation RISC-V boards (such as the SpacemiT K1 / MuseBook M1) do not yet use standard UEFI firmware to boot from traditional CD-ROM ISO images. Instead, they rely on U-Boot/OpenSBI with a hardware-specific Device Tree (.dtb) and expect multi-partition raw disk images (.raw / .img containing bootinfo, fsbl, env, opensbi, uboot, bootfs, and rootfs) built via genimage.

  In generate-plan.go, eggs intercepts riscv64 targets to replace the xorriso step with make-img (genimage). Our next milestone is refining and validating this dual output on real hardware: generating both flashable .img raw disk images for current U-Boot SBCs/laptops and standard UEFI hybrid ISOs for upcoming UEFI-compliant RISC-V systems.

The solution is naturally to use the ISO format for everyone, as I have been doing for years on ARM using a Raspberry Pi 4 and the work of Chinese developer jiangcuo, who in recent years managed the famous **Proxmox-Portéé ecosystem, now pxvirt.

4. Hardware Support: A Call for Silicon​

Before concluding, I want to share a very concrete reality of independent open-source development.

Today, our software is literally ahead of the hardware sitting on my desk. Inside our codebase, support for both ARM64 and RISC-V 64 is already written, compiled, and integrated. We have built the cross-compilation pipelines, configured the Pure UEFI bootloaders—BOOTAA64.EFI and BOOTRISCV64.EFI—and even implemented dedicated partitioning layouts for early RISC-V hardware like the SpacemiT K1.

However, generating and validating live filesystems, SquashFS compression, and bare-metal installers through software emulation is a prohibitive task. Emulation hits a wall right where we need to test real-world machine behavior, firmware handoffs, and storage controllers.

I would like to close this talk with a direct invitation to the hardware manufacturers and ecosystem partners here today. To bring universal, one-command remastering for openKylin, Debian, Arch, Fedora, and openSUSE to your architectures, penguins-eggs only needs two physical machines on the testbench:

1. An RVA23 and BRS (Boot and Runtime Services) compliant RISC-V system—such as the upcoming SpacemiT K3—to validate direct, standard UEFI ISO booting on real silicon.
2. An ARM64 SystemReady-compliant machine for native verification of AArch64 live ISOs and bare-metal installations.

The code is ready. If you provide the silicon, I will make sure that any Linux developer or user can remaster, clone, and deploy their system on your hardware with a single command.

Thank you!