Repository navigation
iso/ (live-build) is missing several required Calamares module configs — is there a working version somewhere? #27
Description
Problem / motivation
hile testing the GRUB fix from PR #26 on a real install (Proxmox VM, OVMF/UEFI), I built an ISO from iso/build.sh per docs/BUILD.md and hit a chain of missing/incomplete Calamares configs that suggest iso/ was never finished:
- Desktop mismatch —
iso/builds Hyprland+DMS, butdocs/BUILD.md, the README, CHANGELOG and release notes all describe KDE Plasma.theme/also ships a full KDE/Plasma theme (Kvantum, plasma-theme, look-and-feel) thatiso/never wires in. etc/calamares/modules/unpackfs.confdoesn't exist — install failed immediately with "Bad unpackfs configuration - There is no configuration information."etc/calamares/modules/packages.confdoesn't exist — failed with "Bad backend backend=None" (schema requiresbackend).grub-installfails inside the Calamares chroot:grub-install: error: cannot find a device for /boot/efi (is /dev mounted?), even thoughfindmntfrom the live session shows/boot/eficorrectly mounted on/dev/sda1(vfat) under/tmp/calamares-root-.../boot/efi. Looks like/devisn't fully populated/bind-mounted inside the target chroot at the pointbootloaderruns.- None of the
apps/(tuner, hub, ai-panel, monitor, kernel-manager…) get installed byiso/at all.
I added the missing configs (unpackfs.conf, packages.conf) and swapped the desktop to KDE to match the docs — those are in PR #26 branch — but #4 looks like it needs your actual working Calamares module set (or whatever you run before eggs produce on the dev board) to compare against, since I don't have a second reference to diff.
Would you be willing to share the real /etc/calamares/modules/* you use (even just as a gist, redacted if needed), or point at where in the eggs/penguins-eggs flow the equivalent gets generated? That would save a lot of guesswork for anyone trying to build from iso/ as documented.
Proposed solution
Upload or share
Area
Other
Alternatives considered
No response
Activity
MTSistemi commentedon Aug 15, 2026
You were right, and it was worse than "missing a few module configs":
iso/had Hyprland as its desktop. The package list pulled inhyprland,wofi,mako,swaylock, and the two SDDM hooks set the session tohyprland. Nothing KDE anywhere, while the system we actually ship has been Plasma for months. Theiso/tree had drifted from the product to the point of describing a different distribution.Fixed in 70f215d:
10-desktop-hyprland.list.chroot→10-desktop-kde.list.chroot. The package names are not hand-picked: they are the packages actually marked manually-installed on the BC-250 development board, so the list describes the system users really get.plasmax11. X11 rather than Wayland because that is what the board actually runs.build.shannounced "Debian forky | Hyprland+DMS | kernel 7.0.10" — wrong on all three counts. Now sid, Plasma 6, 7.1.7.Your Calamares modules from #26 are in, both of them:
shellprocess@boot_reconfigure.confandskillfish-fix-boot-extents, wired into the sequence afterbootloader. I had left those out when I thoughtiso/was a dead branch. It is not being dropped — so they belong there, and the comments you wrote explaining the$...expansion trap in shellprocess YAML are worth keeping on their own.While in there, 231,000 lines of live-build artefacts came out of the repository:
chroot.filesalone was 225,390 lines, a listing of every file inside a May build.iso/.gitignorenow keeps them out.What is still missing, and I would rather say it than let you discover it: none of this has been through an actual
lb build. The changes are consistent and syntax-checked, but a KDE live-build ISO has not been produced or booted from this tree. That is the next step, and it is also the honest condition for callingiso/supported again — if it is not built and booted at least once per release, it will drift right back.If you want to take that run, say so and I will stay out of your way. Otherwise we will do it here and report the result on this issue. Keeping it open until then.
MTSistemi commentedon Aug 15, 2026
It builds.
P: Build completed successfully, and a 2.9 GBSkillFishOS-amd64.hybrid.isocame out ofiso/on real hardware.The tree needed more than the missing module configs you spotted, so here is what it took, in case you build from it:
hyprland,wofi,mako,swaylock— with nothing KDE, while we have shipped Plasma for months. Rewritten from the packages actually installed on the board minus the Depends closure, because--apt-recommends falsemeans Recommends never come back.kwin-x11was the sharp edge: without it theplasmax11session starts with no window manager at all.settings.conflisted 19 module instances andmodules/had 5 files.unpackfs.conf— the module that copies the system onto the disk — was one of the missing ones. Now 14, validated against the 3.4.2 schema. The btrfs subvolumes were infstab.conf, where nothing reads them; they belong tomount.bootloader, and fix eggs' own boot-fix from silently going stale #26 are in, wired afterbootloader.kernel-7.0.10-skillfishoswhile everything else said 7.1.7. That did not fail the build, it silently produced an image with June's kernel.ca-certificateswas missing from--debootstrap-options, so the firstapt updateover HTTPS died before installing anything.0115-ssh-debughook, marked "remove for release" but active, setPermitRootLogin yesand root's password to a fixed string, with a service restoring it at every boot — and it lands in the squashfs. Removed. For the record I checked the published 26.06.3: it is not there, so released media were never affected.Verified in the produced image:
/live/vmlinuz-7.1.7-skillfishos-genericand its initrd are present (the--linux-packages nonetrap), and El Torito has both a BIOS and a UEFI entry.Two real defects the build surfaced, filed separately as #30: the
nct6687fan module fails to build in the chroot, and hook0050-nct6687gets a 404 fromcurlbefore that. Fan control matters on this board, so it is not cosmetic.Closing this one, since the question it asked — "is there a working version somewhere?" — now has an answer: yes, in the tree, and it produces a bootable ISO. Thanks for pushing on it; the tree would still be quietly wrong otherwise.
One honest caveat: the ISO has been built and inspected, not yet booted. That is the next step, and if it misbehaves this reopens.