I have been playing with a virtual machine running Archlinux on QEMU/KVM

Everything was fine for several days then I added a new disk to the VM to increase its capacity.

I am not sure exactly what happened but now when I try to start my virtual machine, I get an error in grub

error: no signature

I have no idea where to start. Would appreciate any help you could give me to troubleshoot the issue.

Update Could this issue be a QEMU/KVM bug or something? Because, I can navigate to my own grub menu and boot up fine if I use the live-usb.

  • Used install usb
  • When presented with the boot menu, I chose UEFI Firmware Settings
  • Chose Boot Manager
  • Chose Grub
  • That got me to my own grub menu
  • System booted fine
  • I added a new disk to the VM to increase its capacity can you describe the process you went through to do this - I ask this because I've never "added a new disk" to a VM, I've only ever expanded the VM's existing disk in the host (I usually use LVM or a qcow file for VM storage) Aug 20, 2023 at 4:24
  • My guess would be to check if secure boot is enabled and disable it enabled. If that doesn't work you might want to reinstall grub
    – Bog
    Aug 22, 2023 at 14:15

1 Answer 1


After searching through GRUB source code, the error text "no signature" only ever appears with the error GRUB_ERR_BAD_PART_TABLE, i.e. GRUB is not seeing a valid partition table on the disk it's supposed to boot from. Secure Boot is not involved here.

I would guess that the new disk you added to the VM ended up being located before the disk you were originally booting from in the detection order of the VM firmware, and now GRUB (or possibly the system firmware?) is looking at the wrong disk.

Since you got the VM to boot successfully by using the UEFI firmware Boot Manager menu, the next step in troubleshooting should probably be to run efibootmgr -v in the VM, see what the BootCurrent value is and which BootXXXX boot variable it refers to.

Is the BootCurrent value the same as the first value in the BootOrder variable?

  • If it is, this might be a VM firmware bug or something unexpected (self-healing system???)

  • If not, what is the difference between those two boot options? In other words, if BootCurrent is XXXX and the first value of BootOrder is YYYY, what is the difference between BootXXXX and BootYYYY boot variables?

If the BootXXXX variable indicated by BootCurrent seems valid, you might fix the problem simply by placing XXXX as the first item in BootOrder:

efibootmgr -o XXXX,<other BootOrder values, if any>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .