Archinstall 4.5: practical checks for ARM64 and low-latency Arch Linux installs

Archinstall 4.5 updates Arch Linux’s guided text installer with stronger AArch64 support, real-time kernel choices, reliability fixes, and safer defaults. It does not replace the Arch Installation Guide, but it reduces repeated setup work while users still choose disks, bootloader, kernel, networking, and desktop configuration. The release matters most to ARM64 adopters and teams with a measured low-latency requirement.

What changed for ARM64

The installer can now set up GRUB and Limine EFI installations on compatible AArch64 systems and recognizes the AArch64 root partition type GUID. This makes the guided path more realistic for ARM servers, development boards, laptops, and workstations that provide conventional UEFI. It does not make every ARM device installable: firmware, boot chains, and kernel support remain platform-specific and must be validated against device documentation.

Five practical changes

• GRUB and Limine EFI workflows extend to AArch64 UEFI hardware.
• The AArch64 root GUID improves GPT layout handling for the architecture.
• linux-rt and linux-rt-lts can be selected during installation.
• Optional linux-firmware dependencies better match firmware to devices.
• Missing vpl-gpu-rt and libvpl packages are included for post-Gen12 Intel graphics, helping media acceleration in tools such as FFmpeg and OBS.

Real-time kernels seek predictable latency rather than the highest average throughput. They make sense for professional audio, industrial control, robotics, measurement, and specialized embedded work. A normal desktop, gaming machine, or general server usually has no automatic reason to use one. Start with the standard kernel unless a workload and measurements justify RT, and retain a normal-kernel recovery path.

Reliability and security fixes

Archinstall now handles Wi-Fi SSIDs containing spaces, a mundane fix with outsized value when an installer needs a package network connection. TLS certificate verification is enabled, reducing exposure to interception on untrusted networks. EFI mounts use fmask=0177 to limit permissions on boot-related files. Those defaults help, but they do not replace firmware passwords, Secure Boot policy, or physical controls.

The credential-encryption question appears only when credentials will be saved. Locale generation sets a fully qualified LANG value. Norwegian Bokmål, Serbian, and Vietnamese translations are added, and summary presentation is made more consistent. Review screens deserve attention: they are the last easy chance to catch a wrong disk, bootloader, or network choice.

Pre-install checklist

• Back up data and identify the target disk by size and serial, not only /dev/sdX.
• On ARM64, confirm UEFI behavior, supported bootloader, and the vendor’s boot instructions.
• Select RT only for a defined latency need; test an ordinary-kernel fallback.
• Test the intended Wi-Fi and keep Ethernet or an internal mirror available.
• After first boot, validate firmware, graphics, media acceleration, and EFI permissions.
• Read the summary before committing; do not store reusable configuration with secrets.

Conclusion

Archinstall 4.5 broadens and hardens the guided Arch Linux installation path. Its value comes from matching the installer choices to real hardware and workload constraints, then verifying the finished system. Automation reduces repetition; it does not remove the need for backups, device-specific research, and post-install checks.

Nguồn / Source

Biên soạn từ nguồn gốc.

Validation after the first boot

Do not treat a successful installer exit as the acceptance test. Confirm the firmware starts the expected boot entry without removable media, then inspect the partition table and mounted filesystems. Check that the selected kernel is running, that the fallback boot entry works, and that network access uses the intended interface. On ARM64, record firmware version, boot settings, and any board-specific parameters alongside the installation configuration; these details make a later rebuild reproducible.

For systems using Wayland profiles, sign in normally and verify session, input, graphics, suspend, and external-display behavior. For Intel media work, run a small hardware-accelerated encode or decode test rather than assuming the packages are enough. If the system has a real-time requirement, measure latency under representative load before declaring success. Baseline the result, preserve logs, and update the build runbook with any device-specific exceptions.