Just as a reference, this is where I am right now:
1. I've asked porter box access since that seems the most straightforward way to
test this riscv64 issue before pushing changes to salsa.
Getting that access takes time.
In the meantime...
2. I tried using autopkgtest-build-qemu, which fails on vmdb2 not
recognizing riscv64:
~ » sudo autopkgtest-build-qemu --architecture=riscv64
--mirror=http://deb.debian.org/debian unstable
/home/pieter/src/deb/qemu-img-unstable-riscv64.img
2026-04-03 08:23:48 ERROR GRUB UEFI package and target for "riscv64" unknown
Traceback (most recent call last): File
"/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 121, in
grub_uefi_variant
return variants[state.arch] ~~~~~~~~^^^^^^^^^^^^
KeyError: 'riscv64'
~ » grep -n -A 10 'variants' /usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py
113: variants = {
114- "amd64": ("grub-efi-amd64", "x86_64-efi"),
115- "i386": ("grub-efi-ia32", "i386-efi"),
116- "arm64": ("grub-efi-arm64", "arm64-efi"),
117- "armhf": ("grub-efi-arm", "arm-efi"),
118- }
119- logging.debug(f"grub plugin: state.arch={state.arch!r}")
120- try:
121: return variants[state.arch]
122- except KeyError:
123- raise Exception(
124- 'GRUB UEFI package and target for "{}" unknown'.format(state.arch)
125- )
126-
127- def install_uefi(self, values, settings, state):
128- efi = values["efi"] or None
129- efi_part = values["efi-part"] or None
130- if efi is None and efi_part is None:
131- raise Exception('"efi" or "efi-part" required in UEFI GRUB installation')
--
144: variants = {
145- "amd64": "i386",
146- "ppc64": "powerpc",
147- "ppc64el": "powerpc",
148- "sparc": "sparc64",
149- }
150- logging.debug(f"grub plugin: state.arch={state.arch!r}")
151: return variants.get(state.arch, state.arch)
152-
153- def install_ieee1275(self, values, settings, state):
154- vmdb.progress("Installing GRUB for IEEE1275")
155- grub_package = "grub-ieee1275"
156- grub_target = f"{self.grub_ieee1275_variant(state)}-ieee1275"
157- self.install_grub(values, settings, state, grub_package, grub_target)
158-
159- def install_grub(self, values, settings, state, grub_package, grub_target):
160- console = values["console"] or None
161-
I'm not going to try and mess with that by just adding the right key, which
would probably be 'riscv64': ('grub-efi-riscv64', 'riscv64-efi', ...),
3. I'm used https://people.debian.org/~gio/dqib/
I was able to boot the image using the line in the riscv64 image readme, except
I had to drop the -bios flag to get around this error:
~/src/deb/dqib_riscv64-virt » qemu-system-riscv64 -machine 'virt' -cpu 'rv64'
-m 1G -device virtio-blk-device,drive=hd -drive file=image.qcow2,if=none,id=hd
-device virtio-net-device,netdev=net -netdev
user,id=net,hostfwd=tcp:127.0.0.1:2222-:22 -bios
/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel
/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object
rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng
-nographic -append "root=LABEL=rootfs console=ttyS0" qemu-system-riscv64: Some
ROM regions are overlapping These ROM regions might have been loaded by direct
user request or by default. They could be BIOS/firmware images, a guest
kernel, initrd or some other file loaded into guest memory. Check whether you
intended to load all this guest code, and whether it has been built to load to
the correct addresses. The following two regions overlap (in the memory
address space): /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf ELF
program header segment 1 (addresses 0x0000000000000000 - 0x0000000000034b10)
mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
Without the -bios flag, the image boots, apt update and apt upgrade work.
I was able to confirm that the default tolerance works, so defining the custom
tolerance is superfluous, as suggested by hpages in
https://github.com/Bioconductor/S4Vectors/pull/133#issuecomment-4150964996
Next I've submitted an updated patch upstream and have update our patch.