furtka/iso
Daniel Maksymilian Syrnicki c080764c7e
All checks were successful
Build ISO / build-iso (push) Successful in 17m5s
CI / lint (push) Successful in 27s
CI / test (push) Successful in 40s
CI / validate-json (push) Successful in 25s
CI / markdown-links (push) Successful in 12s
fix(furtka): move assets/ to repo top level so Caddy + systemd find it
Root cause of today's 403 on a fresh install: assets/ lived inside the
Python package at furtka/assets/, so the resource-manager tarball
extracted to /opt/furtka/versions/<ver>/furtka/assets/. But Caddyfile
has `root * /opt/furtka/current/assets/www`, systemd units point at
/opt/furtka/current/assets/bin/furtka-status, and the install-time
`systemctl link /opt/furtka/current/assets/systemd/*.service` expected
the top-level layout. All three found nothing:

- Caddy → 403 Forbidden (empty/missing document root)
- systemctl link → silent no-op, nothing ever linked into
  /etc/systemd/system/
- furtka-api.service + furtka-reconcile.service → "inactive" because
  they were never registered

Nothing in the Python package ever imported furtka.assets — these are
shell scripts, HTML/CSS, systemd units, and a Caddyfile, which is
config data, not package data. Promoting assets/ to the repo root
matches how it's referenced everywhere downstream and eliminates the
path mismatch.

Changes:
- git mv furtka/assets assets
- iso/build.sh: tarball-staging step now also `cp -a "$REPO_ROOT/assets"`
  so the tarball ships ./assets at its root, and the live-ISO copy
  reads from $REPO_ROOT/assets instead of $REPO_ROOT/furtka/assets.
- scripts/build-release-tarball.sh: same for release tarballs.
- webinstaller/app.py: _resolve_assets_dir's dev fallback walks one
  level up to REPO_ROOT/assets/.
- tests/test_webinstaller_assets.py: ASSETS constant updated.

Tests still green (150/150) because both paths were fs-level — no
code imports changed. Next ISO build will land assets at the path
everything downstream expects.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-16 15:26:10 +02:00
..
overlay fix(iso): muzzle archinstall sync_log_to_install_medium on Py 3.14 2026-04-16 15:17:19 +02:00
build.sh fix(furtka): move assets/ to repo top level so Caddy + systemd find it 2026-04-16 15:26:10 +02:00
README.md feat: post-install bootstrap — land in Furtka after reboot 2026-04-14 19:51:50 +02:00

Live ISO build

Builds a bootable Arch-based live ISO that auto-starts the Flask webinstaller from ../webinstaller/ on boot. User plugs in a USB, boots, and the installer wizard comes up on http://proksi.local:5000 (or the raw IP shown on the console).

Runnable locally (below) or through Forgejo Actions — .forgejo/workflows/build-iso.yml builds on every push to main and on manual workflow_dispatch. The ISO lands as an artifact named furtka-iso, retained for 14 days. Feature branches don't trigger the ISO build; see memory/project_ci_branching for why.

Run a build locally

Needs a host with Docker. Disk space required: ~15 GB scratch during the build, ~1.5 GB for the final ISO.

./iso/build.sh

Output ISO ends up in iso/out/furtka-<date>-x86_64.iso. Around 310 min on a 4-core VM. First run is slower because it pulls archlinux:latest and all packages from upstream.

The script re-execs itself inside a privileged archlinux:latest container. That's so mkarchiso has root + loop-mount access without polluting the host — Ubuntu hosts don't ship archiso natively anyway.

What gets baked in

The build starts from Arch's stock releng profile (the same one used to build the official Arch ISO), then overlays our customizations from overlay/:

Overlay file Effect
overlay/packages.extra Appended to the package list. Adds python, python-flask, avahi, nss-mdns
overlay/profiledef.sh Appended to profiledef.sh. Renames the ISO to furtka-* with a dated version
overlay/airootfs/opt/furtka/ Directory where webinstaller/ is copied at build time
overlay/airootfs/etc/systemd/system/ Contains furtka-webinstaller.service + a symlink into multi-user.target.wants/ so it auto-starts on boot

The systemd service runs flask --app app run --host 0.0.0.0 --port 5000 under /opt/furtka. The 0.0.0.0 binding is important — the Flask default is localhost-only, which wouldn't be reachable from another machine on the LAN.

mDNS (proksi.local) via avahi is installed but not yet wired. First milestone is just "boot → browser → wizard at raw IP". Naming comes next.

Test flow

  1. Build: ./iso/build.sh
  2. Copy the ISO to your Proxmox host's ISO storage (typically /var/lib/vz/template/iso/). Browser uploads of 1.5 GB truncate silently — prefer scp over the Proxmox WebUI.
  3. Create a VM with:
    • 2 vCPU, 4 GB RAM, 20 GB disk (empty)
    • BIOS: OVMF (UEFI), add EFI Disk on local-lvm. SeaBIOS fails to load ldlinux.c32 from our ISO; only the UEFI path works reliably.
    • Secure Boot disabled. Our GRUB isn't signed, so Secure Boot rejects it with Access Denied. Either boot into OVMF setup (Esc during boot) → Device Manager → Secure Boot Configuration → Attempt Secure Boot [ ] → F10 → reboot. Or remove the EFI Disk and re-add it with "Pre-Enroll keys" unchecked.
    • CD-ROM attached with the Furtka ISO
    • Boot order: CD before disk
    • Network: same bridge as your LAN, DHCP
  4. Start the VM. Wait ~30 s for boot.
  5. Find its IP in Proxmox's VM summary (or your router's DHCP table)
  6. Open http://<vm-ip>:5000 — the existing 3-screen wizard should be there

What you see after install + reboot

Once archinstall finishes and you click Reboot now, the VM comes up into the installed system. No more port :5000 — the wizard ISO is gone. Instead:

  • Console: agetty shows Furtka is ready. Open http://<hostname>.local … with the IP fallback underneath.
  • Browser at http://<hostname>.local (default http://proksi.local): Caddy-served landing page with three live status tiles (uptime, Docker version, free disk) refreshed every 30 s by furtka-status.timer.
  • SSH: ssh <user>@<hostname>.local works; docker ps works without sudo because the user is in the docker group.

This is a demo shell — no Authentik, no app store yet. The landing page lives at /srv/furtka/www/, served by Caddy on :80 per /etc/caddy/Caddyfile. All of this is written into the target by webinstaller/app.py's _post_install_commands via archinstall's custom_commands.

Known rough edges

  • Disk space: the first time you build on a fresh host, the squashfs/xorriso steps need ~15 GB free. If the host's LVM-root is smaller, xorriso silently dies at the very end with "Image size exceeds free space on media".
  • No HTTPS yet. The Furtka plan is "local CA + green padlock on https://proksi.local" — that's a later milestone. For now, plain HTTP.
  • Boot USB could appear as an install target on bare metal. On a VM the ISO is a CD-ROM (filtered) and SATA is the only disk, so the picker only shows the install target. On bare metal with a USB stick, the USB is TYPE=disk and shows up alongside the real install drive; a user could in theory pick the USB they just booted from. Mitigating this needs detecting the boot media (via findmnt /run/archiso/bootmnt or similar) and filtering it out in webinstaller/drives.py.