X86_64 system showing grub prompt after debian image conversion


I am trying to setup a system with debian on x86_64 system.

After following the steps for conversion, I get showed the grub prompt, but still can boot the system manually.

What is wrong. I would like the system to boot debian automatically, as usual.

Here are the steps I followed.

  • Install debian on the system
  • Export part of the disk image including both efi and root partitions as suggested in mender-convert configs/generic_x86-64_hdd_config.
  • Fix the GPT.
  • Run conversion successfully
  • Flash the system back with the converted image.
  • Fix the GPT once again (sgdisk -e /dev/sda)

Now, I get the following file tree in the efi partition:

β”œβ”€β”€ config-4.19.0-16-amd64
β”œβ”€β”€ efi
β”‚   └── EFI
β”‚       β”œβ”€β”€ BOOT
β”‚       β”‚   β”œβ”€β”€ bootx64.efi
β”‚       β”‚   β”œβ”€β”€ grub.cfg
β”‚       β”‚   β”œβ”€β”€ mender_grubenv1
β”‚       β”‚   β”‚   β”œβ”€β”€ env
β”‚       β”‚   β”‚   β”œβ”€β”€ lock
β”‚       β”‚   β”‚   └── lock.sha256sum
β”‚       β”‚   └── mender_grubenv2
β”‚       β”‚       β”œβ”€β”€ env
β”‚       β”‚       β”œβ”€β”€ lock
β”‚       β”‚       └── lock.sha256sum
β”‚       └── debian
β”‚           β”œβ”€β”€ BOOTX64.CSV
β”‚           β”œβ”€β”€ fbx64.efi
β”‚           β”œβ”€β”€ grub.cfg
β”‚           β”œβ”€β”€ grubx64.efi
β”‚           β”œβ”€β”€ mmx64.efi
β”‚           └── shimx64.efi
β”œβ”€β”€ grub
β”‚   β”œβ”€β”€ fonts
β”‚   β”‚   └── unicode.pf2
β”‚   β”œβ”€β”€ grub.cfg
β”‚   β”œβ”€β”€ grubenv
β”‚   β”œβ”€β”€ locale
β”‚   β”‚   β”œβ”€β”€ ast.mo
β”‚   β”‚   β”œβ”€β”€ ca.mo
β”‚   β”‚   β”œβ”€β”€ da.mo
β”‚   β”œβ”€β”€ unicode.pf2
β”‚   └── x86_64-efi
β”‚       β”œβ”€β”€ acpi.mod
β”‚       β”œβ”€β”€ adler32.mod
β”‚       β”œβ”€β”€ affs.mod
β”œβ”€β”€ initrd -> initrd.img-4.19.0-16-amd64
β”œβ”€β”€ initrd.img-4.19.0-16-amd64
β”œβ”€β”€ kernel -> vmlinuz-4.19.0-16-amd64
β”œβ”€β”€ System.map-4.19.0-16-amd64
└── vmlinuz-4.19.0-16-amd64

Thanks for you help,

How are you able to boot manually? I’m having difficulty following the steps here.

Why do you need to fix the GPT?

If you export the entire disk image does it behave the same?


same problem here. I converted Debian Buster, with mender-convert 2.4.
For me it looks like the EFI is using grub.cfg in folder β€œdebian”, but the right one is grub.cfg in folder /efi/EFI/BOOT/
If I reached grub prompt, I manually changed to the right grub.cfg by typing
configfile /efi/boot/grub.cfg
The System tries to start, but it cant. "error: can’t find command β€œhashsum”.
If I edit the grub.cfg and comment out the functioncall β€œfunction mender_check_and_restore_env”, the system is starting up. But mender is not working how it should.

For fun I copied the content from /efi/EFI/BOOT to /efi/EFI/debian (overwrite existing in debian) and changed the one functioncall in grub.cfg. The system is starting up, every time I like to start, but without changing partition after successfull update.
For me it sounds like the same problem, that’s yours. I’m glad if someone can help.

Sorry for my bad english and thank’s a lot,

I boot manually to the first rootfs partition

linux (hd0,2)/boot/vmlinuz-4.19.0-16-amd64 root=/dev/sda2
initrd (hd0,2)/boot/initrd.img-4.19.0-16-amd64

I did fix the GPT 1) bacause I only copied a part of my voluminous hard drive. This is what is also suggested in mender-convert repo, file counfigs/generic_x86-64_hdd_config (for the other partition not copied (swap?) and for the backup gpt table at the end of the disk not being copied either, I guess).

I also tried with an image installed on a small usb drive, exporting the entire disk, without the need to fix GPT, and I got the same result after converting the disk image.

We might be facing the same issue.

For my part, the following command configfile (hd0,1)/efi/boot/grub.cfg prints a few lines that I don’t have the time to read, and then the system shuts down.

Doing the same but with (hd0,1)/efi/debian/grub.cfg simply resets the grub command line interface.

I hope someone can help. I would like to see if mender is a good solution for the project I work on.

I made a photo from the lines

Yeah, those lines look like what I get after the command configfile (hd0,1)/efi/boot/grub.cfg.

It seems your grub configuration is missing the hashsum command.

@oleorhagen does the generic_x86-64_hdd_config use a custom-built GRUB or the one provided by the distro?

@francoislefebvre @daniel1 which distro are you using? It’s possible that you will need a custom grub binary if the one provided by your distro does not have all the require configs enabled.


@drewmoseley I’m fairly sure it is using a custom built GRUB

@drewmoseley I use Debian 10, as do @daniel1 .

So what would be the next things to do?

Sorry for the late reply, I was on vacation.

You’ll need to try and figure out where the Grub image you are using is coming from. You may need to modify it to add the missing hashsum config. I’m not familiar enough with Grub to say how to do that but I don’t imagine it’s terribly difficult.

I just created a minimal Debian 10 image using mkosi and did not have any issues booting it after conversion. I only booted it with QEMU but it did successfully launch. I wonder if it’s related to your specific hardware or your image?


1 Like

Now it’s working…
I forgot sgdisk -e /dev/sda
But this was not the only one reason, why I had this problems…
The BIOS of my Hardware (I tested with Lenovo ThinkStation) is not supporting all features, I need. I changed the hardware and now It’s working.
Thank you for all your help

For my part, I switched to the suggested method using mkosi and it works. It also ease the development process. Thanks for the tip @drewmoseley .