bundle information is null on newly flashed system

[om26er]

When we flash a new image it seems rauc status command reports incomplete data. Here is the result after fresh boot

root@jetson-xavier-nx-devkit:~# rauc status --detailed --output-format=json
{"compatible":"XavierNX","variant":"","booted":"APP","boot_primary":"rootfs.0","slots":[{"rootfs.1":{"class":"rootfs","device":"/dev/mmcblk0p2","type":"ext4","bootname":"APP_b","state":"inactive","parent":null,"mountpoint":null,"boot_status":"good","slot_status":{"bundle":{"compatible":null}}}},{"rootfs.0":{"class":"rootfs","device":"/dev/mmcblk0p1","type":"ext4","bootname":"APP","state":"booted","parent":null,"mountpoint":"/","boot_status":"good","slot_status":{"bundle":{"compatible":null}}}}]}

Do note that the bundle information is broken. This is is kind of a problem for us because we want to check what version of the bundle our system has currently installed and check on a remote service if an update is available. Is that a bug or "expected" ?

[om26er]

Here is the other format

root@jetson-xavier-nx-devkit:~# rauc status --detailed
=== System Info ===
Compatible:  XavierNX
Variant:     
Booted from: rootfs.0 (APP)

=== Bootloader ===
Activated: rootfs.0 (APP)

=== Slot States ===
o [rootfs.1] (/dev/mmcblk0p2, ext4, inactive)
	bootname: APP_b
	boot status: good
      slot status:
          bundle:
              compatible=(null)

x [rootfs.0] (/dev/mmcblk0p1, ext4, booted)
	bootname: APP
	mounted: /
	boot status: good
      slot status:
          bundle:
              compatible=(null)

[ejoerns]

@om26er How did you flash the System? With or without using RAUC for writing the rootfs?

As the bundle information can only be generated after the rootfs file system image was created, it cannot be part of the rootfs and is thus only available when you did the first installation.

You could use RAUC in factory (after partitioning) to write the initial rootfs. Then you would have the bundle information available.

Where/How do you use the information (for)?

[om26er]

We flash the partitions using Nvidia's tegraflash tool. So I ended up writing a "fake" slot.raucs into the image during it's creation. This enables us to check what version we currently have installed

root@jetson-xavier-nx-devkit:~# cat /slot.raucs 
[slot]
bundle.build=20210405184112
status=ok

[JakubVanek]

I think we've been facing a similar issue.

We are using Buildroot and genimage for building a small OS for the Raspberry Pi 4. We've picked a symmetric A/B ext4 rootfs setup with a single FAT32 boot partition and a single ext4 data partition.

In our case, the build process outputs a full SD card image for flashing new devices and a RAUC update bundle for updating deployed devices. The built rootfs image is used for both: it is copied into both SD card partitions and is also the only image file in the update bundle.

The slot state file is stored on the persistent data partition, which is initially empty. We'll likely use the same workaround, i.e. generating the status file based on the raw rootfs image and including that in the data partition of the SD card image. I can also reflash both partitions using RAUC, but it doesn't fit neatly into the build process.

[JakubVanek]

Hmm, the workaround might be even simpler - including a separate version string directly in the rootfs image solves this too. We want to use this information for determining what OS version is installed on the device. We can then determine whether the device needs to be updated using an internal update agent.

[jluebbe]

This working as intended. On a newly flashed system, no bundle has been installed yet, so there is no "currently installed bundle version". If you need a OS version, I'd suggest the same as @JakubVanek in https://github.com/rauc/rauc/issues/710#issuecomment-915317590: Store it in /etc/os-release or /etc/lsb-release when building the root filesystem.

You can the use the same version in the manifest when building a bundle, if that fits your workflow.