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.
signature.asc
Description: PGP signature
