Finally got mender-convert to run against the full image I captured. It produced .cfg, .ext4, .img and .mender. Can’t apply .mender because device is not mender converted. Don’t know what .cfg and .ext4 are for and when I apply the .img it runs out of space and fails. Why does it produce an image that takes up more space than the drive it’s converting contains? I don’t understand why mender-convert outputs an artifact file when it applies to an image of a device that can’t install an artifact. Any assistance anyone can provide would be greatly appreciated.
Regards,
Keith
Update: MENDER_STORAGE_TOTAL_SIZE_MB=250000 for 250gb drive. changed to 230000. Fits now but when booting
Gave up waiting for suspend/resume device
Gave up wating for root file system device. Common Problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough)?
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/nvme0n12 does not exist. Dropping to a shell!
It seems mender-convert has not laid out the drive partitions correctly.
BusyBox v1.35.0 (Debian 1:1.35.0-4+b4) build-in shell (ash)
Enter ‘help’ for a list of build-in commands.
(initramfs) & flashing cursor.
Did some digging with AI and found settings to try in config file and rebuilt.
BOOT_DEVICE=“/dev/nvme0n1p1”
ROOTFS_PART_A=“/dev/nvme0n1p2”
ROOTFS_PART_B=“/dev/nvme0n1p3”
DATA_PART=“/dev/nvme0n1p4”
Hopeful but no luck so took them back out and also removed:
MENDER_STORAGE_DEVICE_BASE=/dev/nvme0n1
Now error is: /dev/mmcblk0p2 does not exist.
Latest: Removed config file completely
2025-08-20 14:47:43 [WARN] [mender-convert-package] The calculated rootfs partition size 3760 MiB is too small.
2025-08-20 14:47:43 [WARN] [mender-convert-package] The actual rootfs image size is 9232 MiB
2025-08-20 14:47:43 [FATAL] [mender-convert-package] You can try adjusting the MENDER_STORAGE_TOTAL_SIZE_MB variable to increase available space, or modify one of the variables IMAGE_ROOTFS_SIZE, IMAGE_ROOTFS_EXTRA_SPACE or IMAGE_OVERHEAD_FACTOR to reduce the size of the root filesystem. So… added config file with only IMAGE_ROOTFS_EXTRA_SPACE=20480 sudo No luck so, replaced extra var with total_size var. Built, applied and /dev/mmcblk0p2 does not exist. Next add config file back and change storage base var appending p ie. nvme0n1p
Appending the “p” seems to have fixed that issue. Now, checksums failing on blocks 1,2 and 7. Can’t execute /bin/init & /bin/sh.
Fixed finally. Had to reinstall debian on the client then capture that image, convert that then everything fell into place as expected. With all the install client links in the main docs page for mender and a little misguided assistance from AI, somehow I got the idea that the client needed to be installed before the base image capture and that just reeked havoc! With the clean base and the few config tweaks, everything just fell into place!
Hi @hackenstein,
Just now found time to follow up on this. Interesting, really the first time Mender Hub essentially served as rubberducking and an AI tool solved it 
On a side note, if the resulting configuration does not yield any confidential information and relates to a publicly obtainable board, it would be helpful for others if you could share it here - possibly sanitized, of course.
Greetz,
Josef
Think you may have misread my post. AI caused my grief!