question

Speaking from casual observation, I don’t think it persists much. When it’s configured to send data to VRM for the cloud reporting feature, it will log those data locally until it has a network connection and can upload again, but I think that log doesn’t really get too big. And a couple historical software images are cached. Otherwise, I can’t imagine it has anything else of substance to write.

Thanks! I wonder why the heck they make the file 1.8 GB then. It appears it could be a LOT smaller and save all the bandwidth when we download it.

Hi all, the four partitions are:

- boot partition

- rootfs1 & rootfs2 (search google or our wikis about “dual rootfs” to learn more)

- data partition

So there are no ‘other empty partitions’.

And indeed the rootfs partitions are larger than strictly necessary; to make then future proof. Also you wont see their real size when looking at the rootfs file system; see our resize2fs.sh for details about that.

The file you download from our website is 95MB. Then unzipping it indeed makes it large; its the image that you write to an sdcard.

If you use Etcher for writing the image; then you don’t even have to unzip and never see its real size.

Improvements are welcome: If anybody has a better idea on how its done; very welcome and please make a PR (or first send a proposal before implementing it). :-). Just ideas are not very helpful; there is not much spare time.

The boot partition is about 25 MB and contains the little bits responsible for loading the active root partition. Little is stored there and changes very little.

There are two root partitions: the active one and the "backup" one. These flip-flop with each software upgrade. Initially one will be empty. Current usage is about 350 MB each.

The 4th partition is /data where all persistent data is stored: settings, logs, VRM data that hasn't been transferred to the server, etc. The VRM database and the logs are the only things likely to vary in size. With no VRM data, there's about 300 MB stored in this partition.

According to Victron, VRM data amounts to around 20 MB/day. That's about 50 days/1GB, or 8GB to store 1 year. Once the data is transferred to VRM, it is removed from local storage, so you only need storage for the period of time your system is off-line.

The initial image ends up with the root and data partitions of equal size, each being 1/3 the size of the SD card.

I created the initial Venus SD card using Raspberry Pi Imager from the .gz image. Imaging SD cards for backup purposes required some research. I first tried dd from the command line but never got an SD card copy to run.

After looking at several SD cloning apps for Mac OS and unix, I settled on the free "ApplePiBaker" (Mac OS). Not sure about Windows tools.

Cloning tools often complain that the 16 GB image you just made won't fit on a 16 GB card. That's because each card varies in size slightly. Some form of partition size management may be necessary. The problem is that most tools fail to handle the 4-partition Venus image properly when using automatic shrink/expand. The "SD Clone" tool failed to resize at all or damaged the image. ApplePiBaker produced a copy with only two partitions, discarding the other two. I settled on Gparted running on Ubuntu for partition management. There are derivatives that supposedly run on Mac OS but I'd read warnings about flaky EXT drivers for Mac OS. (The derivative I tried wouldn't work with Paragon's EXT driver.)

Hope this helps.