I did some more testing today and I am almost positive that this is a mender-artifact thing. mender-convert calls mender-artifact so if i take the rootfs.img from mender-convert and try to run mender-artifact myself i still see the above errors. on top of that if i do compression none and try to install that i get:
Installing artifact...
record_id=1 severity=error time="2026-Jan-19 23:19:53.835339" name="Global" msg="Failed to initialize the Archive handle: Failed to initalize the 'libarchive' C bindings. LibArchive error message: 'Unrecognized archive format' error code: 84"
record_id=2 severity=info time="2026-Jan-19 23:19:53.865742" name="Global" msg="Sending SIGTERM to PID 1011000"
record_id=3 severity=info time="2026-Jan-19 23:19:53.865879" name="Global" msg="PID 1011000 exited with status 15"
record_id=4 severity=error time="2026-Jan-19 23:19:53.869552" name="Global" msg="Parse error: archive_read_next failed in LibArchive. Error code: -30 Error message: Unrecognized archive format"
Installation failed. System not modified.
Could not fulfill request: Parse error: archive_read_next failed in LibArchive. Error code: -30 Error message: Unrecognized archive format
i’ve tried mender-artifact 4.2.0, 4.1.0, 4.1.1
i know the rootfs.img is good because i can take that and dd it to the other rootfs and boot it and it works fine. so mender-artifact is doing things i just dont understand. it takes a perfectly fine rootfs.img and then packages in a way that seems utterly broken. paths dont make sense, like you said above, the 0000 directory is weird to me.
in the manifest it says
8ae4b98c0dfa4c762681799da27cacbaf4c61fdcf2cd9064b0c7019920afd98b data/0000/rootfs.img
but then you look in the data dir and there’s just a file in there called 0000.tar or 0000.tar.gz if compression is gzip. but if you untar that file you would assume it would untar into 0000/rootfs.img but it just expands into rootfs.img. you would think it would expand much like header.tar{.gz} which expands to
headers/0000/type-info
headers/0000/meta-data
not to mention even in the manifest it has the header.tar{.gz} checksum on the .tar{.gz} but the checksum for the rootfs.img is on the .img file living in data/0000 instead of the compressed file???
which leads me to believe that mender-update is looking for a file that doesn’t exist inside the package
as for how to replicate this.
here is my user-data storage settings for a ubuntu 25.04 install:
storage:
swap:
size: 0
config:
- type: disk
match: # select largest ssd...
size: largest
id: disk0 # ...and call it disk0
ptable: gpt # use gpt partitions on disk0
wipe: superblock
- type: partition # create partitions on disk0
number: 1
id: efi-partition
device: disk0
size: 256M
flag: boot # uefi partition needs boot flag
grub_device: true # and must be the grub device?
- type: partition
number: 2
id: roota-partition
device: disk0
size: 10G
- type: partition
number: 3
id: rootb-partition
device: disk0
size: 10G
- type: partition
number: 4
id: data-partition
device: disk0
size: -1
- type: format # format partitions on disk0
id: efi-format
volume: efi-partition
fstype: fat32 # ESP gets FAT32
label: ESP
- type: format
id: roota-format
volume: roota-partition
fstype: ext4 # / (root) gets ext4, xfs, btrfs
label: ROOTA
- type: format
id: rootb-format
volume: rootb-partition
fstype: ext4 # / (root) gets ext4, xfs, btrfs
label: ROOTB
- type: format
id: data-format
volume: data-partition
fstype: ext4
label: DATA
- type: mount # mount formatted partitions on disk0
id: root-mount # / (root) gets mounted first
device: roota-format
path: /
- type: mount
id: efi-mount # /boot/efi gets mounted next
device: efi-format
path: /boot/efi
- type: mount
id: data-mount
device: data-format
path: /data
the rest is pretty basic.
then qemu-img convert -O raw /dev/pve/vm-9001-disk-1 ./disk-v0.0.19-$(date +“%Y%m%d.%H%M”).img
then my mender-convert config is
# Compression
MENDER_COMPRESS_DISK_IMAGE="gzip"
MENDER_ARTIFACT_COMPRESSION="gzip"
# EFI / GRUB
MENDER_GRUB_EFI_INTEGRATION="y"
MENDER_BOOT_PART_MOUNT_LOCATION="/boot/efi"
MENDER_PARTITION_SCHEME="gpt"
# Storage device
MENDER_ENABLE_PARTUUID="y"
MENDER_BOOT_PART="/dev/disk/by-partuuid/66aa2bd1-1329-4b40-94c4-1d1cebd51acc"
MENDER_ROOTFS_PART_A="/dev/disk/by-partuuid/98309743-8135-4000-85fd-00108ae8d601"
MENDER_ROOTFS_PART_B="/dev/disk/by-partuuid/872f9f2e-7f80-4cbf-a694-fd7f98aa114e"
MENDER_DATA_PART="/dev/disk/by-partuuid/8f3f7347-a2df-4674-b642-ef3e16a47798"
# Partition numbers
MENDER_BOOT_PART_NUMBER="1"
MENDER_ROOTFS_PART_A_NUMBER="2"
MENDER_ROOTFS_PART_B_NUMBER="3"
MENDER_DATA_PART_NUMBER="4"
# Partition sizes
MENDER_BOOT_PART_SIZE_MB="256"
MENDER_DATA_PART_SIZE_MB="512"
MENDER_STORAGE_TOTAL_SIZE_MB="40960" # end up with roughly 20G drives
# Rootfs sizing
IMAGE_ROOTFS_SIZE="20070400" # 19600 MiB
IMAGE_ROOTFS_EXTRA_SPACE="0"
IMAGE_OVERHEAD_FACTOR="1.0"
# Data partition
MENDER_DATA_PART_GROWFS="y"
# Image behavior
MENDER_SPARSE_IMAGE="y"
MENDER_COPY_BOOT_GAP="n"
# Client
MENDER_CLIENT_INSTALL="y"
MENDER_CLIENT_VERSION="4.0.7"
# Device type
MENDER_DEVICE_TYPE="x86_64"
…and here is the wilder part. if i take the rootfs.img and then tar gzip to get rootfs.tar.gz and then i take that and run
mender-artifact write rootfs-image
--file rootfs.tar.gz
--output-path v0.0.19-25.mender
--artifact-name v0.0.19-25
--device-type x86_64
--compression none
i can take that that .mender file and mender-update install it just fine. no errors from mender-update. of course even though the install works the new rootf wont work because all it did was dd the tar.gz to the disk making the disk not boot. but the bigger thing is mender-update allows me to install it.