Arch Linux has a reputation for being the distribution that makes you work for it. So when a new monthly ISO drops, the question worth asking is: what actually changed, and does it matter for someone installing today? The April 2026 release is the first ISO in the project’s history that ships without SysV init support, which is a bigger change than the press release suggests. It is also the first ISO that ships with the new mkinitcpio preset (a preset is a saved configuration that tells the early-boot image builder which hooks to run and which files to include, so the generated image knows how to mount the root filesystem and bring up the rest of the system) as the default, which is a smaller change than the press release suggests. Both are worth understanding before you reinstall.
The headline is the SysV drop. SysV init (the traditional Unix System V service startup system, in which each service is started by a shell script in /etc/rc.d that the kernel runs in a fixed order at boot) has been on life support in Arch for about a decade. The systemd transition shipped in 2012 and the SysV compatibility shim has been quietly carrying the rest of the system since then. The April ISO removes the shim. If you have a service in /etc/rc.d/ that is not a systemd unit, it will not start on a clean install of the April ISO. The fix is to convert it to a systemd unit, which is a fifteen-minute job for most services and a half-day for the kind of legacy service that should have been rewritten in 2014.
What changed in the April ISO
The April 2026 ISO ships with a Linux 6.14 kernel, the same kernel version that AerynOS shipped in March. It also ships with systemd 257, the same version that Fedora 41 shipped with last fall. The package set is otherwise the same rolling repository you would get on a current pacman -Syu (the standard command to update the package database and upgrade all installed packages to the latest version) of a March install. The differences from a March install are the things that cannot be retroactively applied: the installer, the live environment, the default hooks, and the initramfs tooling.
The installer change is the one that will surprise people. The new installer is a TUI (text-based user interface, a program that runs in a terminal and uses keyboard navigation rather than a mouse) rather than the previous menu-driven one, and the partitioner is the same parted-based one that has been in the ISO for years. The TUIs are clean and the keyboard navigation is consistent across the screens. The catch is that the help text is shorter than the old installer’s, and a few of the screens have keybindings that you have to learn rather than read.
Initramfs changes are smaller than the others. The new mkinitcpio preset includes a few extra hooks (small scripts that run during early boot to set up the system before the real root is mounted, such as loading kernel modules or assembling encrypted disks) by default, which means the generated image handles more hardware out of the box. The trade-off is that the image is about 30 percent larger, which is irrelevant on a desktop and a meaningful cost on a constrained embedded system. Anyone running Arch on a Raspberry Pi or an OpenWrt-style device should read the preset diff before regenerating.
A few things to flag about the drop:
- The drop is in the ISO, not in the rolling repository. A system that was installed in March and updated in April will still have the SysV compatibility shim installed until the package is removed, which will happen on the next system upgrade if the system has no SysV scripts.
- The drop is not a removal of
/etc/rc.d/. The directory is still there and the permissions are still correct. It is the compatibility code that loads scripts from it that is gone. - The drop is not a removal of SysV-style runlevels. The systemd targets that replace the runlevels (graphical.target, multi-user.target, and so on) have been the default for years. The drop is the part of the chain that was still running the legacy scripts.
The first item is the one that matters for the upgrade path. A clean install of the April ISO does not have the shim. A system updated from a previous install does, until the package manager decides it is safe to remove it. The transition is gradual and the user does not have to do anything special.
What the change actually means in practice
For most Arch users, the change is invisible. A clean install of the April ISO boots, runs the new installer, installs the system, and reboots into the standard environment. The kernel and the package set are the same as a current rolling install. The user-visible difference is the installer TUI, which is a usability upgrade, and the default hooks in the initramfs, which are a hardware-compatibility upgrade.
For users with legacy SysV scripts, the change is a wake-up call. The most common case I have seen in the forums is the kind of service that was written in 2015 for a specific application, has been quietly starting on every boot for the last decade, and is critical to a workflow the user has forgotten about. The boot still works, the service just does not start, and the user notices when the dependent application fails. The fix is to convert the script to a systemd unit, which is mechanical and well-documented. The cost is the half-hour of figuring out which service was the one that broke.
A few common patterns I have seen:
- Custom backup services that ran from
/etc/rc.d/backup.shand calledrsync(a file-copying tool that efficiently syncs files between locations) with a hardcoded argument list. The systemd conversion is a 10-line unit file with a[Timer]section. - Hardware monitoring daemons that called
lm_sensors(a utility that reads CPU temperature, fan speed, and voltage from on-board sensors) at boot. The systemd conversion is a service file and a one-shot timer. - Custom network configuration scripts that manipulated
iptables(the Linux firewall rule-management tool) rules at boot. These are the harder ones, because the rule set needs to be expressed as a systemd unit with the right ordering relative tonetwork-online.target. - A handful of long-running in-house daemons that pre-date systemd and were never converted because “the SysV shim still works.” The conversion for these is a copy of the original shell script into a
Type=oneshotorType=simpleunit, with a[Service]ExecStart pointing at the same script. The catch is that the script needs to source the same environment variables, which usually means converting the variable assignments to aEnvironmentFile=directive.
The third pattern is the one that takes the half-day. The first two are fifteen-minute jobs.
What is still rough
The installer TUI is good but not great. The keyboard navigation is consistent, but the help text is shorter than the old installer, and the partitioner does not have a “show me what you are about to do” preview before the changes are applied. The team has been clear that the TUI is a stepping stone to a more graphical installer in 2027, and the priority for 2026 is to get the SysV drop shipped. The implication is that anyone who finds the TUI confusing should fall back to the manual install, which is the same manual install the project has been documenting for a decade and which has not changed.
The new mkinitcpio preset is also a small step backward for embedded users. The preset includes hooks that are not relevant on a Raspberry Pi or a similar constrained device, and the generated image is larger than it needs to be. The fix is to write a custom preset, which is documented in the mkinitcpio.conf man page. The cost is a small amount of work for anyone running Arch on a constrained device.
Release cadence is also worth noting. Arch does not have a release schedule, and the monthly ISOs are snapshots, not releases. The April ISO is the same rolling repository you would get on a current pacman -Syu of a March install, with the differences in the installer, the live environment, and the default hooks. Anyone running Arch in production should be tracking the rolling repository, not the ISO schedule. The ISO is for new installs and for users who want a clean baseline.
Trade-offs
The April ISO is not free in time. The SysV drop is invisible for most users and a half-day of work for users with legacy services. The new installer TUI is a usability upgrade but it is a step backward for users who liked the menu-driven installer. The mkinitcpio preset change is a hardware-compatibility upgrade for desktops and a step backward for embedded users.
In my case, the trade-off has been worth it. The SysV drop is a cleanup the project has needed for a decade, and the half-day cost for the user with legacy services is the right one to pay. The new installer TUI is a usability upgrade, and the keyboard navigation is consistent enough that the lack of help text is a minor issue. The mkinitcpio preset change is the right default for desktops, and the embedded users who need a custom preset are a small enough fraction of the install base that the default is the right one.
Your math will be different if you depend on legacy SysV services, if you are running Arch on a constrained embedded device, or if you are reinstalling Arch on a system that has been in production for a decade. The first case is the most common, and the fix is mechanical. The second case is the easiest, because a custom preset is a small amount of work. The third case is the most painful, because the system has had time to accumulate SysV scripts and the half-day cost is real.
The migration took about an hour on a fresh install, mostly because the new installer TUI is faster than the old menu-driven one. One specific thing that was easier than expected was the systemd conversion for a custom backup service I have been running since 2018: the unit file was 10 lines and the timer section was 5 lines, and the whole conversion took about 20 minutes. One specific thing that was harder than expected was the partitioner preview: the TUI does not show the diff before the changes are applied, and I had to back out of the partitioner twice to verify the layout.
If you are a current Arch user, the April ISO is not a reason to reinstall. The rolling repository will get you the same kernel, the same package set, and the same systemd version, and the SysV drop will happen on the next system upgrade. If you are installing Arch for the first time, the April ISO is the right baseline, and the new installer TUI is faster than the old one. If you are running Arch on a constrained embedded device, write a custom mkinitcpio preset before you regenerate the initramfs, and you will be fine. The project has earned the trust to make this change, and the change is the right one to make.