Cannot load handler for unknown Payload type 'rootfs-image'"

Hi,
I am trying to upgrade rootFS on my raspberry Pi3.

Followed this link Raspberry Pi 3 Model B/B+ Raspbian to create a new artifact

Added artifact, created deployment into a raspberry Pi3 device

The deployment failed, I check the logs on raspberryPi3, this is the error logs
"
time=“2019-11-13T06:50:55Z” level=error msg=“Fetching Artifact headers failed: installer: failed to read Artifact: readHeaderV3: handleHeaderReads: Cannot load handler for unknown Payload type ‘rootfs-image’” module=state

"

Can someone help me out, any clues on how to do proceed further?

Hello @chetansk, and welcome to the Mender community.

It is unclear what the error might be, the error message does not really make any sense. The “rootfs-image” type is something that is built in to the Mender client and do not know why it would classify that as a unknown payload type.

Will need to investigate a bit further.

Can provide out of mender-artifact read <the generated artifact>.

hmm… I am not able to compile mender-artifact Looks like md2man which is needed by urfave has dependency broken. Or my dev environment is screwed up… Anyone else seeing this issue ? Please look at the error logs below

go build -ldflags “-X main.Version=29d3fd4” -o mender-artifact cli/mender-artifact/modify.go cli/mender-artifact/read.go cli/mender-artifact/main.go cli/mender-artifact/dump.go cli/mender-artifact/validate.go cli/mender-artifact/write.go cli/mender-artifact/copy.go cli/mender-artifact/log.go cli/mender-artifact/debugfs.go cli/mender-artifact/artifacts.go cli/mender-artifact/sign.go cli/mender-artifact/partition.go
…/…/go/src/github.com/urfave/cli/docs.go:11:2: cannot find package “github.com/cpuguy83/go-md2man/v2/md2man” in any of:
/usr/local/go/src/github.com/cpuguy83/go-md2man/v2/md2man (from $GOROOT)
/home/chetansk/go/src/github.com/cpuguy83/go-md2man/v2/md2man (from $GOPATH)
Makefile:43: recipe for target ‘build’ failed
make: *** [build] Error 1

You can download pre-built binaries of mender-artifact here,

https://docs.mender.io/2.2/downloads

Here it is

 ./mender-artifact read 2019-06-20-raspbian-buster-lite.mender
Mender artifact:
 Name: 2019-06-20-raspbian-buster-lite
 Format: mender
 Version: 3
 Signature: no signature
 Compatible devices: '[raspberrypi3]'
 Provides group:
 Depends on one of artifact(s): []
 Depends on one of group(s): []
 State scripts:
Updates:
   0:
   Type:   rootfs-image
   Provides: Nothing
   Depends: Nothing
   Metadata: Nothing
   Files:
     name:     2019-06-20-raspbian-buster-lite.ext4
     size:     3984588800
     modified: 2019-11-12 22:39:27 +0530 IST
     checksum: b88c29b6582c03c49e6414a68b4f3538d45072f1a883dd6747c19d2f1d4d80b4

Edit: @mirzak: formatting

Can you also share the mender version that is on your device, e.g by running mender -version on the device.

./mender -version
5f8ab7a
runtime: go1.12.7

Hi @chetansk

I am trying, but I haven’t been able to reproduce your problem yet.

However, what I can see so far is that the Mender version running in your device is wrong. If you follow the tutorial as-is you should get Mender version 2.1.1. Probably you missed the git checkout 1.2.1 step there.

Can you double check your setup? What does git show prints in mender-convert folder?

Hi @mirzak @lluiscampos

I had made some changes in the mender client (mostly setting up few environments and path, not in the core logic) and my code base is based on 2.1.x. Hence the version number is not matching.

Will add some debugs and let you know…

Thanks
C

@chetansk That explains why I couldn’t find 5f8ab7a in our Git history :slight_smile:

Looking forward to your debugs to see how can I help with your modifications.

Could this be related to the Mender client not being set up properly for rootfs-image (aka system) updates on the device?

Hi All,

I am really sorry for false alarm… It was my mistake. I had a overwritten the mender.conf created by mender-create with my config file (a working one for script/files). The config file obviously did not had RootfsPartA and RootfsPartB set. Browsing the code helped me figuring this out.

Again, sorry for this mess…

Thanks
C

Nothing to be sorry about. Great that you found the root issue!