# Porting Arch Linux to s390x: A comprehensive technical roadmap

The s390x architecture presents unique opportunities and challenges for Arch Linux expansion beyond x86_64. Based on extensive research into existing s390x Linux distributions, cross-compilation methods, and architecture-specific requirements, this report provides a complete technical roadmap for implementing Arch Linux on IBM Z/LinuxONE systems.

## Technical feasibility meets institutional challenge

**Successfully porting Arch Linux to s390x is technically achievable but requires sustained community commitment and significant infrastructure investment.** The technical framework exists through proven implementations in Ubuntu, RHEL, SUSE, Debian, and Alpine Linux. However, the specialized knowledge requirements, hardware access constraints, and ongoing maintenance burden present substantial challenges that have prevented any active s390x porting efforts within the Arch Linux community to date.

The s390x architecture differs fundamentally from x86_64 in several critical ways. It uses big-endian byte ordering, requires the zipl bootloader instead of GRUB, and operates with channel-based I/O rather than interrupt-driven mechanisms. These differences necessitate architecture-specific adaptations throughout the distribution, from kernel configuration to package building processes.

Current research reveals that while Arch Linux has successfully supported alternative architectures through projects like Arch Linux ARM, no active or historical s390x porting efforts exist. This absence reflects both the specialized nature of mainframe systems and the limited overlap between typical Arch Linux users and enterprise mainframe operators.

## Cross-compilation provides the critical bootstrap path

Building s390x versions of the Linux kernel requires a well-configured cross-compilation environment. The process begins with installing the appropriate toolchain on an x86_64 host system. For Debian-based systems, this involves installing `gcc-s390x-linux-gnu`, `g++-s390x-linux-gnu`, and `binutils-s390x-linux-gnu`. The kernel build process itself requires specific environment variables: `ARCH=s390` (not s390x) and `CROSS_COMPILE=s390x-linux-gnu-`.

Essential kernel configuration options for s390x include **CONFIG_S390=y**, **CONFIG_64BIT=y**, and architecture-specific features like **CONFIG_MARCH_Z13=y** for modern hardware support. The s390x kernel requires unique drivers absent from x86_64 configurations, including DASD storage drivers, OSA-Express network adapters, and console support for 3270 terminals. Pre-built kernels from Ubuntu or Debian repositories offer a practical starting point, available at `ports.ubuntu.com/ubuntu-ports/` with versions supporting z13/z13s architecture and newer.

The kernel compilation process for s390x follows standard Linux practices with architecture-specific adjustments. A typical build command sequence includes `make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- defconfig` followed by `make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- bzImage modules`. Testing compiled kernels requires either access to real s390x hardware or QEMU emulation with appropriate configuration parameters.

## initramfs creation demands architecture-specific adaptations

Creating a functional initramfs for s390x involves significant modifications to standard Arch Linux tools. The process requires both cross-compilation capabilities and architecture-specific utilities from the s390-tools package. Two primary approaches exist: using dracut for maximum compatibility or manually building with busybox and required tools.

### Cross-compilation environment setup

Building s390x userspace components requires a properly configured cross-compilation toolchain. On x86_64 hosts, install the necessary packages:

```bash
# Debian/Ubuntu
apt-get install gcc-s390x-linux-gnu g++-s390x-linux-gnu \
    binutils-s390x-linux-gnu qemu-user-static binfmt-support

# Fedora
dnf install gcc-s390x-linux-gnu binutils-s390x-linux-gnu \
    qemu-user-static

# Arch Linux (via AUR)
yay -S s390x-linux-gnu-gcc s390x-linux-gnu-binutils qemu-user-static
```

The binfmt_misc kernel module enables transparent execution of s390x binaries through QEMU user-mode emulation, essential for second-stage operations.

### Building BusyBox for s390x

BusyBox provides the core utilities for a minimal initramfs. Static compilation ensures no dependency on shared libraries:

```bash
wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2
tar xf busybox-1.36.1.tar.bz2
cd busybox-1.36.1

# Configure for s390x with static linking
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- defconfig
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- menuconfig

# Enable: Settings -> Build static binary (no shared libs)
# Select needed applets for initramfs functionality

make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- -j$(nproc)
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- install
```

The static binary can be verified with:
```bash
file busybox
# busybox: ELF 64-bit MSB executable, IBM S/390, statically linked
```

### Essential s390-tools utilities

The s390-tools package provides critical utilities for s390x systems. Key components for initramfs include:

- **vmcp**: Interface to z/VM Control Program commands
- **dasdfmt**: Low-level DASD formatting utility
- **chccwdev**: Channel device configuration tool
- **zfcp tools**: Fibre channel storage management
- **vmur**: z/VM spool file handling

Cross-compiling s390-tools requires careful handling of dependencies:

```bash
git clone https://github.com/ibm-s390-linux/s390-tools.git
cd s390-tools

# Many tools can be built with cross-compilation
make ARCH=s390x CROSS_COMPILE=s390x-linux-gnu- \
     HAVE_CARGO=0 HAVE_OPENSSL=0 HAVE_LIBCURL=0
```

### Dracut-based initramfs creation

Dracut provides the most robust method for creating s390x initramfs, with built-in support for cross-architecture scenarios:

```bash
# Create sysroot directory
mkdir -p /tmp/s390x-sysroot

# Install dracut modules for s390x
dracut --sysroot=/tmp/s390x-sysroot \
       --kver=5.15.0-s390x \
       --force \
       --add "base network kernel-modules qemu" \
       --add-drivers "dasd_eckd_mod dasd_fba_mod qeth zfcp" \
       /tmp/initramfs-s390x.img

# For cross-compilation with specific tools
DRACUT_LDCONFIG=/usr/s390x-linux-gnu/bin/ldconfig \
DRACUT_LDD=/usr/s390x-linux-gnu/bin/ldd \
DRACUT_TESTBIN=/tmp/s390x-sysroot/bin/sh \
dracut --sysroot=/tmp/s390x-sysroot ...
```

### Manual initramfs assembly

For fine-grained control, manually assembling the initramfs allows precise inclusion of required components:

```bash
# Create directory structure
mkdir -p initramfs/{bin,sbin,etc,proc,sys,dev,lib,lib64,usr/bin,usr/sbin}

# Copy busybox and create links
cp busybox-s390x initramfs/bin/busybox
chroot initramfs /bin/busybox --install -s

# Copy s390x dynamic linker
cp /usr/s390x-linux-gnu/lib/ld64.so.1 initramfs/lib64/
cp -a /usr/s390x-linux-gnu/lib/ld-*.so initramfs/lib64/

# Add s390-specific tools
cp /usr/s390x-linux-gnu/sbin/{vmcp,dasdfmt,chccwdev} initramfs/sbin/

# Create init script
cat > initramfs/init << 'EOF'
#!/bin/busybox sh

# Mount essential filesystems
/bin/busybox mount -t devtmpfs devtmpfs /dev
/bin/busybox mount -t proc none /proc
/bin/busybox mount -t sysfs none /sys

# Load s390x-specific modules
modprobe dasd_eckd_mod
modprobe qeth
modprobe zfcp

# Activate channel devices
for dev in /sys/bus/ccw/devices/*/online; do
    echo 1 > "$dev" 2>/dev/null
done

# S390-specific initialization
if [ -x /sbin/vmcp ]; then
    /sbin/vmcp q userid
fi

echo "Boot took $(cut -d' ' -f1 /proc/uptime) seconds"
exec /bin/busybox sh
EOF

chmod +x initramfs/init

# Create initramfs archive
cd initramfs
find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../initramfs-s390x.img
```

### Essential kernel modules

The s390x initramfs must include architecture-specific kernel modules:

- **Core system**: `s390_trng` (hardware RNG), `appldata_*` (performance data)
- **Storage**: `dasd_eckd_mod`, `dasd_fba_mod`, `dasd_diag_mod` (DASD variants)
- **Network**: `qeth`, `qeth_l2`, `qeth_l3` (OSA-Express), `netiucv` (IUCV)
- **Fibre Channel**: `zfcp`, `scsi_transport_fc`
- **Virtualization**: `virtio_blk`, `virtio_net`, `virtio_pci` (KVM support)

### Boot process integration

The s390x boot process differs fundamentally from x86:

1. **IPL (Initial Program Load)** replaces BIOS/UEFI boot
2. **zipl bootloader** loads kernel and initramfs
3. **Channel subsystem** initialization occurs early
4. **Device detection** uses channel paths, not PCI scanning

The initramfs must handle:
- CCW device activation via sysfs
- DASD online/offline state management
- z/VM guest commands through vmcp
- Channel path configuration

### Testing with QEMU

Verify the initramfs using QEMU s390x emulation:

```bash
qemu-system-s390x \
    -machine s390-ccw-virtio \
    -cpu max \
    -m 2G \
    -kernel vmlinuz-s390x \
    -initrd initramfs-s390x.img \
    -append "root=/dev/ram0 console=ttyS0" \
    -nographic
```

This approach enables thorough testing before deployment on actual s390x hardware.

## Arch Linux architecture porting requires systematic adaptation

Arch Linux currently supports only x86_64 officially, with architecture ports requiring modifications throughout the distribution infrastructure. PKGBUILDs need architecture arrays updated to include `arch=('s390x')`, while makepkg.conf requires s390x-specific settings including `CARCH="s390x"`, `CHOST="s390x-unknown-linux-gnu"`, and appropriate compiler flags like `-march=z13 -mtune=z15`.

The bootstrap process follows a three-stage approach: initial cross-compilation of core packages, transition to emulated native building, and finally full native compilation on s390x hardware. Critical bootstrap dependencies include the cross-compilation toolchain, base system components (glibc, gcc-libs, bash), and Arch-specific tools (pacman, makepkg) compiled for s390x.

Package management adaptations involve configuring pacman for s390x architecture recognition, establishing separate repository hierarchies, and implementing architecture-specific dependency resolution. The lack of existing Arch Linux s390x efforts means starting from scratch, unlike the established Arch Linux ARM project that provides a reference implementation.

## Existing distributions demonstrate proven implementation patterns

**SUSE Linux Enterprise Server** pioneered s390x Linux support in 2000, utilizing the OpenSUSE Build Service with dedicated s390x builders. Their implementation supports LPAR, z/VM, and KVM environments with full container capabilities. **Red Hat Enterprise Linux** requires IBM z14 minimum for current versions, supporting various storage backends including DASD, FCP-attached SCSI, and virtio devices.

**Ubuntu's s390x port** began with 16.04 LTS, requiring z13/z13s minimum for modern versions. The distribution uses the Ubuntu Ports infrastructure with packages available at `ports.ubuntu.com/ubuntu-ports/`. **Debian** maintains approximately 90% package coverage through build infrastructure at ITZBund and other facilities. **Alpine Linux** offers a minimal, musl-based alternative particularly suited for container deployments.

These distributions share common implementation patterns: dedicated build infrastructure, cross-compilation for initial bootstrap, architecture-specific package modifications, and close collaboration with IBM for hardware access and optimization. Their experiences highlight both the technical feasibility and resource requirements for maintaining an s390x port.

## IBM Z hardware demands specialized considerations

The s390x architecture implements z/Architecture with 64-bit addressing and big-endian byte ordering. Modern distributions require z13/z13s (2015) minimum, with current generation z16/z17 systems offering enhanced capabilities. The boot process uses IPL (Initial Program Load) rather than BIOS/UEFI, controlled through Hardware Management Console for LPAR or Control Program for z/VM guests.

Storage options include **DASD** (Direct Access Storage Devices) using ECKD format with FICON connectivity, limited to three partitions per device. **FCP** (Fibre Channel Protocol) provides industry-standard SCSI connectivity with multipathing support. Network adapters comprise **OSA-Express** for Ethernet connectivity and **HiperSockets** for high-speed inter-LPAR communication within a single system.

Virtualization support encompasses both traditional z/VM and newer KVM implementations (z13+). Hardware cryptographic acceleration through Crypto Express adapters and on-chip compression (z15+) provide performance advantages. These features require specific kernel configurations and userspace tool support for optimal utilization.

## Development environments enable practical implementation

**QEMU system emulation** provides full s390x virtualization on x86_64 hosts, though with significant performance penalties. Basic setup requires `qemu-system-s390x` with appropriate CPU and device configurations. User-mode emulation through `qemu-s390x-static` enables running individual s390x binaries within x86_64 environments, facilitating package building and testing.

**Cross-compilation toolchains** from major distributions offer pre-built solutions. Fedora provides `gcc-s390x-linux-gnu` packages, while Debian/Ubuntu offer similar tooling with multi-architecture support. LLVM/Clang added full s390x support in version 18.1, providing an alternative to GCC-based toolchains.

**Container-based development** leverages Docker/Podman multi-architecture capabilities. The `docker buildx` command enables building s390x containers on x86_64 hosts. Pre-built base images from major distributions facilitate rapid development environment setup. **IBM LinuxONE Community Cloud** provides free 120-day access to actual s390x hardware, essential for performance testing and validation.

## Implementation roadmap charts the path forward

**Phase 1: Infrastructure establishment** begins with securing s390x hardware access through IBM Community Cloud or partnerships. Creating cross-compilation toolchains for initial bootstrap follows, along with repository structure setup mirroring the ports.archlinux.org model. Package signing infrastructure specific to s390x ensures security and authenticity.

**Phase 2: Core system bootstrap** focuses on porting essential packages including glibc, gcc, binutils, and the Linux kernel. Creating a minimal bootable system with zipl bootloader integration establishes the foundation. Porting pacman and core utilities enables native package management on the target architecture.

**Phase 3: Full distribution development** involves mass package building using native s390x infrastructure, comprehensive quality assurance testing on real hardware, and documentation creation for s390x-specific procedures. Community engagement with the existing IBM Z Linux ecosystem provides ongoing support and knowledge sharing.

**Critical success factors** include sustained community commitment from maintainers with mainframe expertise, potential corporate support from IBM or enterprise users for infrastructure, realistic scope definition for package coverage, and adherence to Arch Linux's quality standards throughout the porting process.

## Economic and strategic considerations shape viability

The mainframe Linux market represents a specialized but significant segment of enterprise computing. Organizations running IBM Z systems often seek Linux alternatives for modernization while maintaining mainframe reliability advantages. However, the Arch Linux philosophy of simplicity and user choice may conflict with typical mainframe deployment scenarios requiring extensive vendor support and certification.

Infrastructure costs present substantial barriers, as s390x hardware remains expensive even in cloud environments. Build server requirements, whether physical or virtualized, demand significant investment compared to commodity x86_64 systems. The limited pool of developers with both Arch Linux and mainframe expertise further constrains volunteer availability.

Despite these challenges, successful implementation would position Arch Linux uniquely in the enterprise mainframe space, potentially attracting corporate sponsorship and expanding the distribution's reach into new markets. The technical learning opportunities and architectural diversity benefits align with open-source development principles.

## Conclusion: Technical feasibility awaits community catalyst

Porting Arch Linux to s390x is technically feasible, with clear implementation paths demonstrated by multiple successful Linux distributions. The required tools, documentation, and reference implementations exist. However, success depends entirely on finding dedicated maintainers willing to commit to the substantial initial effort and ongoing maintenance burden.

The absence of current s390x porting efforts within the Arch Linux community reflects practical realities rather than technical impossibilities. Should sufficient interest and resources materialize—whether through corporate sponsorship, academic initiatives, or passionate individual contributors—this comprehensive technical roadmap provides the blueprint for bringing Arch Linux to IBM's mainframe architecture. The question remains not whether it can be done, but whether the community sees sufficient value to justify the significant investment required.