daniel/furtka
1
1
Fork 0
Code Issues 2 Pull requests 2 Projects 1 Releases 19 Packages Wiki Activity Actions

fix: pin archinstall, Limine on 32-bit UEFI, hostname-scoped 302 HTTPS redirect #20

Open
daniel wants to merge 0 commits from fix/followups-archinstall-ia32-https into main
pull from: fix/followups-archinstall-ia32-https
merge into: daniel:main
Conversation 0 Commits - Files changed -
daniel commented 2026-09-28 14:24:59 +02:00
Owner
Copy link

Three follow-ups from the #19 bug scan. 413 tests, ruff check and ruff format --check green.

1. Pin archinstall (iso/build.sh)

  • The webinstaller imports archinstall internals and sed-patches one of its files. Until now every ISO build took whatever the Arch repos shipped that day.
  • The build now downloads archinstall 4.4-1, the version every recent build and the 26.20 bench install used, from archive.archlinux.org. It checks the sha256 and serves it from a local [furtka-pinned] repo placed before [core], and only the build uses that repo.
  • The build fails with a clear message once Arch's Python moves past 3.14. Bump steps are in iso/README.md.
  • Verified in archlinux:latest (podman): pacman resolves furtka-pinned archinstall 4.4-1.

2. 32-bit UEFI (webinstaller/app.py)

  • On Bay Trail / Cherry Trail boxes we chose systemd-boot, but Arch ships no ia32 build of it. archinstall 4.4's GRUB path hardcodes --target={platform.machine()}-efi, which is also wrong there.
  • Its Limine path installs both BOOTIA32.EFI and BOOTX64.EFI and picks the boot entry based on fw_platform_size. So when fw_platform_size is 32 we now use Limine. The default FAT /boot passes its layout check.
  • Checked against the archinstall 4.4 source only; not booted on 32-bit UEFI yet.

3. HTTPS redirect (furtka/https.py)

  • The redirect now covers only <hostname>.local and <hostname>, and it is a 302:
    • Previously every host was redirected, including bare IPs, which have no certificate.
    • Browsers cached the old 301 even after HTTPS was switched off.
  • Self-update rewrites the old snippet only if it is still the untouched legacy content.
  • caddy validate (caddy:2) accepts the full Caddyfile including both snippets.
  • Browsers that already cached the old 301 keep it until their cache is cleared.

Not tested yet

  • The full ISO build plus a VM install with the pinned archinstall. That happens in the main pipeline after the merge.
  • An actual boot on 32-bit UEFI hardware, or in QEMU with ia32 OVMF.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wq1hzUp4ZmCKHDuLKCnu73

Three follow-ups from the #19 bug scan. 413 tests, `ruff check` and `ruff format --check` green. ## 1. Pin archinstall (`iso/build.sh`) - The webinstaller imports archinstall internals and sed-patches one of its files. Until now every ISO build took whatever the Arch repos shipped that day. - The build now downloads **archinstall 4.4-1**, the version every recent build and the 26.20 bench install used, from `archive.archlinux.org`. It checks the sha256 and serves it from a local `[furtka-pinned]` repo placed before `[core]`, and only the build uses that repo. - The build fails with a clear message once Arch's Python moves past 3.14. Bump steps are in `iso/README.md`. - **Verified** in `archlinux:latest` (podman): pacman resolves `furtka-pinned archinstall 4.4-1`. ## 2. 32-bit UEFI (`webinstaller/app.py`) - On Bay Trail / Cherry Trail boxes we chose systemd-boot, but Arch ships no ia32 build of it. archinstall 4.4's GRUB path hardcodes `--target={platform.machine()}-efi`, which is also wrong there. - Its Limine path installs both `BOOTIA32.EFI` and `BOOTX64.EFI` and picks the boot entry based on `fw_platform_size`. So when `fw_platform_size` is 32 we now use **Limine**. The default FAT `/boot` passes its layout check. - Checked against the archinstall 4.4 source only; not booted on 32-bit UEFI yet. ## 3. HTTPS redirect (`furtka/https.py`) - The redirect now covers only `<hostname>.local` and `<hostname>`, and it is a **302**: - Previously every host was redirected, including bare IPs, which have no certificate. - Browsers cached the old 301 even after HTTPS was switched off. - Self-update rewrites the old snippet only if it is still the untouched legacy content. - `caddy validate` (caddy:2) accepts the full Caddyfile including both snippets. - Browsers that already cached the old 301 keep it until their cache is cleared. ## Not tested yet - The full ISO build plus a VM install with the pinned archinstall. That happens in the main pipeline after the merge. - An actual boot on 32-bit UEFI hardware, or in QEMU with ia32 OVMF. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Wq1hzUp4ZmCKHDuLKCnu73
daniel added 4 commits 2026-09-28 14:24:59 +02:00 
The webinstaller imports archinstall internals and sed-patches one of its
files, so every ISO build silently picked up whatever archinstall Arch
shipped that day — any upstream release could break all installs with no
change on our side. build.sh now downloads the validated build from
archive.archlinux.org, checks its sha256, and serves it from a local
[furtka-pinned] repo ahead of [core] in the build's pacman.conf.

The build fails with a clear message once Arch's Python moves past the one
the pinned package targets. Verified in an archlinux:latest container:
pacman resolves 'furtka-pinned archinstall 4.4-1'. Bump steps in
iso/README.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wq1hzUp4ZmCKHDuLKCnu73
Atom Bay Trail / Cherry Trail mini-PCs and tablets have a 64-bit CPU behind
32-bit UEFI. We picked systemd-boot there (Arch ships no ia32 build), and
archinstall 4.4's GRUB path hardcodes --target=x86_64-efi, so the installed
system could not boot. archinstall's Limine path copies both BOOTIA32.EFI
and BOOTX64.EFI and chooses the entry by /sys/firmware/efi/fw_platform_size;
the default layout's FAT /boot satisfies its layout check. 64-bit UEFI and
BIOS keep systemd-boot / GRUB.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wq1hzUp4ZmCKHDuLKCnu73
The force-HTTPS snippet was 'redir https://{host}{uri} permanent':
- every Host was redirected, including a bare IP that the tls-internal
  block has no certificate for — devices reaching the box by IP (no mDNS
  on Android / older Windows, the console IP fallback) couldn't load the
  UI at all
- 301 is cached by browsers, so switching HTTPS off kept bouncing them to
  a dead :443

Now a host matcher limits the redirect to <hostname>.local and <hostname>
and it's a 302. Self-update rewrites the old snippet if it is still the
untouched legacy content. Browsers that already cached the old 301 keep it
until their cache is cleared.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wq1hzUp4ZmCKHDuLKCnu73
docs(changelog): archinstall pin, 32-bit UEFI, HTTPS redirect
All checks were successful
CI / lint (pull_request) Successful in 26s
Details
CI / test (pull_request) Successful in 1m45s
Details
CI / validate-json (pull_request) Successful in 24s
Details
CI / markdown-links (pull_request) Successful in 21s
Details
ff5fe6f1c6 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wq1hzUp4ZmCKHDuLKCnu73
All checks were successful
CI / lint (pull_request) Successful in 26s
Required
Details
CI / test (pull_request) Successful in 1m45s
Required
Details
CI / validate-json (pull_request) Successful in 24s
Required
Details
CI / markdown-links (pull_request) Successful in 21s
Details
This branch is already included in the target branch. There is nothing to merge.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin fix/followups-archinstall-ia32-https:fix/followups-archinstall-ia32-https
git checkout fix/followups-archinstall-ia32-https
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: daniel/furtka#20
No description provided.
Delete branch "fix/followups-archinstall-ia32-https"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?