-
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.
-
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.
-
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.
-
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: https://docs.mender.io/hosted/downloads
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.
Drew
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.
Drew
Hi Drew,
I just restarted this task again after a long hiatus. Brief Description of the task and what i’m trying to do:
- Wanting to see how i could use mender to create and apply binary delta update between two slightly various versions of Yocto rootfs images
- 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.
- Using mender-artifact converted the two old-yocto and new-yocto image artifacts.
- 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
/home/olepor/go/bin/mender-artifact
$ ./mender-binary-delta-generator -o v2.0-deltafrom-v1.0.mender t1 t2
$ echo $?
0
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 $?
1
This was all done using the x86-64 binary.