Mender convert fails during grub install

Board Integrations Debian family
1

I’m hitting the following error when executing docker-mender-convert on a debian image on a ubuntu 20.04:

2022-09-28 10:11:46 [INFO] [mender-convert-modify] Not installing GRUB EFI bootloader, relying on platform provided one.
2022-09-28 10:11:46 [INFO] [mender-convert-modify] Installing Mender GRUB tools...
2022-09-28 10:11:46 [INFO] [mender-convert-modify] Installing the GRUB editenv binary
2022-09-28 10:11:47 [INFO] [mender-convert-modify] Generating grub config using update-grub...
mender-convert-modify has finished. Cleaning up...
2022-09-28 10:11:49 [ERROR] [mender-convert] mender-convert failed
2022-09-28 10:11:49 [DEBUG] [mender-convert-modify] When running: (modules/grub.sh:114): run_and_log_cmd_noexit():  

	sudo chroot work/rootfs grub-install --removable --no-nvram
	Disabling OS prober in offline mode...
Cannot probe device in command line: --target=fs_uuid --device /dev/sda3
grub-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.

2022-09-28 10:11:49 [ERROR] [mender-convert] mender-convert failed
2022-09-28 10:11:49 [ERROR] [mender-convert] mender-convert exit code: 1

This happens on some bare metal ubuntu 20.04 machines (but not all) and on ubuntu 20.04 VMs. In all cases the same input image and config was used.

    MENDER_ARTIFACT_NAME=release-1 \
        ./docker-mender-convert --disk-image "input/Debian-11-x86-64.img" \
        --config configs/debian-qemux86-64_config \
        --overlay input/rootfs_overlay_demo/

Any ideas about what is going wrong here and why this would depend on the host machine?

2

Hmm, that’s odd, it chooses the i386 BIOS variant. This is a x86_64 image, right?

Can you try to add --target=x86_64-efi to the line in grub.sh that it mentions? There is a line right below it which is very similar; you should add it there too.

Don’t forget to run ./docker-build afterwards to rebuild the mender-convert Docker image before trying to convert again.

3

Thank you. The workaround works for me. What would be the best way to get this properly fixed upstream in mender-convert?

4

I suspect that the difference between working image build host systems and failing systems is that the failing systems (both bare metal and VM) were all legacy bios booted with grub and the working systems were booted through efi and grub. This difference may be visible inside the mender-convert container through the bind mount /dev and /sys as well. But that’s all just a guess so far.

Edit: grub-install seems to look for /sys/firmware/efi/vars/ for example.

5

I can take care of that. Thanks for confirming!

6

Hello kacf,
I see the same issue on a Debian 10 VM with legacy BIOS.
Will there be a fix short-term or would it make sense to use the suggested workaround for now?

Best regards,
Kai

7

You can try the workaround, but if the target is using legacy BIOS, I don’t think mender-convert will work at all. It only supports UEFI.

I have not yet applied the fix above to our source code, but it’s on my TODO! :slightly_smiling_face:

1 Like
8

There is a task to get this fixed now: [MEN-5979] Fix mender-convert grub.d integration when host and target 32/64-bit architectures don't match - Northern.tech AS