Mender-artifact not writing on a free space partition

  1. On an Intel NUC1, running Yocto1, I’m trying to create a full filesystem artifact using mender-artifact utility for the same Yocto1 image ( I created this image, which is 60GB, using dd off of my 2nd Intel NUC2 also running Yocto1, and then copied my image onto a separate 800 G partition mounted in Yocto-1’s rootfs). The reason for using a dd created version is to avoid the additional complication of having a read-only filesystem when doing a snapshot dump. I kept the size of the 800G partition deliberately large so that I have enough space for the artifact creation.

  2. The plan is to eventually do the same for a newer version of the Yocto2 image and then use the delta binary generator utility to create a delta artifact between Yocto 1 and Yocto 2 images, and be able to apply it to the full system Yocto1 running on NUC1 to update it to Yocto 2.

  3. When I run the mender-artifact I’m seeing a few error messages, the last one being that the “writer: can not tar header: write /tmp/dataxxxx : no space left of device”. The Yocto image created by dd, is roughly 60 G in size. The Root fs of the Intel NUC1 running Yocto1 also is 12 G. I am guessing the writer is trying to use the rootfs/tmp dir to create the artifact. Since there’s no quick/easy way to re-partition the Yocto image(also want to retain the exact partition sizes), I am interested in finding out if I can make use of the mounted 800G partition for writing of the artifact. Unfortunately even after creating a symbolic link to the rootfs/tmp and pointing it to another tmp dir in the 800G partition didn’t resolve the problem. Is there any way I can configure the mender-artifact util to forcefully use the 800G partition for creation of the artifact. Any suggestion/help would be really appreciated.

  4. Alternately, is it possible to use a different workstation with mender installed and running Ubuntu, to create the required artifact which I can then proceed with Step 2 above. I understand that doing this would require me to also convert the image first? I’d like to avoid going through the conversion process if possible.

Hi @krajput101 welcome to Mender Hub.

You definitely can use mender-artifact on an Ubuntu workstation and that is our main use case for it. You can find a pre-compiled mender-artifact binary here:

If you want to continue trying to create this on the NUC, you may be able to use a bind mount rather than a symlink but it’s hard to say for sure without understanding the root cause.

It looks like mender-artifact uses the golang os.TempDir support which claims to respect the $TMPDIR environment variable. I’ve not tried that but you might want to give that a shot as well.


Thanks i’ll check it out and let you know

Hi Again,
Thanks for the suggestion on changing the TempDir. I got the mender artifact working after that. Now that i’ve done the binary delta creation on the two artifacts, i went ahead and tried installing / applying the binary delta. I ran into the following error. Question here is that specific device type should i be using for an Intel NUC, to get past this error?

time=“2020-08-28T17:32:48Z” level=info msg=“Loaded configuration file: /var/lib/mender/mender.conf” module=config
time=“2020-08-28T17:32:48Z” level=info msg=“Loaded configuration file: /etc/mender/mender.conf” module=config
time=“2020-08-28T17:32:48Z” level=info msg=“Mender running on partition: /dev/sda2” module=main
time=“2020-08-28T17:32:48Z” level=info msg=“Start updating from local image file: [/win/mender-binary-delta-1.1.0/x86_64/new-deltafrom-old.mender]” module=standalone
Installing Artifact of size 1805730816…
time=“2020-08-28T17:32:48Z” level=info msg=“no public key was provided for authenticating the artifact” module=installer
time=“2020-08-28T17:32:48Z” level=error msg=“Reading headers failed: installer: failed to read Artifact: readHeaderV3: handleHeaderReads: installer: image (device types [intel]) not compatible with device intel-corei7-64” module=standalone
time=“2020-08-28T17:32:48Z” level=error msg=“installer: failed to read Artifact: readHeaderV3: handleHeaderReads: installer: image (device types [intel]) not compatible with device intel-corei7-64” module=main

Also i assume i’d need to create the artifacts again with the new device type, correct? Thnx

Yes they all need to match. It looks like your device is using “intel-corei7-64” as the device type. You can see what it is in the /etc/mender/device_type file.

Hi Drew,

I just restarted this task again after a long hiatus. Brief Description of the task and what i’m trying to do:

  1. Wanting to see how i could use mender to create and apply binary delta update between two slightly various versions of Yocto rootfs images
  2. Installed yocto old version and then created the rootfs image using dd on a NUC, calling this old-yocto image. Did the same with a new yocto version and created an image using dd.
  3. Using mender-artifact converted the two old-yocto and new-yocto image artifacts.
  4. Tried doing a mender-binary-delta-generator to run the command : sudo ./mender-binary-delta-generator -o new-delta-from-old old-yocto-image-artifact.mender new-yocto-image-artifact.mender but seeing the following error: “could not execute mender-artifact command: No such file or directory”. Plz take note that the mender-artifact is in the same directory and runs fine if i just execute it separately.
    Any suggestions on how to get past this error? Thanks

It seems to me that mender-artifact is not in your PATH?

I’ve added explicitly the mender-artifact location to the $PATH variable as well and no change, am still seeing the same error.

Didn’t hear back. Any other suggestions for me? Thnx

I downloaded the latest mender-binary-delta-generator, and I was not able to reproduce.
With mender-artifact in PATH:

$ x86_64 which mender-artifact 
$ ./mender-binary-delta-generator -o v2.0-deltafrom-v1.0.mender t1 t2
$ echo $?
export PATH=/bin:/usr/bin
$ ./mender-binary-delta-generator -o v2.0-deltafrom-v1.0.mender t1 t2
Could not execute mender-artifact command: No such file or directory
$ echo $?

This was all done using the x86-64 binary.