This is a report of failures, and ultimate success, in installing Debian HPPA with the QEMU emulation of that CPU architecture.
I run a large farm of more than 500 physical and virtual machines that we use for software testing and development. The VMs include numerous O/Ses and CPU types: AMD64 (x86_64), ARM32, ARM64, Alpha, M68K, MIPS32, MIPS64, PowerPC, RISC-V64, S390x, SPARC, and x86. Most of those are emulated by QEMU running on CentOS 7 and Ubuntu 20.04 on Intel Xeon hardware. The major historical CPU family with IEEE 754 floating-point arithmetic missing from that list is Hewlett-Packard's Precision Architecture RISC, PA-RISC, also called HPPA. In the 1990s, we had several physical workstations and servers of that type, but all have long since been retired and disposed of. Neither of our other virtualization systems, OVirt and VirtualBox, supports emulation of other CPU types. With VirtManager and QEMU, however, there are numerous CPU types available. Regrettably, for many of them, it is necessary to discard the easy-to-use VirtManager GUI, and resort to low-level qemu-system-xxx command lines, and that is the case for Alpha, HPPA, M68K, and SPARC. One of the projects that I work on is ensuring that the annual TeX Live releases can be built on a wide range of platforms. This year's report is at http://www.math.utah.edu/pub/texlive-utah/ I had previously tried to install Debian 4, 5, 9, and 10 releases for HPPA, but each time, I failed: either QEMU complained of missing firmware, or the VM would not boot, or it would boot, but I could not get a working network. In June 2021, I retried with a .qcow2 disk image converted from -rw-rw-r-- 1 511504481 May 9 2018 debian-10-hdd-img.tar.bz2 That disk image is far too small for my needs, but I was able to to extend the partition size like this: qemu-img convert -O qcow2 debian-10-hdd.img debian-10-hdd.qcow2 qemu-img resize debian-10-hdd.qcow2 +55G That gets a bigger partition, but further work is needed after a boot from an ISO image: fdisk /dev/sda [delete second partition, then recreate with maximum size] reboot Unfortunately, the disk image it has no C/C++ compilers, and other tools that I need, (e.g., starting with the build-essential one) but we found that it is sufficiently old that it is impossible to run "apt update" and "apt install" commands: there are far too many unresolved dependencies. It would be good to get that .img file replaced by a current one that could be used directly, and that had important packages needed for software development already installed, including build-essential, gfortran, m4, and compilers for Go and Rust. This month, I tried an install from the more recent ISO image -r--r--r-- 1 263258112 Jun 8 16:14 debian-10.0.0-hppa-NETINST-1.iso With the native version 4.2.0 qemu-system-hppa on Ubuntu 20.04 LTS, the installer boot died with [ 51.098263] [<101e7684>] do_group_exit+0x54/0xf0 [ 51.098263] [<101f76a4>] get_signal+0x1b0/0xac8 [ 51.098263] [<101c5b34>] do_signal+0x4c/0x56c [ 51.098263] [<101c609c>] do_notify_resume+0x48/0xfc [ 51.098263] [<101b70a8>] intr_check_sig+0x34/0x38 [ 51.098263] [ 51.098263] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a ]--- I have built several later versions of QEMU from source, but with them, the installer runs for some time, then dies with a terminal screen that looks like this: [ (1*installer) 2 shell 3 shell 4- log ][ Aug 07 0:00 ] .... blank screen ... [ 1489.609145] _______________________________ [ 1489.609145] < Your System ate a SPARC! Gah! > [ 1489.609145] ------------------------------- [ 1489.609145] \ ^__^ [ 1489.609145] (__)\ )\/\ [ 1489.609145] U ||----w | [ 1489.609145] || || [ 1489.613720] ip (pid 2962): Illegal instruction (code 8) [ 1489.614573] CPU: 0 PID: 2962 Comm: ip Tainted: G E 5.10.0-6-parisc #1 Debian 5. [ 1489.694519] ---[ end trace 49060643616260b7 ]---844cx2744 E 5.10.0-6-parisc #1 Debian 5. For the record, here is the emulator command: $QEMUDIR/qemu-system-hppa \ -m 3G \ -drive file=debian-10e-hdd.qcow2 \ -drive file=debian-10.0.0-hppa-NETINST-1.iso,media=cdrom \ -boot order=d \ -nographic \ -serial mon:stdio I ran an xterm log of those attempts, and found that the "Your System ate a SPARC! Gah!" message appears just after the output Detecting network hardware That suggested that changing from the default TULIP network device might be worth trying. The devices supported by qemu-system-hppa are e1000 i82559c e1000-82544gc i82559er e1000-82545em i82562 i82550 i82801 i82551 ne2k_pci i82557a pcnet i82557b rtl8139 i82557c tulip i82558a virtio-net-pci i82558b virtio-net-pci-non-transitional i82559a virtio-net-pci-transitional i82559b vmxnet3 Of those, the Intel e1000 is one that is commonly supported on most operating systems. I therefore changed the startup command to $QEMUDIR/qemu-system-hppa \ -m 3G \ -drive file=debian-10e-hdd.qcow2 \ -drive file=debian-10.0.0-hppa-NETINST-1.iso,media=cdrom \ -boot order=d \ -nographic \ -serial mon:stdio \ -net nic,model=e1000,netdev=net0 \ -netdev user,\ id=net0,\ net=192.168.123.0/24,\ restrict=off,\ ipv6=off,\ hostfwd=tcp::12222-192.168.123.122:22 and that led to a successful boot of the installer, which ran to completion, but took more than 10 hours to do so. In my recent experiments, I have used QEMU versions 6.0.0, 6.1.0-rc0, 6.1.0-rc2, and 6.1.0-rc3. Although the ISO image is labeled as Debian version 10, the actual version reported in /etc/debian_version is 11.0. I can now boot the .qcow2 image directly with a similar command $QEMUDIR/qemu-system-hppa \ -m 3G \ -smp cpus=4 \ -drive file=debian-10e-hdd.qcow2 \ -boot order=c \ -nographic \ -serial mon:stdio \ -net nic,model=e1000,netdev=net0 \ -netdev user,\ id=net0,\ net=192.168.123.0/24,\ restrict=off,\ ipv6=off,\ hostfwd=tcp::12222-192.168.123.122:22 where the -drive line for the ISO image is removed, and the boot device is changed from d to c. My local practice is that VMs reside on the private network 192.168.123.0/24, and the last octet for a particular VM prefixes the standard secure shell port number, 22: thus, I have port 12222 when the last octet is 122. The network used by QEMU, and its DHCP range, is determined by this block in /etc/libvirt/qemu/networks/default.xml: <network> <name>default</name> <uuid>740f7e29-7ab4-4130-9316-d2e216fa707b</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:7c:1e:ae'/> <ip address='192.168.123.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.123.241' end='192.168.123.254'/> </dhcp> </ip> </network> I can now connect to the VM with ssh -p 12222 localhost and have since been able to fully configure it with user accounts and installations of scores of packages. So far, it appears to run stably. There is, however, a serious performance issue that I will discuss in a subsequent posting to this list. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------