Question on updating rootfs with a bundle where there are no changes

[bbergquist0930]

This is on kirkstone release. I have rauc up and running successfully. For my system.conf it looks like

[system]
compatible=Kiosk
bootloader=grub
grubenv=/grubenv/grubenv
data-directory=/data/

[keyring]
path=ca.cert.pem

[log.readable]
filename=rauc-history.log

[log.json]
filename=rauc-history.json
format=json

[slot.efi.0]
device=/dev/disk/by-partlabel/boot
type=boot-gpt-switch
region-start=4M
region-size=100M

[slot.rescue.0]
device=/dev/disk/by-partlabel/rescue
type=ext4
readonly=true

[slot.rootfs.0]
device=/dev/disk/by-partlabel/root_a
type=ext4
bootname=A

[slot.rootfs.1]
device=/dev/disk/by-partlabel/root_b
type=ext4
bootname=B

I build an update bundle with

...
RAUC_BUNDLE_FORMAT = "verity"
RAUC_BUNDLE_SLOTS = "rootfs"
RAUC_IMAGE_FSTYPE = "ext4"

RAUC_SLOT_rootfs = "kiosk-image"
RAUC_SLOT_rootfs[fstype] = "ext4"
RAUC_SLOT_rootfs[adaptive] = "block-hash-index"

I have run unsquashfs on the bundle and have

-rw-r--r-- 1 brett brett 3375087616 Apr  5  2011 kiosk-image-epc-kiosk-intel64.ext4
-rw-r--r-- 1 brett brett   26367872 Apr  5  2011 kiosk-image-epc-kiosk-intel64.ext4.block-hash-index
-rw-r--r-- 1 brett brett        318 Apr  5  2011 manifest.raucm

the manifest looks like

...
[bundle]
format=verity

[image.rootfs]
sha256=7e9a3d4a408ebb139a96da2aaf57cfa292b97478bf3ef03e8d5b5b6c66825ce8
size=3375087616
filename=kiosk-image-epc-kiosk-intel64.ext4
adaptive=block-hash-index;

So it looks like I should be ok to support the adaptive updates.

I setup a simple range supporting HTTP server and from the device I run

rauc install http://172.16.99.68:8000/kiosk-image-bundle-epc-kiosk-intel64.raucb

which succeeds. I do this for both rootfs slots.

The bundle is about 1.3G in size with the internal rootfs ext file being about 3.2G in size.

Now I back on slot A, I install the bundle again. This is with no changes to the bundle. From capturing the network traffic, I see about 1.2G of HTTP traffic.

I am curious why there should be so much. The build was done with the Yocto reproducible build settings

    BUILD_REPRODUCIBLE_BINARIES = "1"
    export PYTHONHASHSEED = "0"
    export PERL_HASH_SEED = "0"
    export TZ = 'UTC'
    export SOURCE_DATE_EPOCH ??= "1520598896"
    REPRODUCIBLE_TIMESTAMP_ROOTFS ??= "1520598896"

Any insight as to why so much of a transfer is needed will be helpful.

[ejoerns]

@bbergquist0930 you might want to check the adaptive update stats from the rauc service log (access stats for .. lines)

Also, check that the ext4 block size is 4096 and that you use a fixed directory hash seed. See https://github.com/rauc/meta-rauc-community/blob/master/meta-rauc-qemux86/recipes-core/images/core-image-minimal.bbappend#L12 for example.

[bbergquist0930]

Thank you very much for taking the time to respond!. I did go through those. My rootfs.ext inside the bundle

brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64/squashfs-root$ dumpe2fs kiosk-image-epc-kiosk-intel64.ext4 | grep "Block size"
dumpe2fs 1.46.5 (30-Dec-2021)
Block size:               4096
brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64/squashfs-root$ 

My rootfs of the original image

brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ dumpe2fs kiosk-image-epc-kiosk-intel64.ext4 | grep "Block size"
dumpe2fs 1.46.5 (30-Dec-2021)
Block size:               4096
brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ 

My initial install is an installer image that copies rootfs.img to the drive after partitioning (like a live install but custom). I can see that rootfs.img is 4k blocks as well

brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ sudo losetup --find --show --partscan kiosk-image-installer-epc-kiosk-intel64.wic
/dev/loop45
brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ sudo mount /dev/loop45p2 /mnt
brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ ls /mnt
bzImage  EFI  lost+found  rootfs.img
brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ dumpe2fs /mnt/rootfs.img | grep "Block size"
dumpe2fs 1.46.5 (30-Dec-2021)
Block size:               4096
brett@brett-precision-7780:~/yocto/build/tmp/deploy/images/epc-kiosk-intel64$ 

and on the physical device once installed

root@9996:~# dumpe2fs /dev/disk/by-partlabel/root_a | grep "Block size"
dumpe2fs 1.46.5 (30-Dec-2021)
Block size:               4096
root@9996:~# 

So originally, all seem to have 4k blocks. Doing more investigation, maybe it is my initial copying the rootfs.img to the physical storage as part of my installation. I am using "cp -r" after mounting the image, which is probably not what I want. I probably want to use "dd".

I will try that later today and report back.

But again, just the response back caused me to think investigate and think some more!

[bbergquist0930]

My installing the rootfs onto the target device was the issue. I had to change to using "dd" to copy the rootfs to the target device and then use "resize2fs" to resize the filesystem to the partition size. An update with no changes only downloaded 26M out of 3.2G of the update bundle.