Testdriving NetBSD-11.0RC2 on ARM hardware (in VM!)
After some (mostly ongoing) absence from NetBSD, and
with NetBSD 11.0RC2 recently announced, I wanted to give it a try.
I have moved to a ARM-based Apple machine, and thus x86 / amd64
was not the way to go. Instead, I wanted to see how NetBSD works
on ARM these days. Here's how I got it going!
1st try: VirtualBox
NetBSD does not come with a VirtualBox image in 2026, so my workaround
was to convert the provided .img file and convert it to a disk image
file in VDI format.
Download:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0_RC2/evbarm-aarch64/binary/gzimg/arm64.img.gz
Convert img to VDI:
qemu-img convert -f raw -O vdi arm64.img arm64.vdi
Setup VirtualBox VM with .vdi file as existing harddisk.
Result: VirtualBox (not the VM!) crashed. Oh well.
2nd try: QEMU
After VirtualBox didn't work, I wanted to see if qemu (running on MacOS)
works. Spoiler: it does, and here are the steps to get things going:
First, grab the kernel:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0_RC2/evbarm-aarch64/binary/kernel/netbsd-GENERIC64.img.gz
...and gunzip. Make sure kernel and userland versions match!
Run in QEMU:
qemu-system-aarch64 -M virt,accel=hvf -cpu host -smp 4 \
-m 4g -drive if=none,format=raw,file=arm64.img,id=hd0 \
-device virtio-blk-device,drive=hd0 -netdev user,id=net0 \
-device virtio-net-device,netdev=net0 -kernel netbsd-GENERIC64.img \
-append root=dk1 -nographic
How to leave QEMU: Ctrl-A X
Troubleshooting: Make sure kernel and userland match - else random segfaults will happen.
Userland setup
Quite a few settings are already OK (sshd, dhcpcd, ntp),
which is not the default I remember from a few years ago, but
that's nice and convenient. I still wanted to see what config
settings are new, and here are my additions to /etc/rc.conf:
hostname="qnetbsd"
rndctl=yes
certctl_init=yes
ip6mode=autohost
ntpdate=NO
On first login you will see an unsafe keys warning:
-- UNSAFE KEYS WARNING:
The ssh host keys on this machine have been generated with
not enough entropy configured, so they may be predictable.
To fix, follow the "Adding entropy" section in the entropy(7)
man page. After this machine has enough entropy, re-generate
the ssh host keys by running:
/etc/rc.d/sshd keyregen
Fix by feeding entropy, then reboot:
echo lkajsdflkjasdflkjasdlkfjoiasjdfiojasdkf >/dev/random
shutdown -r now
Note: Use shutdown(8), not reboot(8) or poweroff(8) - only shutdown runs the hooks that save entropy.
After reboot, regenerate SSH keys:
/etc/rc.d/sshd keyregen
Success
neuland% qemu-system-aarch64 -M virt,accel=hvf -cpu host -smp 4 -m 4g \
-drive if=none,format=raw,file=arm64.img,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-netdev user,id=net0 -device virtio-net-device,netdev=net0 \
-kernel netbsd-GENERIC64.img -append root=dk1 -nographic
[ 1.0000000] NetBSD/evbarm (fdt) booting ...
[ 1.0000000] NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026
...
NetBSD/evbarm (qnetbsd) (constty)
login: root
NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026
Welcome to NetBSD!
qnetbsd# uname -a
NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar 4 21:02:00 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm
Summary
Not providing a working VirtualBox image in 2026 is painful for new users.
As Kali Linux works fine in VirtualBox on the same hardware, I'd say
there is some way to go, NetBSD!
The manual setup works, but needs some tweaks beyond the expected (/etc/rc.conf), exp. manual entropy setup was surprising as
network and disk were working ok. I did expect those to be used as
sources of randomness before the first SSH keys are generated.
We'll see where things go from there. For now I can (at least for QEMU on my Mac) say: Of course it runs NetBSD! :-)
[Tags: arm, mac, qemu, rc2]
|
