Skip to content

feat: add raspi-arch branch for Arch Linux ARM on Raspberry Pi - #7

Draft
LJLee37 wants to merge 1 commit into
raspifrom
claude/settingfiles-restructure-raspi-arch-uk2buw-raspi-arch
Draft

feat: add raspi-arch branch for Arch Linux ARM on Raspberry Pi#7
LJLee37 wants to merge 1 commit into
raspifrom
claude/settingfiles-restructure-raspi-arch-uk2buw-raspi-arch

Conversation

@LJLee37

@LJLee37 LJLee37 commented Aug 1, 2026

Copy link
Copy Markdown
Owner

⚠️ Review-only — do not merge

This is not meant to be merged into raspi. The new raspi-arch branch
has already been pushed directly to raspi-arch (same content as this PR's
head, claude/settingfiles-restructure-raspi-arch-uk2buw-raspi-arch) — there
was no existing raspi-arch branch to open a normal "into" PR against, so
this PR exists purely to give you a reviewable diff. raspi is used as the
base only because it's the closest sibling in scope (both are headless/CLI),
which keeps the diff to just the files that actually differ. Once you're
happy with it, just close this PR without merging; raspi-arch already
stands on its own as a branch.

Summary

Companion to the cleanup PRs on master/arch/macOS/ubuntu/alpine/raspi. Adds the new raspi-arch branch: a headless Arch Linux ARM (ALARM) install for Raspberry Pi, scoped like raspi (CLI-only — no GNOME/Steam like the x86_64 arch branch has).

ALARM's install procedure is fundamentally different from x86 Arch's pacstrap+GRUB flow, so arch's scripts couldn't be reused as-is:

  • install-sdcard.sh (replaces install1.sh) — run on a separate Linux host with the SD card/USB drive attached (the Pi has no OS yet at this point). Partitions/formats the media and extracts a prebuilt ALARM rootfs tarball with bsdtar (extended attributes/ACLs can be dropped by plain tar).
  • install-firstboot.sh (replaces install2.sh) — run on the Pi after first boot. Adds the ALARM-specific pacman-key --init/--populate archlinuxarm step; drops GRUB/grub-mkconfig entirely (the Pi boots via firmware + config.txt, not GRUB); drops mkinitcpio/initramfs (not needed for a stock boot) and intel-ucode (x86-only). Takes a Pi-model argument to swap in the linux-rpi-16k kernel that a Pi 5 currently needs in place of the generic aarch64 kernel the tarball ships with.
  • backup.sh adapted from raspi's: ALARM mounts the boot partition at /boot, not /boot/firmware.
  • set.sh: same ~/gitRepos/settingfiles path fix as the other branches.
  • .vimrc/.zshrc/init.vim reused verbatim from raspi — unchanged, since shell/editor config is architecture-independent.
  • raspi's apt-based install.sh was removed (wrong package manager for ALARM) — flagging per the task's instruction to call out deletions before/while doing them.

Written against a Raspberry Pi 4 Model B (64-bit), using the generic ArchLinuxARM-rpi-aarch64-latest.tar.gz image (ALARM's docs list this as also covering the Pi 3 and 400). The Pi 5 has no dedicated ALARM image as of this writing — install-firstboot.sh 5 swaps in the kernel package the community currently recommends there, but this is inherently more fragile than the Pi 3/4 path. I verified the core steps (tarball URL pattern, bsdtar, pacman-key sequence, fstab entries, no-GRUB boot, Pi 5 kernel caveat) against multiple current third-party guides during this session, since archlinuxarm.org itself blocked automated fetches — please re-check https://archlinuxarm.org for your specific model before a real install, as ALARM's supported devices and exact procedure do change over time.

Hardcoded personal values (carried forward from raspi/arch for consistency, left as-is)

  • Default username ljlee, default hostname raspi-arch (both overridable via USERNAME/HOSTNAME_VALUE env vars in install-firstboot.sh — the hostname is a placeholder, not a real personal value, since raspi-arch has no prior hostname to reuse)
  • Locale list incl. ko_KR/ja_JP/eo (ported from arch/install2.sh for consistency)
  • LAN backup destination 192.168.35.203 (ported from raspi/backup.sh)
  • Timezone Asia/Seoul (ported from arch/install1.sh, with the zoneinfo typo already fixed)

Test plan

  • bash -n install-sdcard.sh / bash -n install-firstboot.sh — both pass (checked locally)
  • .vimrc/.zshrc/init.vim are byte-identical to raspi's (checked locally)
  • Actual install against real Pi hardware — not done in this session; please test before relying on this for a real machine

Generated by Claude Code

New branch (forked from raspi's tree) covering a headless Arch Linux
ARM (ALARM) install, scoped like raspi (CLI-only) rather than the
GNOME/Steam-heavy x86_64 arch branch. ALARM's install procedure
differs fundamentally from x86 Arch's pacstrap+GRUB flow:

- install-sdcard.sh replaces install1.sh: run on a separate host to
  partition/format the SD card and extract a prebuilt ALARM rootfs
  tarball with bsdtar (not pacstrap, since the Pi has no OS to
  pacstrap from yet; bsdtar instead of tar to preserve xattrs/ACLs).
- install-firstboot.sh replaces install2.sh: adds the ALARM-specific
  pacman-key --populate archlinuxarm step, drops GRUB/grub-mkconfig
  (the Pi boots via firmware + config.txt, not GRUB), drops
  mkinitcpio/initramfs (unneeded for a stock boot) and intel-ucode
  (x86-only). Accepts a Pi model argument to swap in the linux-rpi-16k
  kernel that Pi 5 currently needs in place of the generic aarch64
  kernel.
- Removed raspi's apt-based install.sh (wrong package manager for
  ALARM) and replaced it with the two scripts above.
- backup.sh adapted from raspi's: ALARM mounts the boot partition at
  /boot rather than /boot/firmware.
- set.sh: same clone-path fix as the other branches
  (~/gitRepos/settingfiles, not .../Personal/settingfiles).
- .vimrc/.zshrc/init.vim reused verbatim from raspi, unchanged --
  these are architecture-independent.

Written against a Raspberry Pi 4 Model B (64-bit); see README and
script comments for Pi 3/5 notes and the caveat that ALARM's exact
procedure should be re-verified at archlinuxarm.org before a new
install.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants