Dunfell hddimg support

What happened to hddimg support in Dunfell? I used this image to boot off a USB drive and install onto my target’s SSD - grub would show an “install” option that will then write to MENDER_STORAGE_DEVICE (/dev/sda in my system). In Zeus, it was built along with uefiimg. This post seems to imply it was rolled into uefiimg and so I should write the uefiimg to my USB drive. But when I boot from USB, I don’t get a grub select screen, just “Welcome to GRUB! lock: OK lock: OK” and it tries to boot from the USB. Boot of course fails because doesn’t work because MENDER_STORAGE_DEVICE is pointing to /dev/sda and the USB drive is /dev/sdb. And if I do build with MENDER_STORAGE_DEVICE = "/dev/sdb" boot fails because the USB drive is read-only for some reason?

So, maybe I can just add IMAGE_FSTYPES_append = " hddimg" to local.conf? Nope, I get this error:

$ bitbake core-image-full-cmdline
ERROR: <>/poky_trunk/meta/recipes-core/images/core-image-minimal-initramfs.bb: INITRD_IMAGE_LIVE core-image-minimal-initramfs cannot use image live, hddimg or iso.
ERROR: <>/poky_trunk/meta/recipes-core/images/core-image-minimal-initramfs.bb: Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.
ERROR: Failed to parse recipe: <>/poky_trunk/meta/recipes-core/images/core-image-minimal-initramfs.bb

My local.conf and bblayers.conf:

INHERIT += "mender-full"
MACHINE ?= "genericx86-64"
...
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""

ARTIFACTIMG_FSTYPE = "ext4"
#IMAGE_FSTYPES_append = " hddimg"

MENDER_ARTIFACT_NAME = "demo-1"

MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "<token>"

MENDER_STORAGE_DEVICE = "/dev/sdb"
MENDER_STORAGE_TOTAL_SIZE_MB = "2048"
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${TOPDIR}/../meta \
  ${TOPDIR}/../meta-poky \
  ${TOPDIR}/../meta-yocto-bsp \
  ${TOPDIR}/../meta-mender/meta-mender-core \
  ${TOPDIR}/../meta-mender/meta-mender-demo \
  "

If your jumping between USB and internal drives, you may want to take a look at using PARTUUIDS as your partition references to make life easier.

https://docs.mender.io/system-updates-yocto-project/image-customization/features

Hi @skrawn that other post was misleading. When I said that HDDIMG included the UEFIIMG, what I meant was that the UEFIIMG file was stored inside the HDDIMG and the the installer from the HDDIMG would write the UEFIIMG to the hard drive. If you are trying to do that you still need the hddimg. I guess you’ll need to troubleshoot that error you posted. Evidently something changed, likely in poky, that we will need to address. Please let us know if you find anything.

Ok, thanks. I’ll give PARTUUIDs a try quickly and if that doesn’t work for me, I’ll investigate the problem with hddimg and let you know what I find.

@drewmoseley you’re right, it was in poky. This is it: poky - Poky Build Tool and Metadata

Thoughts about the least invasive way to fix this?

But you already tried manually adding hddimg to IMAGE_FSTYPES right? There must be more to it.

I don’t see any obvious changes in poky that would cause this.

What does bitbake -e core-image-minimal | grep -B100 '^(IMAGE_BASENAME|INITRD_IMAGE_LIVE)=' show in your older branch where you don’t see this issue?

Drew

But you already tried manually adding hddimg to IMAGE_FSTYPES right? There must be more to it.

Right, but the change in Poky is setting that way down in the x86-base.inc. I don’t pretend to know all the in-and-outs of how Bitbake establishes dependencies, but it is doing something that makes core-image-minimal-initramfs happy.

This change does have an impact to IMAGE_FSTYPES though:
Before (current poky):

IMAGE_FSTYPES="wic wic wic.bmap  mender mender.bmap    uefiimg uefiimg.bmap   uefiimg.bz2 "

After (undo-ing that patch):

IMAGE_FSTYPES="hddimg wic wic.bmap  mender mender.bmap    uefiimg uefiimg.bmap   uefiimg.bz2 "

What does bitbake -e core-image-minimal | grep -B100 '^(IMAGE_BASENAME|INITRD_IMAGE_LIVE)=' show in your older branch where you don’t see this issue?

I don’t know why that regex isn’t working…

$ bitbake -e core-image-minimal | grep '^INITRD_IMAGE_LIVE' 
INITRD_IMAGE_LIVE="core-image-minimal-initramfs"
$ bitbake -e core-image-minimal | grep '^IMAGE_BASENAME' 
IMAGE_BASENAME="core-image-minimal"

Also my “older” branch is just the mender-community meta-mender-intel project: https://github.com/mendersoftware/meta-mender-community/tree/zeus/meta-mender-intel

I can’t say I understand why but I was able to build an hddimg file using:

IMAGE_INSTALL += " hddimg "

rather than

IMAGE_INSTALL_append = " hddimg "

Give that a shot and let us know if it builds and if the integrated install stuff still functions.

Drew

Yup, sure enough IMAGE_INSTALL += " hddimg" works.

I’m sorry, I spoke too soon. While the error does go away, the hddimg isn’t actually being created. I thought it was but that was from a previous build.

That’s strange. In my case it definitely did get created. What happens if you rm -rf build/tmp and let it all get recreated?

Drew

Same effect; missing the hddimg still.

Strange. I just built both intel-corei7-64 and qemux86-64 and have HDDIMG files in both cases. What MACHINE are you building?

What does bitbake -e core-image-full-cmdline | grep 'IMAGE_FSTYPES=' show?

genericx86-64

$ bitbake -e core-image-full-cmdline | grep 'IMAGE_FSTYPES='
IMAGE_FSTYPES="wic wic wic.bmap  mender mender.bmap    uefiimg uefiimg.bmap   uefiimg.bz2 "

@drewmoseley I blindly followed your post the other day about IMAGE_INSTALL += " hddimg" when I think you meant to type IMAGE_FSTYPES += " hddimg" because that does work!

Dang. Sorry about that. Clearly, that was a mistake in my previous post. Glad you have it building. Let me know if it is functional.

It is; just booted off the USB drive and installed my image. Thank you!