Installing Chimera Linux to QEMU VM

Installing Chimera Linux (ppc64, big-endian) on a QEMU/libvirt VM

This documents a from-scratch install of Chimera Linux on a pseries QEMU/KVM VM running on a POWER9 host, with a PReP boot partition and GRUB (powerpc-ieee1275 target).

Verification status: the GRUB/PReP step (grub-install /dev/vda1) and overall flow have been run for real and reported straightforward. Package names and dinit-specific commands below are verified against Chimera's actual repo and official docs, but the full sequence hasn't been run start-to-finish end to end, and a couple of spots are flagged inline as unconfirmed.

0. Why this is harder than an x86 install

PowerPC installs are unusually fragile compared to x86/UEFI mainly because there's no BIOS/UEFI boot menu convenience. The firmware is Open Firmware (SLOF under QEMU pseries), which boots from a raw PReP partition containing GRUB's core.img directly — no ESP, no bootloader search heuristics like UEFI has.

1. Preparation

1.1 Kernel and package reference

	Chimera ppc64 (big-endian)
Package repo	https://repo.chimera-linux.org/current/main/ppc64/
Kernel package	linux-lts (LTS track) or linux-stable (mainline track)
GRUB package	grub-powerpc-ieee1275 (architecture-locked)
Bootloader install	grub-install /dev/vda1 — targets the PReP partition directly, no extra flags needed
Init system	dinit
Privilege escalation	doas (opendoas package)
Network	dhcpcd + dhcpcd-dinit
SSH	openssh + openssh-dinit

Chimera also publishes a ppc64le repo (https://repo.chimera-linux.org/current/main/ppc64le/) if you need that instead.

• Disk: 50GB is comfortable. Layout:
  • vda1 — 9 MiB, PReP boot partition (no filesystem)
  • vda2 — ~43 GiB, ext4, root
  • vda3 — ~7 GiB, swap
• VM specs:
  • libvirt/QEMU, machine='pseries-10.2', cpu model='POWER9', 8 vCPUs, 8GiB RAM
  • Disk: virtio-blk, backed by a qcow2 image
  • NIC: virtio model
  • Install media: attached as a scsi cdrom (virtio-scsi controller)
  • A serial console is essential: <serial type='pty'><target type='spapr-vio-serial'/></serial>. This is your only way to interact with the SLOF firmware and the GRUB shell — there's no graphical framebuffer to fall back on. Access it with virsh console <domain> (needs a real pty — allocate one with ssh -tt if you're driving this over SSH, or run it in a local terminal).

2. Getting the install media and booting it

Chimera provides bootstrap tarballs (bare userland + apk, for container-style installs), full tarballs (complete non-graphical system, no kernel/bootloader — for fully manual chroot-style installs), and live ISOs for "most POWER architecture systems." Get whichever matches your plan from the Chimera Linux project.

1. Attach the install media to the VM as a cdrom device with <boot order='1'/>, ahead of the disk (<boot order='2'/> on the virtio disk).
2. Start the VM and attach to the console:

virsh start <domain>
virsh console <domain>

1. Once installed, remember to flip the boot order back (or detach the install media) — otherwise every reboot lands back in the installer instead of the real disk, since SLOF always tries boot order 1 first and a live/install image is a valid bootable target every time.

3. Partitioning

From inside the live/install environment, partition the target disk (assume /dev/vda):

fdisk /dev/vda

• g — create a new empty GPT partition table
• n — new partition 1, size +9M (a PReP partition needs to be small; a handful of MB is plenty for GRUB's core.img)
  • t — change its type; search for "PowerPC PReP boot" and select it
• n — new partition 2, most of the remaining space, default type (Linux filesystem)
• n — new partition 3, remaining space for swap
  • t — set its type to Linux swap
• w — write the table

Format and mount:

mkfs.ext4 /dev/vda2
mkswap /dev/vda3
swapon /dev/vda3
mount /dev/vda2 /mnt

Sanity-check with lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINT /dev/vda before continuing: vda1 should have no FSTYPE (it stays raw — GRUB writes its core.img directly to the block device, not to a filesystem), vda2 should show ext4 and be mounted at /mnt, and vda3 should show swap.

4. Bootstrap and configuration

4.1 Bootstrap the base system

chimera-bootstrap -l /mnt

-l bootstraps from local packages/mirror into the target directory. By default this installs the base-full package group into the root; the kernel is not part of base-full and gets installed explicitly in the next step.

4.2 fstab and chroot

genfstab -U /mnt >> /mnt/etc/fstab
chimera-chroot /mnt

chimera-chroot mounts the pseudo-filesystems (/dev, /proc, /sys) and sets up network access for you automatically — use it rather than a bare chroot, which would leave /dev empty and break things like sshd later.

4.3 Kernel, GRUB, and base tooling

apk add linux-lts grub-powerpc-ieee1275 shadow bash opendoas openssh openssh-dinit dhcpcd dhcpcd-dinit

A few things worth being explicit about here, since they're easy to miss:

• The dinit service files are separate subpackages. openssh gives you the sshd binary but not its dinit service definition — that's in openssh-dinit. Same split for dhcpcd/dhcpcd-dinit. Forgetting the -dinit package means there's nothing to enable in step 4.6/4.7 even though the program itself is installed.
• shadow provides useradd/passwd (standard GNU shadow-utils) — install it explicitly rather than assuming it's part of base-full.
• bash likewise isn't guaranteed to be your default shell out of the box; install it explicitly if you want it as a login shell.

Rebuild the initramfs after installing the kernel:

update-initramfs -c -k all

4.4 Hostname, users, doas

echo chimera-power > /etc/hostname
passwd root

useradd -m -G wheel -s /bin/bash yourusername
passwd yourusername

Grant the wheel group access via doas's config, /etc/doas.conf:

echo 'permit persist :wheel' > /etc/doas.conf

Authorize your SSH key for the new user:

mkdir -p /home/yourusername/.ssh
echo '<your public key>' >> /home/yourusername/.ssh/authorized_keys
chown -R yourusername:yourusername /home/yourusername/.ssh
chmod 700 /home/yourusername/.ssh
chmod 600 /home/yourusername/.ssh/authorized_keys

4.5 GRUB install and config

grub-install /dev/vda1
update-grub

Just the PReP partition device, no --target/--boot-directory flags needed. This matches Chimera's own docs, which state that on PReP systems grub-install targets the PReP partition directly. grub-powerpc-ieee1275 is an architecture-locked package, so there's no ambiguity about which target to build for.

update-grub is Chimera's grub-mkconfig wrapper (writes /boot/grub/grub.cfg) — run it after grub-install, and again any time you change /etc/default/grub or install a new kernel.

Unconfirmed — watch for this: GRUB defaulting to gfxterm (a graphical terminal) can crash with no suitable video mode found on SLOF's serial-only console, which has no framebuffer — this drops you into an interactive grub> shell instead of showing the boot menu. This is general GRUB behavior on this firmware, not confirmed either way for Chimera's default config specifically. If you land at a grub> prompt instead of a menu after rebooting, check /etc/default/grub for GRUB_TERMINAL_OUTPUT and set it to console, then rerun update-grub.

4.6 Networking (dhcpcd via dinit)

dhcpcd handles DHCP directly, configured via /etc/dhcpcd.conf (the default behavior is to DHCP-configure all interfaces, so the stock config file needs no edits for a basic setup).

Since dinitctl doesn't work inside a chroot (there's no running dinit instance to talk to), enable the service by symlinking it manually into the boot runlevel directory instead:

ln -s /usr/lib/dinit.d/dhcpcd /etc/dinit.d/boot.d/dhcpcd

Once you've rebooted into the real system (not chroot), dinitctl works normally and this is the equivalent of what dinitctl enable dhcpcd does under the hood.

4.7 SSH (via dinit)

Same manual-symlink pattern as networking, for the same reason (no live dinit instance inside a chroot):

ln -s /usr/lib/dinit.d/sshd /etc/dinit.d/boot.d/sshd

(Verify the exact service name shipped by openssh-dinit — sshd is the expected name following the package's own binary name, but hasn't been independently confirmed here the way the package names above were.)

5. Finish and reboot

Exit the chroot, unmount, and detach the install media (or demote its boot order below the disk), then restart the VM:

exit
umount -R /mnt

Then, from the host (not the VM):

virsh detach-disk <domain> <cdrom-or-install-media-target> --config --live
virsh destroy <domain>
virsh start <domain>

Watch the console — you should see: SLOF → PReP partition → GRUB → kernel boot → login prompt, all without manual intervention.

6. Debugging the GRUB shell, if you land in one anyway

If you end up at an interactive grub> prompt:

grub> insmod part_gpt
grub> insmod ext2
grub> ls

GRUB names disks by Open Firmware device path, not hd0-style BIOS names — expect something like (ieee1275/disk) (ieee1275/disk,gpt1) (ieee1275/disk,gpt2) (ieee1275/disk,gpt3). Find your root and check what the kernel/initramfs are actually named before booting manually (these haven't been independently confirmed for Chimera the way they were for other distros' naming conventions):

grub> ls (ieee1275/disk,gpt2)/boot/
grub> linux (ieee1275/disk,gpt2)/boot/<kernel-image> root=UUID=<your-root-uuid> rw
grub> initrd (ieee1275/disk,gpt2)/boot/<initramfs-image>
grub> boot

Or, to test whether grub.cfg itself is reachable/valid without going through the full normal auto-boot flow:

grub> set root=(ieee1275/disk,gpt2)
grub> configfile (ieee1275/disk,gpt2)/boot/grub/grub.cfg

Summary: key facts at a glance

Concern	Chimera Linux
Package manager	apk
Bootstrap tool	chimera-bootstrap -l <target>
Chroot tool	chimera-chroot <target> (auto-mounts /dev, /proc, /sys)
Kernel package	linux-lts / linux-stable
GRUB package	grub-powerpc-ieee1275
Bootloader install	grub-install /dev/vda1 (PReP partition directly, no extra flags)
Regenerate GRUB config	update-grub
Regenerate initramfs	update-initramfs -c -k all
Enable a service	dinitctl enable <svc> (running system) / manual symlink into /etc/dinit.d/boot.d (chroot)
Service files	separate -dinit subpackages (e.g. openssh-dinit, dhcpcd-dinit) — install alongside the main package
Privilege escalation	doas — permit persist :wheel in /etc/doas.conf
Network client	dhcpcd, configured via /etc/dhcpcd.conf

If you hit anything beyond what's flagged as unconfirmed above, it's worth folding back into this doc.