Error: Fetching Artifact headers failed: installer: failed to read Artifact: type_info provides values not yet supported

[gswebspace]

Hi,

I am facing a issue while updating my RaspberryPi 3 device. This is from the deployment log -

{“level”:“error”,“message”:“Fetching Artifact headers failed: installer: failed to read Artifact: type_info provides values not yet supported”,“timestamp”:“2020-11-03T21:34:03+05:30”}

The device is a RPi3B running mender client version 2.1.0 with image built using mender-convert earlier.
Tried upgrading to a new image (from a golden image based on Raspberry Pi OS Buster 2020-05-27) built with mender-convert (branch 2.2.0) with default steps mentioned here.

Steps followed -

RAW_DISK_IMAGE="<value1>"
ARTIFACT_NAME="<value2>"
TENANT_TOKEN="<value3>"

./scripts/bootstrap-rootfs-overlay-hosted-server.sh \
    --output-dir ${PWD}/rootfs_overlay_demo \
    --tenant-token $TENANT_TOKEN
    
MENDER_ARTIFACT_NAME=$ARTIFACT_NAME ./docker-mender-convert \
    --disk-image $RAW_DISK_IMAGE \
    --config configs/raspberrypi3_config \
    --overlay ./rootfs_overlay_demo

As @kacf mentioned in a similar thread, the flag -no-checksum-provide for mender-artifact tool can help.

But is there a way to specify the -no-checksum-provide flag via mender-convert ? (as I am not using Yocto)
or essentially a way to resolve the above error while using mender-convert ?

Thanks in advance!

[drewmoseley]

Hi @gswebspace you can add additional parameters using a function override hook.

HTH,
Drew

[gswebspace]

Thanks for the link @drewmoseley, that helped !
I created a custom_config file with the --no-checksum-provide flag added -

mender_create_artifact() {
  local -r device_type="${1}"
  local -r artifact_name="${2}"
  local -r image_name="${3}"

  mender_artifact=deploy/${image_name}.mender
  log_info "Writing Mender artifact to: ${mender_artifact}"
  log_info "This can take up to 20 minutes depending on which compression method is used"

  run_and_log_cmd "mender-artifact --compression ${MENDER_ARTIFACT_COMPRESSION} \
      write rootfs-image \
      --file work/rootfs.img \
      --output-path ${mender_artifact} \
      --artifact-name ${artifact_name} \
      --device-type ${device_type} \
      --no-checksum-provide"
}

and ran the modified mender-convert command -

MENDER_ARTIFACT_NAME=$ARTIFACT_NAME ./docker-mender-convert \
    --disk-image $RAW_DISK_IMAGE \
    --config configs/raspberrypi3_config \
    --config configs/custom_config \
    --overlay ./rootfs_overlay_demo

But unfortunately I have now run into another issue.

The update still fails but for a different reason.
It seems to be happening post reboot. From the deployment log -

I am not sure but It seems the rootfs_overlay_demo/etc/mender/mender.conf is missing the RootfsPartA and RootfsPartB keys. Current values in rootfs_overlay_demo/etc/mender/mender.conf prepared by mender-convert -

{
  "InventoryPollIntervalSeconds": 5,
  "RetryPollIntervalSeconds": 30,
  "ServerURL": "https://hosted.mender.io/",
  "TenantToken": "<redacted>",
  "UpdatePollIntervalSeconds": 5
}

Any clues how this can be fixed ?

[gswebspace]

On further testing I found out that adding the following to rootfs_overlay_demo/etc/mender/mender.conf -

"RootfsPartA": "/dev/mmcblk0p2",
"RootfsPartB": "/dev/mmcblk0p3"

allows the update to succeed on the Rpi3.

This also seems related to the transient and persistent config split. There are instructions on how to resolve this using yocto but I can’t find steps to resolve this using mender-convert.

Also I am not sure if I should add the above lines manually to the mender.conf files in the first place.

What’s the recommended way to resolve the Dual rootfs configuration not found when resuming update error via mender-convert ?

[drewmoseley]

Hi @gswebspace I’m not sure why that would be needed. The default is to put those settings in /data/mender/mender.conf. Have you added a custom version of that file in your rootfs overlay?

[gswebspace]

@drewmoseley

Have you added a custom version of that file in your rootfs overlay?
-> Yes, I updated the generated rootfs_overlay_demo/etc/mender/mender.conf just for an experiment to check if the deployment succeeds by doing that. The error Dual rootfs configuration not found when resuming update happened when the default overlay files were used.

I understand that RootfsPartA, RootfsPartB keys should be finally present in /data/mender/mender.conf. But currently there is no mender.conf file in /data/mender. So while upgrading using mender-convert I am not sure how I add that file in /data.

Should I create a rootfs_overlay_demo/data/mender/mender.conf file ? Will that be written on the data partition while installing the artifact ?

[drewmoseley]

I’m not sure how that would happen. @mirzak any thoughts here?

[gswebspace]

ok so the problem seems to be that the conf file has been split, and the older/running image on the device does not already have the mender.conf in /data/mender. This is because that running image was created via mender-convert and deployed before split config was required.

For compatibility with future updates of mender, /data/mender/mender.conf needs to exist on the existing device.

To achieve that, I can try to create a State script for the state ArtifactInstall whose job would be to create the /data/mender/mender.conf file.
The State script can be added to the artifact via mender-convert as described here.
(For future updates, the State script will not be used)

@drewmoseley @mirzak Do you think this solution can work ? Thoughts on any additional steps that may be required?

[drewmoseley]

That sounds reasonable to me. Let us know how it goes.

Drew

[Jerry]

hi @gswebspace : did you succeed in building the state ArtifactInstal script ?
I have litterally the same problems as you and would be interested

[oleorhagen]

For the meta-mender migration we had this setup:

mendersoftware/meta-mender

Could be emulated I think

[gswebspace]

Yes creating the conf file in data partition using a state script worked nicely.

[Jerry]

For those who would be interested. Here is what i dit. All went well.

A custom mender_create_artifact function added in my custom config file :

mender_create_artifact() {
  local -r device_type="${1}"
  local -r artifact_name="${2}"
  local -r image_name="${3}"

  mender_artifact=deploy/${image_name}.mender
  log_info "Writing Mender artifact to: ${mender_artifact}"
  log_info "This can take up to 20 minutes depending on which compression method is used"

  run_and_log_cmd "mender-artifact --compression ${MENDER_ARTIFACT_COMPRESSION} \
      write rootfs-image \
      --file work/rootfs.img \
      --output-path ${mender_artifact} \
      --artifact-name ${artifact_name} \
      --device-type ${device_type} \
      --no-checksum-provide \
      --script configs/ArtifactInstall_Enter_00_add_mender_conf"
}

An ArtifactInstall script like this one :

#!/bin/sh

# move partition configuration variable to persistent partition

PARTA_LOCATION="/dev/mmcblk0p2"
PARTB_LOCATION="/dev/mmcblk0p3"
MENDER_CONF_FILE="/data/mender/mender.conf"

if test -f "$MENDER_CONF_FILE"; then
    echo "mender.conf file exists"
    ROOTFSAKEY=$(cat $MENDER_CONF_FILE | jq  '.["RootfsPartA"]')
	if [ "${ROOTFSAKEY}" != "null" ]; then
		echo "PartitionA location key exist. Everything is OK. Exiting"
		exit 0
	else
		echo "Add missing keys to existing mender.conf file"
		JSON_STRING=$( cat "$MENDER_CONF_FILE" | jq \
			--arg parta "$PARTA_LOCATION" \
			--arg partb "$PARTB_LOCATION" \
			'. + {"RootfsPartA": $parta, "RootfsPartB": $partb}' )
	fi
else
	echo "No mender.conf file. Build it"
	JSON_STRING=$( jq -n \
		--arg parta "$PARTA_LOCATION" \
		--arg partb "$PARTB_LOCATION" \
		'{"RootfsPartA": $parta, "RootfsPartB": $partb}' )
fi

echo "Write mender.conf file to /data/"
echo $JSON_STRING > "$MENDER_CONF_FILE"
sync