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:
beebe@math.utah.edu - - 155 S 1400 E RM 233
beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)