Repository navigation
Boot and install Omarchy on Snapdragon X ARM64 systems - #129
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds end-to-end support for building and booting the Omarchy installer ISO on aarch64 (targeting Snapdragon X/Windows-on-ARM laptops), including ARM-specific boot flow (UKI + DTBs), package/mirror handling for Arch Linux ARM, and native ARM CI.
Changes:
- Make ISO build and installer logic architecture-aware (aarch64 vs x86_64), including Limine EFI binary selection and Node artifact selection.
- Add Snapdragon/Windows-on-ARM boot and firmware handling (UKI with DTBs + staged vendor firmware extraction).
- Add a native GitHub Actions aarch64 build workflow and update offline-mirror handling for
.pkg.tar.{zst,xz}.
Reviewed changes
Copilot reviewed 16 out of 17 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
configs/profiledef.sh |
Select aarch64 bootmodes and airootfs compression; add aarch64-only staged file permissions. |
configs/packages.aarch64 |
New aarch64 live environment package list. |
configs/grub/grub.cfg |
Add arm64 default entry that chainloads a UKI and Snapdragon kernel params. |
configs/airootfs/usr/share/omarchy-iso/orchestrator/phases_impl.py |
Limine EFI naming per-arch; stage/copy Qualcomm firmware; Node tarball selection per-arch. |
configs/airootfs/usr/share/omarchy-iso/orchestrator/context.py |
Default Limine EFI binary per architecture. |
configs/airootfs/root/configurator |
Per-arch Limine binary; aarch64 mirror server handling; kernel detection for linux-aarch64; firmware staging integration. |
configs/airootfs/root/.automated_script.sh |
Warm offline mirror for both .pkg.tar.zst and .pkg.tar.xz. |
configs/aarch64/zz-aarch64-live.conf |
Ensure live initramfs HOOKS include archiso; drop thunderbolt module for aarch64. |
configs/aarch64/live-uki.sh |
Build a live UKI embedding DTBs + SMBIOS hwids for Windows-on-ARM. |
configs/aarch64/linux.preset |
No-op preset to avoid mkinitcpio failures on missing /boot/vmlinuz-linux. |
configs/aarch64/customize_airootfs.sh |
Reconcile ALARM kernel naming, build live initramfs, and build UKI. |
builder/patches/archiso-grubmodules.patch |
Patch archiso to filter unavailable GRUB modules on arm64-efi. |
builder/patches/archiso-copy-boot-efi.patch |
Patch archiso to copy /boot/*.efi into the ISO (needed for the UKI). |
builder/build-omarchy-packages.sh |
Include .pkg.tar.xz artifacts when building/copying packages. |
builder/build-iso.sh |
Host-arch selection; ALARM keyring handling; pacman.conf filtering; aarch64 package filtering/substitution; Node arch selection. |
bin/omarchy-iso-make |
Add --local-repo; choose Arch vs ALARM container image by host arch. |
.github/workflows/aarch64-build.yml |
New native ARM CI workflow building pkgs then ISO on arm64 runner. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Package dependencies are now split and upstream-visible: omacom/omarchy-pkgs#223 provides the reusable native ARM repository artifact, omacom/omarchy-pkgs#222 provides the Quattro Limine aarch64 build, and omacom/omarchy-pkgs#221 provides safe Qualcomm firmware extraction. This branch now points at the eventual upstream master workflow and declares its own exact ISO package set; the fork-specific integration wiring remains only on the test branch. |
|
Confirming provenance. The Snapdragon commits are mine and match |
|
The corrected native ARM validation is green: https://github.com/birkskyum/omarchy-iso/actions/runs/33128799299 The run built the aarch64 package repository, retained and verified |
|
Tested on an HP EliteBook Ultra G1q (Snapdragon X1E-78-100), linux-aarch64 7.2-2, from the ISO built on your Works: boots via Limine into the UKI with the G1q device tree selected; display at native resolution with GPU acceleration; Wi-Fi (WCN7850, ath12k); keyboard, touchpad, touchscreen; battery reporting; Arch Linux ARM package sources configured and Not yet: audio (no card registers; that's the topology/UCM follow-up I mentioned) and the function-row media keys. I haven't run the encrypted path on this machine yet. So that's two machines for the stack, both X1E. |
|
Tested successfully on an ASUS Vivobook S15 S5507QA-MA052W (Snapdragon X Elite X1E-78-100, DTB Encrypted full-disk install to internal NVMe:
Works: OLED (after GPU zap), Wi-Fi Gotchas that might help this PR:
Not working yet: speakers/mics (ADSP never started; also needs kernel Happy to pull more logs if useful. |
builder/build-iso.sh hardcodes x86_64 in the places that pick a kernel, a Node
tarball and a package list, and assumes the archiso package is installable.
Derive all of them instead, so the same script builds for either architecture.
Architecture selection:
- one case statement sets ISO_ARCH / ISO_NODE_ARCH / ISO_KERNEL from uname -m;
everything downstream uses those rather than a literal
- packages.$ISO_ARCH for the live environment's own package list
- the Node tarball follows ISO_NODE_ARCH, since Node names its builds
linux-x64 / linux-arm64 rather than by uname
- phases_impl.py, which consumes that tarball during the install, derives the
same suffix from platform.machine(). Both ends have to agree or the
installer aborts with "no bundled Node tarball in /opt/packages" after the
build has already bundled the right file.
- on x86_64 every one of these resolves to exactly the previous value:
linux-t2, packages.x86_64, linux-x64.tar.gz
Host portability, not architecture-specific:
- prefer the archiso package, and fall back to the vendored submodule when the
repository has no archiso (Arch Linux ARM does not). Installing from source
skips the package's dependency closure, so squashfs-tools, dosfstools,
mtools, libisoburn, erofs-utils, arch-install-scripts and e2fsprogs are
requested explicitly on that path. Use install-scripts and install-profiles
rather than the default install target, which runs rst2man for man pages
this build does not use.
- match both .pkg.tar.zst and .pkg.tar.xz when indexing the offline mirror.
Arch ships zstd, Arch Linux ARM still ships xz, and matching only zstd makes
repo-add index almost nothing. It fails silently: repo-add succeeds, the db
exists, pacman -Sy succeeds, and only the resolve reports "target not found"
for everything including base. Both extensions are enumerated rather than
globbed so .sig files are not swept in.
aarch64 package selection, gated on uname -m:
- OMARCHY_ARCH_DROP plus a filter, since pacman -Syw aborts the whole
transaction on the first missing target. Applied to every consumed list, not
just the mirror's download set: filtering only that one produces an ISO that
builds cleanly and then fails partway through a real install.
- quickshell-git and mise substituted for their packaged equivalents.
Verified by building an aarch64 ISO end to end on Arch Linux ARM natively.
mkarchiso reads packages.$arch from the profile directory. The build seeds the profile from archiso's releng configs, which ship only packages.x86_64, so an aarch64 build had no live package list of its own and would pacstrap only the handful of names appended by build-iso.sh. Derived from releng's packages.x86_64 with the entries that do not exist for aarch64 removed, each checked against the Arch Linux ARM repositories rather than by inspection.
customize_airootfs.sh removed the existing initramfs and then downgraded both mkinitcpio failing and the image being absent to log messages, so an aarch64 ISO could build cleanly and be unbootable -- the GRUB entries load initramfs-linux-aarch64.img by name. mkinitcpio's exit status cannot be used directly here: it exits non-zero on this platform even when it produces a complete image, because archiso's memdisk hook wants the phram module and the memdiskfind binary and neither exists for aarch64 (memdiskfind ships in syslinux, which is x86-only). So the check is on the artefact instead -- a missing or empty image now exits 1, which mkarchiso propagates since it runs under set -e. The same applies to the kernel image the preset points at: if neither /boot/Image nor /boot/vmlinuz-linux-aarch64 exists, say so rather than letting mkinitcpio fail confusingly further down.
The script read as though it hand-rolls initramfs generation for aarch64. It
does not, and should not: on Arch that is automatic, because the kernel package
installs usr/lib/modules/<ver>/{vmlinuz,pkgbase}, 90-mkinitcpio-install.hook
triggers on the former and the alpm script reads the latter for the kernel name.
Arch Linux ARM installs neither, which is proposed upstream as
archlinuxarm/PKGBUILDs#2215.
With that applied the hook does fire, verified by staging both files into a
pacstrapped root and installing them: the initramfs is generated automatically.
Two naming gaps remain, and closing those is this script's actual job:
- ALARM's preset writes /boot/initramfs-linux.img while the GRUB entries load
initramfs-linux-aarch64.img
- nothing creates /boot/vmlinuz-*, which is the glob mkarchiso copies the
kernel from
Also records why the deprecated customize_airootfs.sh hook is used at all: the
work has to happen inside the chroot after packages install, since the kernel
image does not exist before that, and shipping the preset through airootfs/ does
not work because the overlay is copied before pacstrap and linux-aarch64's own
preset overwrites it.
Comments only; no behaviour change.
archiso hardcodes a GRUB module list taken from an x86 bug report. at_keyboard is PS/2, and keylayouts, usb and the four usbserial_* drivers are x86-oriented, so none of them are built for arm64-efi and grub-mkstandalone aborts on the first one it cannot find. Without this an aarch64 ISO cannot be built at all. The fix belongs in archiso rather than here, so it is carried as a patch against the vendored copy and applied where the submodule is staged for installation. It uses --forward, so it becomes a no-op once the submodule is bumped past a release containing the change. A check after installation confirms the mkarchiso actually in use can build for this platform, whether it came from the submodule or from a distro package. Failing there with an explanation is better than failing several minutes later inside grub-mkstandalone. The seven modules were confirmed absent by installing grub in an aarch64 container and testing each path under /usr/lib/grub/arm64-efi/.
build-iso.sh checks the installed mkarchiso for _filter_grubmodules before building, but the patch inlined its filtering and never defined that name, so an aarch64 build failed at the guard every time. Move the filtering into a _filter_grubmodules helper that build-iso.sh can find. Its diagnostic goes to stderr, since stdout carries the module list.
The configurator hands archinstall three custom mirror servers, which it prepends to the target's /etc/pacman.d/mirrorlist. All three are Arch x86_64 mirrors laid out as $repo/os/$arch. Arch Linux ARM lays its tree out as $arch/$repo on different hosts, so on aarch64 every one of them 404s ahead of the mirror the distribution's own pacman-mirrorlist package installed, and each pacman -Sy walks through a dozen failures before reaching it. Pass an empty list on aarch64 so archinstall leaves the mirrorlist alone. The x86_64 rendering is byte-identical to before.
repo-add was handed both *.pkg.tar.zst and *.pkg.tar.xz as inline globs. A mirror holding only one format, which is every x86_64 build, leaves the other pattern unmatched; bash passes it to repo-add literally, repo-add reports the file as not found, and set -e aborts the build. Collect the existing files first, as build-omarchy-packages.sh already does, and fail with a clear message if there are none.
…chy] repo bin/omarchy-iso-make ran archlinux/archlinux:latest, whose manifest is amd64-only; on an aarch64 host use menci/archlinuxarm:base-devel instead. x86_64 keeps the same image as before. Add --local-repo <dir>: mounts a built [omarchy] repository at /omarchy-repo and build-iso.sh rewrites the repo's Server line to file:///omarchy-repo. pkgs.omarchy.org serves no aarch64 tree, so this is how the aarch64 ISO gets omarchy's own packages (built by omarchy-pkgs bin/repo build --arch aarch64). Carry builder/patches/archiso-grub-modules-arm64.patch: archiso v87 hardcodes seven GRUB modules that have no arm64-efi build, so grub-mkstandalone aborts. build-iso.sh applies builder/patches/archiso-*.patch to the vendored submodule copy on aarch64 only; the patch header names its retirement condition. Populate the archlinuxarm keyring after pacman-key --init when the container ships it, so ALARM's signed databases verify.
Twin of nightly-build.yml: builds the aarch64 [omarchy] repo through omarchy-pkgs' reusable workflow, then the ISO on ubuntu-24.04-arm with --local-repo, and uploads the ISO as an artifact. The x86_64 workflow is untouched.
Windows-on-ARM laptops boot with ACPI tables Linux cannot drive the SoC from, and their firmware hands over no device tree. Wrap the live kernel and initramfs into a systemd-stub UKI that carries every Windows-on-ARM device tree linux-aarch64 ships as .dtbauto sections plus systemd's SMBIOS-ID database as .hwids; the stub picks the board's tree at boot. No board is named anywhere (JimmayVV#12). - configs/aarch64/live-uki.sh builds it at the end of customize_airootfs.sh, the only point where the kernel exists and /boot is not yet emptied. - builder/patches/archiso-copy-boot-efi.patch copies /boot/*.efi into the ISO next to the kernel; mkarchiso only knows vmlinuz-* and initramfs-*. - configs/grub/grub.cfg gains an arm64-only default entry that chainloads it with the archiso arguments as EFI load options (GRUB's `linux` rejects a stub-wrapped image on arm64); the plain entry stays as the fallback. The x86_64 menu is unchanged. - systemd-ukify joins configs/packages.aarch64.
|
@HurlyDesousa, thanks again for the detailed ASUS results. If you have time, would you be willing to try a live boot of this native ARM ISO build on the Vivobook? No reinstall needed. The question is whether the same image also loses USB detection or battery/charger readings on the ASUS. On the Yoga, those failed in the live session even though the installed system's battery indicator works. This is a separate test from audio and encrypted unlock, not a proposed fix for either. 1. Download and boot safelyDownload sha256sum omarchy-2026.09.06-aarch64-local.isoExpected SHA256: Write it with your usual image-writing tool to a spare USB drive whose contents you can erase, checking the target carefully. Boot the normal live entry without changing its kernel parameters or DSP/audio settings. Stop at “Press Return to Start Install”. Do not start installation or unlock/mount the internal partitions. Keep the charger and boot USB plugged in throughout. Switch to a console with Ctrl+Alt+F2 (add Fn if needed), and log in as 2. Collect two USB/power snapshotsThe block below reads diagnostics and writes reports only to the temporary live session. It takes one snapshot now and another two minutes later. The kernel log also covers anything that disappeared before you reached the console. Copy-paste diagnostic commandsbash <<'EOF'
if [ ! -d /run/archiso ]; then
echo "Please run this from the live USB, not the installed system."
exit 1
fi
out=$(mktemp -d /tmp/omarchy-live.XXXXXX) || exit 1
{
uname -r
cat /usr/share/omarchy-iso/build-info
cat /proc/cmdline
tr '\0' '\n' < /proc/device-tree/model
} > "$out/build.txt" 2>&1
snapshot() {
date -Is
cat /proc/uptime
timeout 10 lsusb
timeout 10 lsblk -o NAME,TRAN,TYPE,SIZE,MOUNTPOINTS
echo "Power-supply devices:"
ls /sys/class/power_supply
for f in /sys/class/power_supply/*/{online,status,capacity}; do
[ -e "$f" ] || continue
printf '%s: ' "$f"
timeout 5 cat "$f"
done
}
snapshot 2>&1 | tee "$out/first.txt"
echo "Waiting two minutes. Please leave the USB and charger connected."
sleep 120
snapshot 2>&1 | tee "$out/second.txt"
journalctl -b -k --no-pager -o short-monotonic > "$out/kernel.txt"
printf '\nReports saved in: %s\n' "$out"
EOFMissing power entries, read errors, or an absent USB stick are useful results too. They do not by themselves prove the laptop has stopped charging. 3. Check Wi-Fi, if possibleFirst run iwctl station wlan0 scan
iwctl station wlan0 get-networks
iwctl station wlan0 connect "YOUR_SSID"
iwctl station wlan0 show
curl --max-time 15 -fsS -o /dev/null -w 'HTTP %{http_code}\n' https://archlinuxarm.org/Please mention whether connecting needed a retry and whether the HTTPS check returned What to sharePlease reply here with whether the welcome screen and keyboard worked, any touchpad behavior you could actually test, and the USB/power/Wi-Fi results. “Not tested” is fine. Save the printed report directory to another machine before rebooting, since it is temporary. If you already have another machine accepting SSH, you can use this, replacing the directory and destination: scp -r /tmp/omarchy-live.XXXXXX user@other-computer:~/Review the files before attaching them and redact network names/addresses, MAC addresses, serial numbers and other personal identifiers. If transferring logs is awkward, photos of the short results are a useful first step. Even a basic boot result would help. |
|
@birkskyum Follow-up on your live-USB ask for ASUS Vivobook S15 S5507QA (X1E-78-100). No reinstall; NVMe install left untouched. Artifact:
Boot result: selecting the USB as boot device → black OLED, no installer welcome screen. Recovered via Limine back to the installed system. Did not reach a live console, so we could not run the USB/power 2‑minute diag or Wi‑Fi checks. ISO EFI layout looked OK on inspection: Hypothesis: same ASUS OLED early-display / blank-prompt class we already hit on LUKS (keyboard works, panel stays black). Yoga reached welcome on this same build; Vivobook did not. Planned retry if Hurly wants: Shift/Esc GRUB edit — drop Happy to report again after that retry (or after an ASUS early-display live drop-in if you have one). Signed-off-by: Grokbot |
|
@birkskyum Follow-up on the Vivobook live-USB black OLED (after #129 (comment)). Hurly reached a Still black OLED. Ctrl+Alt+F2 had no visible effect (no console). Recovering back to the NVMe Limine install. USB/power 2‑minute diag still not run — never got a usable live console. Write integrity of the ISO on the SanDisk was previously verified (SHA-256 matched). So this looks like an early-display / panel bring-up failure on ASUS OLED even when GRUB successfully hands off to Signed-off-by: Grokbot |
|
@HurlyDesousa Thanks for testing this and keeping the NVMe installation untouched. This confirms that the same ISO reaches the welcome screen on the Yoga but leaves the ASUS screen black. I checked the image and noticed a difference in the manual retry: If you’re happy to try once more, these commands are for the exact September 6 ISO you verified. They preserve the normal boot arguments, remove The If any text appears, a photo of the last visible messages would help. If it stays completely black, that result is useful too. No need to keep trying blind commands or proceed with installation. We can then compare the ISO against your working installed system’s kernel, device tree and firmware. For now, the USB, battery and Wi-Fi checks remain untested rather than failed. |
|
@birkskyum Follow-up / correction on the SanDisk live-USB GRUB chainload (Vivobook S15 S5507QA OLED). Earlier note called this a hard black-OLED fail — that was wrong. After a black period, the Omarchy installer did appear. So this is a SUCCESS for display on live USB with the full chainloader (slow/blank bring-up, then installer). Hardware: ASUS Vivobook S15 S5507QA (Snapdragon X Elite), OLED Exact GRUB used: Result: black OLED for a while → then installer UI. NVMe Limine install left intact. Signed-off-by: Grokbot |
|
@HurlyDesousa Thanks for correcting that, and for testing again. That’s useful confirmation that this ISO reaches the installer on the Vivobook too. If you have time, could you run the USB/power snapshots and Wi-Fi checks from the [earlier instructions](#129 (comment)), using this successful boot command? Roughly how long the screen stayed black would also help. No installation needed. We can record this as a successful live installer boot with the diagnostic arguments, while keeping normal-entry boot and the remaining hardware checks separate. |
|
@birkskyum Live USB/power follow-up on ASUS Vivobook S15 S5507QA (Snapdragon X Elite OLED) with Boot / displayAfter a short black OLED period (~6–7 seconds before the Omarchy logo — not minutes), the installer welcome appeared (SUCCESS for live display). Booted via GRUB with your full chainloader (DSP blacklist kept; Wi‑FiAssociated and HTTPS check returned USB / power 2‑minute snapshots (
|
|
@HurlyDesousa Thanks, this helps narrow things down. The installer and Wi-Fi results are encouraging. Your SanDisk stayed detected, so it did not reproduce the Yoga's USB disappearance; the unavailable power readings are the shared finding. I've added the touchpad observation to the PR description as reported, not yet independently verified. If you have time on your next live boot, could you check two remaining points?
Read-only checks, no extra packages requiredRun from the live root console. Do not start the installer, mount/unlock the internal disk, or change the DSP blacklist. The commands only print diagnostics and count input bytes; they do not save raw input or change configuration. Move and click the touchpad during each ten-second sample. bash <<'EOF'
if (( EUID != 0 )); then
echo "Please run this from a root shell (sudo -i on the installed system)."
exit 1
fi
if [[ -d /run/archiso ]]; then
echo "Session: live USB"
else
echo "Session: installed system"
fi
uname -r
cat /proc/cmdline
cat /proc/bus/input/devices
found=0
for sys in /sys/class/input/event*; do
[[ -r "$sys/device/name" ]] || continue
name=$(cat "$sys/device/name") || continue
case "${name,,}" in *093a:3016*) ;; *) continue ;; esac
found=1
dev="/dev/input/${sys##*/}"
printf '\n%s: %s\nMove and click the touchpad for 10 seconds. Byte count:\n' "$dev" "$name"
timeout -k 2 10 cat "$dev" | wc -c
printf 'Reader exit: %s (124 means the timed sample ended normally)\n' "${PIPESTATUS[0]}"
done
if (( found == 0 )); then
echo "No 093A:3016 event device found; please share the input-device list above."
fi
journalctl -b -k --no-pager -o short-monotonic |
grep -Ei 'i2c.hid|hid.over.i2c|093a|touchpad'
EOFA reader exit of If convenient, repeat the same block after returning to your installed system, using Please reply here with the outputs, labelled live/installed, after reviewing and redacting any serials or personal identifiers. Copy the live output before rebooting. Partial results are useful too; no reinstall or extra testing of audio/camera is needed for this follow-up. |
|
@birkskyum Follow-up on cmdline + touchpad — ASUS Vivobook S15 S5507QA (X1E-78-100). INSTALLED (Omarchy NVMe) — 2026-09-07Session: installed system
|
|
@birkskyum LIVE USB follow-up for cmdline + touchpad — pairs with the installed results. LIVE USB (OMARCHYLIVE) — 2026-09-08 ~00:31 Europe/BerlinSession: live USB / archiso Exact
|
|
@HurlyDesousa Thanks for checking both environments. This confirms touchpad events on live USB too. With the correct OMARCHYLIVE stick, does selecting USB in the firmware boot menu show the normal Omarchy boot menu, or drop directly to |
|
@birkskyum Re: firmware USB boot path with the correct OMARCHYLIVE stick (Vivobook S15 S5507QA). Short answer: selecting USB in the firmware boot menu does not drop us straight to What we observed with OMARCHYLIVE:
Earlier EFI Shell / “no — Grokbot |
|
@HurlyDesousa Thanks, that clears it up. I checked the built image: GRUB has Your reports confirm that the default USB path can reach the live environment on the S5507QA without manual chainloader commands, using the shipped arguments. Together with the touchpad event capture, that resolves the earlier boot-path and touchpad uncertainty for this image. No need to repeat those checks for this follow-up. The unavailable live battery/charger readings remain a separate issue to investigate. Thanks for taking the time to separate the live and installed results. |
|
I’m offline for medical so working remotely over iPhone on this - what I have working Omarchy on Surface Laptop 7 (15", Snapdragon X Elite, 32/1TB) https://gist.github.com/cicorias/6da75542f9e2b4a7b6f58a61ba3979d6 |
|
@cicorias Thanks for sharing this, and no rush on testing. Just to clarify, have you actually booted Omarchy on your Surface, or is the gist a proposed build plan so far? The comment and the guide currently describe different testing states. I checked our September 6 image and it already includes the 15-inch Surface Laptop 7 device tree. The download is also still available until September 13. There is no need to wipe Windows for the first test. Booting the USB with its default settings and checking the installer welcome screen, keyboard and Wi-Fi would be a useful starting point. Please stop before installation. If you have already booted it, the image name, |
Carry the offline keyboard configuration and its tests from Marcelo’s ARM ISO work. These changes do not require a running host systemd instance. Extracted without changes from commit 4897e8b. Source: omacom#149
Adapt the architecture split from omacom#149 and the hardware profiles from omacom#156. Keep the tested Snapdragon UKI as the ARM default and make generic firmware-based media an explicit target. Carry the Spark unlock arguments without duplicating the Yoga runtime setup, kernel-image shim or repository refresh. Use the same manifest for offline packages and target selection, and reject invalid profiles before disk cleanup. Add launcher, profile and boot-generation tests, inspect generated live initramfs hooks, and document the remaining combined-image validation. Sources: omacom#149 (4897e8b), omacom#156 (b333b46), and Jim Martin’s Spark fix 4f70137. Co-authored-by: Marcelo Alcantara <marcelo.alcantara@bp.com> Co-authored-by: Matt Gilg <gilgm12@gmail.com> Co-authored-by: Jim Martin <jimmartin@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Keep the upstream broadcom-wl to broadcom-wl-dkms mapping alongside ARM platform package selection. Exclude both package names on ARM, with regression coverage.
Keep the early USB-protection blacklist. Start the DSP from a live-only service after checking the overlay and its backing files are in RAM. Skip other hardware and storage-backed layouts, and cover the guards with regression tests.
|
Not yet it's a "plan" at best -- I've been OOF traveling on PTO -- not back online till week of September 21. So, I'll report back then. Am excited though.
|
|
Hi, signing up to test on an ASUS Zenbook A16 UX3607OA (Snapdragon X2 Elite Extreme, 48GB, 2880x1800 OLED 120Hz, touchscreen SKU) — fresh retail unit, currently on Windows. Plan: bare-metal boot validation first, then the ARM installer image with defaults (welcome screen, keyboard, Wi-Fi), stopping before installation. Will report back with image name, |
Summary
This work aims to make Omarchy a practical option on Snapdragon X Elite laptops people already own. TUXEDO paused its X Elite laptop project after 18 months of development, illustrating the remaining Linux support challenges. Meanwhile, Qualcomm is demonstrating Linux on newer X2 hardware. This PR builds on the wider upstream effort, with testing currently focused on first-generation X Elite machines, so owners can choose Linux without replacing capable, recent hardware.
Consolidation and attribution
Carries Sean's aarch64 ISO work from #121 and Jimmy Van Veen's Snapdragon work from
JimmayVV/omarchy-iso@snapdragon, preserving original authorship. The #121 code is already in this branch; if that PR lands first, reconcile the shared history before merging this consolidation.Marcelo Alcantara's #149, reviewed at
4897e8b, supplied the architecture/media-target separation and isolated build-cache approach. His offline keyboard implementation and tests are carried unchanged in a commit retaining his authorship.Matt Gilg's #156, reviewed at
b333b46, supplied the hardware-profile model, identities, package requirements and generated-initramfs inspection approach. The manifest supplies both offline package coverage and model-matched installation settings, without duplicating the Yoga runtime setup. Jim Martin's4f70137supplied the Spark graphical disk-unlock settings. Adapted work carries co-author trailers, including the original AI co-author credit from Matt's source commit.Dependencies
masterso this PR's reference resolves. Fork integration builds used explicit test references instead. These workflows do not themselves enable scheduled production ARM publishing.This ISO consumes those changes; it does not block their merge. They can be reviewed in parallel, then a final integrated image needs validation with the landed versions before release. The separate systemd shutdown fix and camera stack are not prerequisites for this PR and are not supplied by it.
Firmware fallback
Windows extraction is not required to boot every X1 laptop. The wizard automatically attempts it only for missing device-tree-named firmware, before partitioning; it is not a separate checkbox. Staged files are kept in RAM and copied into the installed system. This staging is not a durable backup if installation is interrupted.
The current implementation still depends on omacom/omarchy-pkgs#221 for firmware inspection and GPU initramfs handling, even on machines needing no extraction. It does not download OEM firmware or supply missing Linux drivers, and ACPI-only/X2 extraction is not validated. The missing Yoga CDSP companion and the request for vendor-backed distribution are tracked in that package PR.
Current validation
The September 10 consolidated Snapdragon image was built from
4d47dd6943b342e057aeb5534790ba127b1708dd, with kernel7.2.4-1-aarch64-ARCH. Runtime and package prerequisites were combined in isolated checkouts, not already-merged upstream branches.The initial USB link was already SuperSpeed before DSP startup. It disconnected during early boot and returned after ADSP started, so the test demonstrates safe recovery, not prevention of every early reset. CDSP remained offline because
qcom/x1e80100/LENOVO/83ED/cdsp_dtbs.elfwas missing; the ADSP result does not establish camera, compute-DSP or audio support. Other boards and repeated boot cycles have not been validated with this automatic sequence.A fresh install onto an explicitly disposable drive, followed by an update and reboot, remains required for the consolidated path. Matt's and Jim's fresh-install reports apply to their source branch, not automatically to this consolidation. Generic ARM media still needs physical validation. A final image also needs testing with the landed and published prerequisites. The existing Yoga installation containing valuable files was not used as an installation target.
Prior test reports
These reports identify the source revisions and setups they tested. They are not validation of the latest consolidated image.
Previous image tests and installed-system results
5c3bce42d65b4443e619568dadd7a0b263107d8d, passed ISO construction and inspection. The initial ASUS report here used that ISO. Yoga and HP EliteBook Ultra G1q reports also document their tested configurations; they are not validation of every subsequent change.The installed Yoga hardware report confirms Limine without the hash warning, graphical Omarchy disk unlock, polished shutdown/reboot, Wi-Fi, Bluetooth, speakers and microphone. The shutdown result used a separate systemd v261.2 backport of systemd/systemd#43671, not a change included in this ISO PR. The hardware report also covers the fast, denoised camera preview and subsequent Chromium live-video test on an experimental setup. Camera enablement is a follow-up, not functionality supplied by this ISO PR.
A September 6 integration build and physical Yoga live-USB test now pass ISO construction, image verification, installer startup, built-in input and Wi-Fi connectivity. The linked report pins all three source repositories. Its functional ISO build corrections are now included in
dc166d7, without the fork-specific integration wiring; repository verification is handled in omacom/omarchy-pkgs#223. That September 6 live image had unresolved USB disconnection/hotplug and power-telemetry problems, distinct from the working installed SSD system. The September 10 Yoga test above validates the guarded late-DSP fix for those live-session failures; it does not extend that result to other models. No fresh installation was performed; the existing internal installation was preserved. Early unlock display remains board-specific; missing signed firmware may still prevent display or other hardware from working.The September 7 ASUS Vivobook S15 S5507QA report used the same pinned September 6 image, with kernel
7.2.3-2-aarch64-ARCH. The installer welcome screen and Wi-Fi/HTTPS worked. Its SanDisk stayed enumerated across snapshots two minutes apart, so it did not reproduce the Yoga's USB disappearance. Power-supply reads returnedEAGAINin both snapshots, confirming unavailable live-session telemetry on a second board, not a charging failure.The default-boot clarification confirms that selecting the correct USB in the firmware boot menu can reach the live environment without manually entered GRUB commands. The image intentionally hides its menu with
timeout=0; the GRUB prompt was entered deliberately for diagnostics. The live-session capture confirms the shipped arguments, includingquiet splashandmodprobe.blacklist=qcom_q6v5_pas, and nonzero input events from the093A:3016touchpad. This supersedes the earlier zero-byte observation. No pointer is expected in the console installer.Separately, the installed-system report confirms Omarchy running from the ASUS's internal NVMe with kernel
7.2.0-12-aarch64-vivobook-ARCH, working desktop touchpad movement and gestures, and nonzero touchpad input events. These are tester-reported results with distinct live and installed kernels, not a fresh-install validation of this image. Encrypted unlock, audio and camera were not tested in the live-image follow-up; live battery/charger telemetry remains unresolved.