A user reported (and it reproduces on hardware) that turning "ENABLE
NAVIGATION SOUNDS" on in Sound Settings does nothing until the device is
rebooted.
Root cause: Sound::init() loaded the WAV sample only when EnableSounds was
already true:
if (!Settings::getInstance()->getBool("EnableSounds"))
return;
mSampleData = Mix_LoadWAV(...);
So when the frontend starts with sounds disabled, every Sound keeps a null
sample; flipping the menu switch only writes the setting and never reloads
the samples, so play() bails on the null sample. Only the next boot re-runs
init() with the setting true and finally loads them.
Sound::play() already checks the live EnableSounds value, so the init-time
gate is redundant for correctness and harmful for runtime toggling. Drop it
(new patch, first under this package's patches/) so samples always load and
the toggle works immediately, both directions, no reboot. Memory cost is a
handful of small navigation WAVs.
Pending validation: takes effect after the ES package is rebuilt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Found during the live multi-device SSH sweep; none break a single device but
each is a real defect:
- linux-drivers/RTL8188EUS 99-rtl8188eus.rules: the RUN line used single `$`
for its shell vars, which udev parses as its own specifier ("invalid
substitution type") and rejects the whole rule, so the rtl8xxxu->8188eu
rebind never ran (the dongle stayed on the better driver only by probe-order
luck). Double them to `$$`.
- linux 10-bfq-sched.rules: `KERNEL=="mmcblk[0-9]*"` matched partitions too,
whose queue/* knobs do not exist, spamming the boot log with ~15 ENOENT
write failures. Gate on SUBSYSTEM=="block", DEVTYPE=="disk".
- hostname: system.cfg shipped `system.hostname=@DEVICENAME@` -> "RK3326" (the
SoC name, identical on every unit), so two ArchR consoles on one LAN collide
on NetBIOS/mDNS registration (nmbd "Failed to register my name"). Set the
base name to "archr" and append a short per-device machine-id suffix in
network-base-setup so each device is unique.
- tsadc: r3xs.dtsi and eeclone.dts enabled tsadc without
rockchip,hw-tshut-mode/-polarity, so the driver logged "Missing tshut ...
using default" on every boot. Spell out the defaults (CRU reset, active-low);
behaviour unchanged. DTS compiles clean (eeclone + soysauce).
The "GO-Super Gamepad" joypad name on the Soysauce was investigated and is
intentional (soysauce.dts sets joypad-name with a matching retroarch config),
so it is left as-is.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The image rootfs is a squashfs, not a pacman install, so /var/lib/pacman
(-> /storage/.pacman/db) ships empty: on every device `pacman -Q` returns 0
and `pacman -Qu` finds nothing, so archr-update / `pacman -Syu` reports "No
updates available" even when the repo carries newer base packages. The
headline 2.0 update path therefore only ever installed user addons, never
upgraded the base system (confirmed live: local/ holds only ALPM_DB_VERSION).
Fix in two self-contained parts (no image-build wiring, so the seed always
matches the build that produced it):
- gen-pacman-repo: after building the sync db, register every just-built
package as installed (`pacman -U --dbonly`, files already in the squashfs)
and publish the resulting local/ tree as <repo>-localdb.tar.gz alongside
the packages.
- autostart/004-seed-pacmandb: on first boot, if the local db is still empty
(only ALPM_DB_VERSION) and the network is up, pull <repo>-localdb.tar.gz
from the configured release channel and extract it into
/storage/.pacman/db. Idempotent and skipped once the db is populated, so a
user's own pacman activity is never clobbered.
PENDING VALIDATION: needs a full build + repo publish to confirm the seed is
produced and that `pacman -Syu` then sees base upgrades. Best-effort on the
generator side (logs a warning rather than failing the repo build).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The R36S Clone's standalone DTB diverged from the shared r3xs.dtsi the
Original/Soysauce use, producing two real boot-time errors (confirmed by a
dmesg diff against the Original, which boots clean):
- &emmc was status=okay + non-removable, but the Clone board has no eMMC
chip. The controller retried an absent card forever ("Timeout sending
command", "Failed to initialize a non-removable card"), wasting boot time.
Disable it; the OS boots from &sdmmc.
- &uart5 (console, ttyS2) inherited the px30 default pinctrl with uart5_cts
on gpio3 RK_PA3, already claimed on this board, so the kernel reverted the
whole pin group ("Error applying setting, reverse things back") and could
leave even TX/RX unapplied. Mux xfer-only (a console needs no hardware flow
control), matching how the Original wires uart2.
DTS compiles clean (cpp + dtc).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The quirks loader matches /usr/lib/autostart/quirks/devices/<dir> against the
exact /proc/device-tree/model string. The Clone (model "R36S Clone") and the
Soysauce (model "Game Console R36S Soysauce") had no matching folder, so no
device_config was sourced and DEVICE_TEMP_SENSOR stayed unset: System
Information showed no CPU/GPU temperature, while the Original
("Game Console R36S") did. The DTBs and tsadc are identical and fine on all
three (thermal_zone0/1 read live), so this was purely a missing per-device
quirk, not a devicetree gap.
Add minimal device_config folders wiring thermal_zone0 (CPU) and
thermal_zone1 (GPU). Audio/LED are left on the working defaults. The orphaned
"Generic EE clone" folder (no DTS uses that model) is left as-is rather than
renamed onto "R36S Clone", since its dormant 002-generate_dtbo quirk would
re-introduce in-image DTBO generation that was intentionally moved to the
website generator.
Validated on a live Soysauce: archr-info now reports CPU/GPU temperature.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Verifying the last PortMaster_CFW.md nice-to-have: build-tested the
maintained ltrace fork (gitlab.com/cespedes/ltrace HEAD) on the ArchR
aarch64 toolchain. It fails at autoreconf (configure.ac points at a
config/m4 macro dir that isn't in the checkout, aclocal aborts),
re-confirming the pre-existing exclusion rationale. ltrace stays out;
gdb and perf trace cover symbol-level tracing. This is the only guide
nice-to-have intentionally absent.
Verification of the running R36S against docs/PortMaster_CFW.md flagged
a few required/recommended/nice-to-have items missing. Closes four:
sudo (REQUIRED, section 2): ArchR runs everything as root so PortMaster
sets ESUDO="" and "$ESUDO" ports work, but the guide lists sudo/doas as
required and the live port log printed "No sudo present." Ships a
/usr/bin/sudo shim (archr package, ROCKNIX/dArkOS pattern) that strips
sudo's own options and execs the command as the already-root user.
libjpeg.so.62 (commonly expected, section 4): the base libjpeg-turbo is
built WITH_JPEG8=ON (SONAME libjpeg.so.8); ports compiled against
standard libjpeg-turbo expect libjpeg.so.62. New compat-libjpeg62
package builds the same 3.0.1 source WITH_JPEG8=OFF into /usr/lib/compat
and is pulled in via portmaster-compat-libs; archr-compat-symlinks then
exposes it in the default path.
vmstat (nice-to-have, section 10): procps-ng shipped only free/top/ps;
add src/vmstat to the build + install so memory-pressure monitoring is
available.
perf_event_paranoid (nice-to-have, section 10): ship
sysctl.d/90-archr-perf.conf setting kernel.perf_event_paranoid=1 so perf
can sample userspace CPU events (default 2 blocks non-root profiling).
(ltrace, the remaining nice-to-have, is being build-tested separately;
virtual/debug already documents why upstream 0.7.3 was excluded.)
PortMaster runtimes failed to launch: love_11.5's love.aarch64 died with
"error while loading shared libraries: libtheoradec.so.1: cannot open
shared object file" (caught live over SSH while a port was launched).
Root cause: ArchR keeps the ~50 PortMaster compat libraries (older
Debian-11-era SONAMEs: libtheoradec.so.1, libavcodec.so.58,
libwebp.so.6, libx264.so.160, etc.) under /usr/lib/compat to stay out of
the base system, and the image ships NO ld.so.cache. glibc's dynamic
linker therefore only searches the hardcoded /usr/lib + /lib plus
LD_LIBRARY_PATH, so /usr/lib/compat is invisible to anything that does
not explicitly prepend it. control.txt does set
LD_LIBRARY_PATH=/usr/lib/compat, but the per-runtime invocation
overwrites it, dropping compat for binaries like love.aarch64.
docs/PortMaster_CFW.md is explicit on the fix: "add these older .so
symlinks alongside [the newer versions]" and "Keep [libtheoradec] at
standard versions." So we expose the compat SONAMEs in the default path.
New archr-compat-symlinks script + archr-compat-libs.service oneshot
(ordered Before=archr-autostart so it runs before any port launches):
walks /usr/lib/compat (and /usr/lib32/compat) and symlinks each SONAME
into /usr/lib, but ONLY when the base system does not already provide
that exact name, so real libraries (libogg.so.0, libvorbis.so.0, ...)
are never shadowed. Idempotent via the `[ -e ]` guard; the writable
ext4 rootfs keeps the links so later boots are no-ops.
Verified live on the R36S: 46 compat-only SONAMEs linked into /usr/lib,
libtheoradec.so.1 now resolvable, libogg.so.0 left untouched (still the
real /usr/lib/libogg.so.0.8.6).
Root cause of the persistent "Unable to find LABEL=ARCHR, powering
off" after the issue #34 boot.ini LABEL= migration: busybox's built-in
volume_id CANNOT read FAT32 labels. Proven under qemu-aarch64 against
the real image partitions:
util-linux blkid FAT32 -> LABEL="ARCHR" ext4 -> "ARCHR_ROOT"
busybox blkid FAT32 -> TYPE="vfat" only ext4 -> "ARCHR_ROOT"
So `busybox mount LABEL=` and `busybox findfs LABEL=` both fail for the
FAT /flash partition (mounted first), while the ext4 root would have
resolved. The previous fallback used util-linux blkid but only scanned
a hardcoded /dev/mmcblk0p[1-3] /dev/mmcblk1p[1-3] list, so it broke
whenever the boot SD enumerated outside mmcblk0/1 or the partition
nodes weren't created yet.
mount_common's LABEL=/UUID= branch now:
- resolves exclusively through util-linux /usr/sbin/blkid (reads both
FAT32 and ext4 labels),
- walks every entry in /proc/partitions instead of a fixed device
list, so it is independent of the mmcblkN enumeration order
(exactly what issue #34's 2-SD reordering needs),
- mknod's the /dev node from the /proc/partitions major:minor when
mdev hasn't created it yet, removing the dependency on mdev timing
and on udev (absent in the initramfs),
- keeps busybox findfs (works for ext*) and /dev/disk/by-label as
last-resort fallbacks.
Verified: syntax (sh -n) clean, the parse+blkid logic resolves
mmcblk1p1 in a simulated /proc/partitions run, and the rebuilt image's
embedded initramfs carries the new resolver.
The "Unable to find LABEL=ARCHR, powering off" wall on the freshly
flashed image traced back to a latent bug in the initramfs busybox
packaging that the boot.ini LABEL= migration (issue #34) made
deterministic.
busybox/package.mk
The mount, umount and findfs applets are compiled into the init
busybox (CONFIG_MOUNT/UMOUNT/FINDFS in config/busybox-init.conf),
but no symlinks were ever installed for them. mount_common() in the
init script calls `mount LABEL=... /flash` and
`findfs LABEL=...` by bare name; without symlinks the shell can't
find either command and the 15 retry loops silently exhaust to the
power-off message. This bug also affected the previous
/dev/mmcblk${devnum}p1 path: the string was never reaching the
syscall through busybox.
Adds:
ln -sf /usr/bin/busybox ${INSTALL}/usr/bin/mount
ln -sf /usr/bin/busybox ${INSTALL}/usr/bin/umount
ln -sf /usr/bin/busybox ${INSTALL}/usr/sbin/findfs
/usr/sbin/blkid is already shipped by util-linux as a real binary,
no symlink needed for it.
busybox/scripts/init
Exports PATH=/usr/sbin:/usr/bin:/sbin:/bin at the top so the bare
blkid/findfs/mount calls in mount_common() resolve against
/usr/sbin/blkid (util-linux real binary) and the new busybox
symlinks. Without this, the busybox sh default PATH on aarch64
built images is too narrow to find /usr/sbin tools.
RTL8188EUS/package.mk
PKG_VERSION bumped from ec90af2b... (no longer on the remote) to
af3bf004458f76b7aec33e9ba552cd382ed1f5c3, the current HEAD of the
default v5.3.9 branch on aircrack-ng/rtl8188eus. The previous SHA
failed at `get` time: `fatal: remote error: upload-pack: not our
ref ec90af2b...`, blocking the whole image build.
Strategic continuation of the flasher refactor: the SO no longer
generates or ships pre-built panel DTBOs. Users generate their own
mipi-panel.dtbo at https://arch-r.io/overlay-generator/ and drop it
into /flash/overlays/.
- config/overlays/README.txt rewritten with the same instruction in
6 languages (pt-BR, en, fr, es, zh, ru), one per line.
- u-boot/package.mk: removed the mipi-generator invocation and the
per-SUBDEVICE overlays_{original,clone,soysauce} install blocks.
Only the generic overlays/ dir (README) is shipped under
/usr/share/bootloader/.
- bootloader/mkimage: removed the RK3326-specific overlays_${SUBDEVICE}
and overlays_soysauce branches; the generic overlays/ copy at the
end of mkimage_dtb now covers RK3326 too.
- Deleted config/mipi-generator/ (generator.sh + archr-dtbo.py) and
config/archr-dts/ (vendor DTBs that were only consumed by the
generator).
Net: -8503 LOC + ~120 binary DTBs removed from the tree.
Issue archr-linux/Arch-R#19: dongles USB com chipset RTL8188EUS (TP-
Link TL-WN722N v3, Edimax EW-7811Un, vários no-name) escaneiam SSIDs
mas falham na autenticação WPA2 — handshake 4-way não completa, ESS
fica em "Connecting..." até timeout.
Histórico: tentamos antes o ajuste de IWD (UseDefaultInterface,
AddressRandomization), bump IWD 3.9 → 3.10, e o patch upstream
rtl8xxxu de firmware upload block size 128 → 196 (`projects/ArchR/
packages/linux/patches/6.12-LTS/0050-wifi-rtl8xxxu-Fix-RTL8188EU-
firmware-upload-block-size.patch`). Nenhum desses resolveu para os
usuários que reportaram — o rtl8xxxu in-tree continuamente trava no
handshake nesse chip específico.
A solução conhecida em outras distros (Arch, Debian, Manjaro, Kali,
TWRP, Postmarket) é usar o fork `aircrack-ng/rtl8188eus` mantido
especificamente para esse chip. Ele tem o handshake testado com iwd
e wpa_supplicant.
Pacote adicionado:
projects/ArchR/packages/linux-drivers/RTL8188EUS/
├── package.mk (build out-of-tree 8188eu.ko)
├── modprobe.d/
│ └── 00-rtl8188eus.conf (tunables: LED on, no double MAC random)
└── udev.d/
└── 99-rtl8188eus.rules (unbind rtl8xxxu da interface USB
específica nos USB IDs do 8188EUS
e force-load 8188eu)
A udev rule cobre os IDs comuns:
0bda:0179 / 0bda:8179 / 0bda:8189 — Realtek de fábrica
7392:7811 — Edimax EW-7811Un
056e:4008 — Elecom WDC-150SU2M
Não fazemos blacklist global do rtl8xxxu — ele continua sendo o
driver de RTL8192EU, RTL8723BU, RTL8188CU etc. (que funcionam bem
com ele). Só desbinda do device USB específico quando um 8188EUS
aparece e load o 8188eu in its place.
RTL8188EUS adicionado a ADDITIONAL_DRIVERS em projects/ArchR/devices/
RK3326/options para que a build inclua o módulo no rootfs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Issue archr-linux/Arch-R#34: ao inserir um segundo cartão SD em TF2,
o boot falha com "cannot find mmcblk1p1" + countdown para poweroff.
Causa:
- Linux enumera os controladores MMC do RK3326 por ordem do DT:
ff380000.mmc -> mmc0 -> /dev/mmcblk0 (TF2, slot secundário)
ff370000.mmc -> mmc1 -> /dev/mmcblk1 (TF1, slot com o OS)
- U-Boot enumera por ordem de probe dos slots; com TF2 populado o
devnum repassado para a sysboot pode acabar diferente do que o
kernel apresenta como /dev/mmcblk1.
- clone_boot.ini e original_boot.ini montavam o kernel cmdline como
`boot=/dev/mmcblk${devnum}p1 root=...p2 disk=...p3`, então a
troca de devnum quebrava o /init busybox.
Fix:
Substituir o path hardcoded por LABEL=@DISTRO_BOOTLABEL@ (sed do
package.mk já existia mas não tinha onde substituir; agora cobre
ARCHR / ARCHR_ROOT / STORAGE). O /init busybox já trata LABEL= via
findfs + fallback de blkid scan em mmcblk0/mmcblk1, então a partição
certa é encontrada independente da ordem de enumeração — sobrevive
a 2-SD, troca de slot, ou qualquer reorder que U-Boot decida fazer.
Kernel cmdline antes:
boot=/dev/mmcblk1p1 root=/dev/mmcblk1p2 disk=/dev/mmcblk1p3
Depois:
boot=LABEL=ARCHR root=LABEL=ARCHR_ROOT disk=LABEL=STORAGE
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Vários edge cases no fluxo de conexão WiFi com caracteres não-ASCII /
metacaracteres causavam o sintoma reportado "trava ao conectar":
1. iwd codifica caracteres não ([A-Za-z0-9._-]) no nome do .psk como
=XX (man iwd.network "Network file names"). wifictl gravava o
profile como /var/lib/iwd/<SSID literal>.psk — quando o SSID tinha
espaço, ç, +, /, etc. iwd não encontrava o arquivo, o iwctl
station connect caía em prompt interativo aguardando passphrase via
stdin e ficava preso até o autoconnect timeout (30+s). encode_iwd_
name aplica a transformação canônica byte-a-byte (validado com
"Café" -> "Caf=C3=A9", "DIRECT-17-HP Douglas" -> "DIRECT-17-HP=20
Douglas").
2. Senhas fora do intervalo válido (WPA-PSK: 8..63 bytes printable ou
64 hex chars) também faziam iwd rejeitar o profile e cair no
mesmo trava-no-prompt-stdin. wifictl agora rejeita cedo com retorno
2 e mensagem em stderr, dando feedback útil para a UI.
3. Profile órfão de tentativa anterior podia conflitar: ao trocar
entre rede aberta e WPA, ou ao mudar a senha, o iwd preferia o
profile antigo (.open / .psk). Agora wifictl remove os dois antes
de regravar.
4. O check de pós-conexão era frouxo: "state=connected" sozinho
retornava sucesso quando a estação já estava em outra rede,
mesmo que a conexão solicitada falhasse silenciosamente. Adicionado
match contra "Connected network" do iwctl show.
5. O heredoc do create_adhoc usava <<EOF (não-quoted) — um $ literal
na passphrase disparava expansão de variável bash. Substituído por
printf %s para preservar a senha byte-a-byte.
6. /var/lib/iwd/*.psk passa a ser criado com umask 077 — a passphrase
está em texto claro no arquivo e não deveria ser legível por nada
além do iwd (rodando como root).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
A versão anterior do short-circuit gravava sha256(senha) em
/storage/.cache/.archr-rootpass.sha256 — fingerprint recuperável que
quebraria senhas curtas / dicionário por brute force trivial se o
arquivo vazasse. Revisão de segurança automatizada apontou.
Substituída a comparação por reproduzir o próprio sha512crypt já
armazenado em /storage/.cache/shadow: extrai o salt do campo CURRENT
(formato $6$<salt>$<hash>), chama cryptpw -m sha512 -S "$SALT"
"$ROOTPASS" e compara contra CURRENT. Nenhum novo arquivo é escrito;
o único hash de senha em disco continua sendo o sha512crypt salted
que já existia.
Live no R36S:
- mesma senha: 0.147s (short-circuit)
- senha nova: 1.233s (caminho completo)
- nenhum arquivo extra em /storage/.cache/.archr-rootpass*
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
5 ganhos mensuráveis identificados rodando o sistema vivo:
1. /etc/sysctl.d → /storage/.config/sysctl.d, e systemd-sysctl roda
Before=sysinit.target — /storage só monta em local-fs.target. O
symlink ficava dangling quando systemd-sysctl lia, então archr.conf
(BBR/fq_codel, vm.dirty_writeback_centisecs=1500, ip_forward, etc.)
nunca era aplicado no boot. Verificado: rodando sysctl -p manual
depois do boot, dirty_writeback_centisecs vai de 500 → 1500.
Replicar os defaults da distro em /usr/lib/sysctl.d (rootfs, sempre
disponível) garante aplicação antes de /storage subir; o /etc/
sysctl.d permanece como ponto de override do usuário.
2. enable.turbo-mode=1 em system.cfg padrão. A baseline validada do
R36S inclui CPU turbo @ 1512 MHz via cpufreq/boost (vdd_arm
regulator-max=1.45V), mas o default era 0 — clamp em 1416 MHz
sem opt-in. O nó scaling_max_freq sobe para 1512000 assim que
boost=1, comprovado live no device. Quem precisar do clamp
térmico de 1416 desliga via Settings > Advanced.
3. rpcbind.service rodando idle custava ~11 MB de RAM em um device
com 1 GB total, sem nada usando NFS. O upstream já fornece
rpcbind.socket (Listen :111 + /run/rpcbind.sock) e systemd faz
activation on-demand — mount.nfs dispara o daemon quando o user
realmente monta um share. Trocado enable_service rpcbind.service
por rpcbind.socket.
4. archr-touchscreen-keyboard ficava acordando a cada 5s mesmo em
devices sem touchscreen (R36S, R33S, etc), e com Restart=always
um exit do helper provocava restart infinito. Adicionado bail-out
precoce quando DEVICE_HAS_TOUCHSCREEN != true, e Restart trocado
para on-failure para honrar o exit limpo. Em devices sem
touchscreen o serviço passa a ficar inativo após o primeiro boot.
5. setrootpass cryptpw sha512 + smbpasswd + syncthing generate
custavam ~6s a cada boot — chamado pelo autostart 007-rootpw com a
senha já configurada. Adicionado short-circuit que compara o hash
sha256 da senha contra o cache em /storage/.cache/.archr-rootpass.
sha256: se nada mudou, sai em 20ms.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
001-functions:wait_lock(): o trap rm -f "\$lockfile" referenciava
uma variável inexistente. O lock real está em \${J_CONF_LOCK}. Como
\$lockfile expandia para string vazia, rm -f "" virava no-op e
deixava /tmp/.system.cfg.lock órfão se o script morresse por SIGINT/
SIGTERM antes do rm -f explícito no final.
archr-automount.service: Before=autostart.service apontava para o
nome herdado do JELOS, que ArchR não embarca (a unit real é
archr-autostart.service). Sem o prefixo o ordering virava silently
ignored, perdendo a garantia de que /storage/games-* fosse montado
antes dos scripts de autostart consumirem os paths. Também ajustada
a Description que dizia "user autostart script" (copy-paste do
archr-autostart.service).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sweep encontrou 5 categorias de bugs sutis em arquivos herdados:
1. StartLimitInterval/StartLimitBurst em [Service] em 13 unidades
(avahi, bluez, connman, samba/nmbd/smbd, sshd, tz-data, ledfix,
xorg, fluxbox/windowmanager, samba-config). systemd silenciosamente
ignora StartLimit* fora de [Unit], então a proteção contra
restart-flood nunca foi aplicada. Movidas para [Unit] e renomeadas
para o canônico StartLimitIntervalSec (StartLimitInterval é alias
antigo).
2. Refs dangling para kodi.service em 5 units (entware, locale, sway,
xorg, xwayland-xorg, windowmanager-fluxbox). ArchR não embarca
Kodi; o ordering Before=kodi.service ficava como "not-found" no
systemctl list-units. Trocado por Before=archr.target (alvo real
de boot da UI em ArchR).
3. usercache.service e userconfig.service referenciavam
automount.service e autostart.service sem prefixo archr-. Em ArchR
as unidades reais chamam-se archr-automount.service /
archr-autostart.service, então o Before= era ignorado e o setup
corria paralelo aos mounts.
4. archr-autostart.service tinha Before=weston.service. ArchR roda
sway, não weston. Removido (After=graphical.target já cobre).
5. nmbd.service do override ArchR queria samba-config.service que só
existe no pacote global packages/network/samba (não no override).
O daemons/002-samba já cria /run/samba/smb.conf manualmente, então
Wants/After=samba-config.service eram supérfluos.
Bugs adicionais corrigidos no caminho:
- archr/autostart/050-audio: `if [ -n "/usr/sbin/quantum" ]` testa se
uma string literal é não-vazia (sempre true) em vez de checar se o
binário existe. Trocado para [ -x ].
- avahi: post_makeinstall_target removia /usr/sbin/avahi-dnsconfd mas
deixava a unit avahi-dnsconfd.service órfã. Remove a unit junto.
- system-utils: video.service só faz sentido em devices que embarcam
/usr/bin/video_sense (RK3399/RK3566/S922X). Remove a unit em
devices que não têm o helper.
- xwayland: scripts/xorg-configure não era instalado, deixando
xorg-configure@.service com ExecStart para um path inexistente.
Agora copiado pra /usr/lib/xorg/xorg-configure.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bug crítico no autostart: QUIRK_DEVICE vem de /sys/firmware/devicetree
/base/model e quase sempre tem espaços ("Game Console R36S"). O loop
`for QDIR in ${QUIRK_DIRS}` com string concatenada partia esse path em
3 tokens (Game, Console, R36S) e o glob ${QDIR}/* não casava com nada.
Resultado: nenhum quirk device-specific rodava — 001-device_config
nunca escrevia /storage/.config/profile.d/001-device_config, então
DEVICE_TEMP_SENSOR / DEVICE_PWR_LED_GPIO / DEVICE_PLAYBACK_PATH_*
ficavam vazios em todos os processos. O System Information do ES não
mostrava CPU TEMPERATURE, GPU TEMPERATURE, e os start_*.sh dos
emuladores caíam em fallback de áudio.
Fix usa arrays bash com expansão entre aspas:
QUIRK_DIRS=(...)
for QDIR in "${QUIRK_DIRS[@]}"; do ...
archr-info ganha 5 melhorias:
- DISTRO FAMILY: lê ID_LIKE de /etc/os-release e renderiza
"Arch Linux" (título). OPERATING SYSTEM agora mostra "ArchR Linux"
para deixar a relação com Arch explícita.
- DISK SPACE: detecta quando games-internal e games-external apontam
para o mesmo device e mostra só "INTERNAL" (a UI repetia a linha
idêntica quando não havia SD externo).
- MESA VERSION: sniffa libgallium-X.Y.Z.so para mostrar 26.1.3.
- GPU DRIVER: lsmod identifica panfrost (Mesa) ou mali_kbase (legacy
blob), útil pra debugar quando o user troca via picker.
- info_quirks: protegido contra chamada sem argumento (era o motivo
do exit 127); usa nullglob + iteração quoted para suportar paths com
espaços e diretórios info.d/* ausentes.
Game Console R36S/001-device_config: define DEVICE_GPU_TEMP_SENSOR
apontando para thermal_zone1 (gpu-thermal IP). A linha GPU TEMPERATURE
da seção GPU INFORMATION agora aparece no ES.
Saída final no R36S:
DEVICE: Game Console R36S
OPERATING SYSTEM: ArchR Linux
DISTRO FAMILY: Arch Linux
CPU TEMPERATURE: 54°
GPU TEMPERATURE: 55°
MESA VERSION: 26.1.3
GPU DRIVER: mali_kbase (legacy blob)
...
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
systemd-analyze verify reclamava em 3 frentes:
1. StartLimitIntervalSec / StartLimitBurst em [Service] são
silenciosamente ignorados, eles têm que ficar em [Unit].
emustation.service e essway.service tinham os dois na seção errada,
então a proteção contra restart-flood (Restart=always) nunca era
aplicada. avahi-daemon.service tinha um StartLimitInterval (alias
antigo, sem 'Sec') também na seção errada. Movidos para [Unit] em
todos os três e renomeados para o key canônico.
2. sixaxis@.service é um template — instâncias são spawnadas sob
demanda por udev (99-sixaxis.rules põe SYSTEMD_WANTS=sixaxis@%E
{DEVNAME}). enable_service criava um symlink do template puro em
multi-user.target.wants/, dangling porque template sem instância
não roda. Removido o enable_service.
3. emulationstation procurava traduções em /usr/share/locale mas o
ArchR embarca os .mo em /usr/config/locale via userconfig rsync,
então o ES nunca encontrava emulationstation2.mo. Patch no fork ES
(commits 8125fdf, 715ea4b no archr-linux/emulationstation-next):
- main.cpp: prefere /usr/config/locale quando ele existe;
- Platform.cpp: getArchString() lê HW_DEVICE do env (já exportado
pelo profile.d/999-export) em vez de /usr/share/batocera/
batocera.arch que nunca embarcamos;
- Scripting.cpp: aceita /run/emulationstation/scripts além do
legado /var/run/emulationstation/scripts.
archr-fhs-bridges.conf cria /run/emulationstation/scripts vazio em
todo boot para usuário poder dropar hooks (game-start, game-end,
system-selected, ...) sem mkdir manual após cada reset do tmpfs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
audio output X gravava o .asoundrc em /userdata/system/, herdado do
Batocera. Em ArchR a homedir de root é /storage, e o ALSA carrega
$HOME/.asoundrc, então o arquivo nunca chegava em lugar útil. Move
para /storage/.asoundrc.
A linha aplay tentava reproduzir /usr/share/sounds/Mallet.wav, que
não embarcamos. Trocar pelo launch.ogg dos retroarch-assets (já no
rootfs) e silenciar o erro com 2>/dev/null para não derrubar o
comando se a saída de áudio acabou de mudar e o aplay falha.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
A varredura via SSH no R36S rodando a 20260624 expôs várias
divergências entre rootfs estagiado e tmpfs/runtime. Cada arquivo
deste commit resolve um gap encontrado na investigação.
archr/tmpfiles.d/z_02_archr-fhs-bridges.conf (NEW):
/var é tmpfs (busybox/system.d/var.mount), então todos os bridges
FHS instalados como symlinks no rootfs eram apagados pelo mount.
Republicar a estrutura via systemd-tmpfiles após var.mount. Resolve
/var/lib/pacman, /var/cache/archr/*, /var/lib/archr/{config,data,
games,backup}, /var/lib/{samba/private,tailscale,bluetooth},
/var/spool/cron, /var/cache/pacman/pkg. Inclui também os targets em
/storage (cron, locpath, tailscale, samba, .local/share, fstrim.run,
journald.conf.d, request-key.d) que estavam ausentes.
ui/emulationstation/package.mk:
ln -sf usava \${INSTALL}/usr/config/... como alvo, vazando o caminho
absoluto do builder para o symlink /etc/emulationstation/es_systems.cfg
no SO final. Trocar pelo path do target.
archr/system.d/timers.target.wants/{rocknix→archr}-report-stats.timer:
Symlink apontava para um arquivo inexistente (rocknix-report-stats);
o timer real chama-se archr-report-stats. Renome.
misc/modules/sources/images/install-{rocknix→archr}.svg:
gamelist.xml já referenciava install-archr.svg; o arquivo se chamava
install-rocknix.svg, quebrando o asset.
emulators/.../gamepads/ROCKNIX→ArchR Gamepad.cfg:
Conteúdo já estava com input_device="ArchR Gamepad"; rename casa o
nome de arquivo com a string de matching.
archr/package.mk + profile.d/005-locale:
LANG="" no SO rodando, todas LC_*=POSIX. glibc gera en_US.UTF-8.
Criar /etc/locale.conf e profile.d que source-a para shells de login
e SSH (que não herdam LANG via systemd env).
sysutils/systemd/scripts/userconfig-setup + freej2me-lr/freej2me.sh:
/storage/jdk caiu como arquivo vazio em algumas builds antigas e
transforma o symlink /opt/jdk em "Not a directory". Saneamento
duplo: a cada boot e antes do download do JDK.
devel/crossguid/package.mk + standalone/hypseus-singe/package.mk:
cmake_install.cmake / crossguid-config.cmake embutiam o BUILD path
do host. Remover dos pacotes target (não rodam em runtime).
tools/pyFDT/package.mk + network/samba/package.mk:
setuptools e waf escrevem o python3 do TOOLCHAIN no shebang dos
entry-points (pydtc, samba-gpupdate). Reescrever pra /usr/bin/python3.
sysutils/systemd/package.mk:
systemd-sysroot-fstab-check é um symlink para
systemd-fstab-generator, que removemos para fora dos generators.
Apagar o link junto. Strip também a regra do legacy.conf que cria
/var/log/README apontando para /usr/share/doc (não embarcamos docs).
sysutils/udevil/package.mk:
/etc/udevil/udevil-user-root.conf é symlink para
/storage/.config/udevil.conf que nunca era populado. Copiar a conf
também para /usr/config/udevil.conf, daí o rsync do userconfig-setup
o semeia no primeiro boot.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Live diagnostic on a R36S running the 20260624 image showed:
archr:~ # gpg --version | head -1
gpg (GnuPG) 1.4.23
archr:~ # gpg --list-packets /usr/share/pacman/keyrings/archr.gpg
:public key packet:
...
unknown algorithm 22
GPG 1.4 is the "classic" branch, frozen before Ed25519 (algorithm 22)
was added in 2.1.x (2014). pacman-key 7.x also calls into gpg with
--check-signatures, a 2.x-only flag. With the ArchR master subkey
being Ed25519 the legacy 1.4 binary can neither parse nor verify the
keyring, so pacman -Sy fails with "no valid user IDs" and "signature
... is invalid" no matter how the user populates the keyring.
Fix the build, not the key. JELOS-era pacman packages cap GnuPG at
1.4.23 because that's the minimal-deps branch; ArchR is now an
Arch-family distro that ships pacman 7 as the user-facing update path,
so it has to ship the modern GnuPG runtime that pacman expects.
New packages:
- libksba 1.8.0
- npth 1.8
- pinentry 1.3.2 (built with --enable-pinentry-tty/curses only;
the GUI variants would pull GTK/Qt that the handheld doesn't have)
Updated:
- gnupg 1.4.23 -> 2.4.8 (latest LTS branch)
Configure trims to the bits pacman uses: gpg + gpgsm + gpgconf.
scdaemon, dirmngr, tofu, wks, gpg-card and the historical 1.4-era
ciphers (idea/cast5/md5/rmd160) are disabled to keep the image lean.
pinentry-tty is the configured pinentry program, since the handheld
has no graphical desktop session to use the other variants.
libassuan, libgcrypt and libgpg-error already live in projects/ArchR/
packages/security/ from earlier work — no new dep tree there.
This unblocks the pacman pipeline on R36S: archr-keyring populate will
parse the Ed25519 master, signature verification will accept the
ArchR-signed archr.db, and pacman -Sy lands at the package list.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Upstream pacman ships pacman-key, makepkg, vercmp and friends as bash
scripts whose shebang is built against the configured sbindir (/usr/sbin
on Arch). Arch ships /usr/sbin as a symlink to /usr/bin via the usrmerge
package, so the shebang resolves fine. ArchR (LibreELEC heritage)
does NOT merge sbin: /usr/sbin is a real directory and bash lives at
/usr/bin/bash only. Result on a fresh boot:
archr:~ # pacman-key --init
-sh: /usr/bin/pacman-key: /usr/sbin/bash: bad interpreter: No such
file or directory
which also makes the pacman-init.service silently miss the keyring
populate step.
Post-install pass that rewrites every "#!/usr/sbin/bash" first line
to "#!/usr/bin/bash" anywhere under ${INSTALL}/usr fixes the lot in
one shot. The pkg.tar.zst we ship in the repo will need the same
treatment, but that's handled at build time too because gen-pacman-repo
packages whatever install_pkg holds.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
User reported on a freshly flashed R36S:
archr:~ # pacman
error: failed to initialize alpm library:
(root: /, dbpath: /var/lib/pacman/)
could not find or read directory
The package.mk created /var/lib/pacman as a real directory in
post_makeinstall_target (mkdir -p), then in post_install ran
`ln -sf /storage/.pacman/db ${INSTALL}/var/lib/pacman`. When LINK is
an existing directory, ln -sf does not replace it — it creates
LINK/$(basename TARGET). So the installed image ended up with:
/var/lib/pacman/ ← real, empty dir (rootfs, ro)
/var/lib/pacman/db -> /storage/.pacman/db ← child symlink
Pacman reads dbpath=/var/lib/pacman/ from pacman.conf, looks for
local/ and sync/ inside it, finds nothing, and bails.
Fix: install /var/lib/pacman directly as a symlink to
/storage/.pacman/db in one shot, no intermediate mkdir. Same for
/var/cache/pacman/pkg. Move both into post_makeinstall_target so the
file layout is decided in one place; post_install now only enables
the pacman-init service.
Runtime escape hatch on already-installed systems (since the rootfs
is squashfs-ro and can't be patched):
mount --bind /storage/.pacman/db /var/lib/pacman
mount --bind /storage/.pacman/cache /var/cache/pacman/pkg
This commit fixes the build so the next image flashes correctly.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Douglas Teles