Comment 3 for bug 1980519

I'm a bit concerned that we're squashing an error case that seems legitimate to me? There's several cases of "dummy" entries in flash-kernel's all.db for QEMU instances under various architectures. For example:

  https://git.launchpad.net/ubuntu/+source/flash-kernel/tree/db/all.db#n407
  ## qemu instance on armhf
  Machine: Dummy Virtual Machine

  https://git.launchpad.net/ubuntu/+source/flash-kernel/tree/db/all.db#n983
  ## qemu instance on arm64
  Machine: linux,dummy-virt

I'd be happy to add one of these for the QEMU RISC-V machine (which, from our mm conversation would be "Machine: riscv-virtio,qemu".

However, to change "functions" so that, in the case flash-kernel doesn't recognize the machine type, it stops but *doesn't* stop apt upgrade seems too invasive to me. It is indeed serious that flash-kernel breaks apt upgrade in this case, but it seems justified to me: the new kernel and initrd will be installed in the boot directory by this point, and the kernel (or initramfs-tools) packaging will have triggered flash-kernel with the expectation it flashes the new kernel+initrd(+bootloader machinery) to wherever it needs to be for this particular board. If flash-kernel *can't* do that (because it doesn't recognize the board), is that not legitimate grounds to stop apt so the user knows they're in a pretty serious situation?

To put it another way, I'd be happy to sponsor a change adding a dummy entry to all.db (I'm also happy to just add that diff myself and push it right away), but I'm concerned that the proposed diff affects more than just QEMU RISC-V instances, and does so in ways that change error behaviour in situations which seem like they should remain error situations to me.