pcurtis avatar image

What are the Consequences of Resizing Venus Large rootfs Partitions on a Raspberry Pi 3B+

I am considering making some changes to the partition and file-system in my Venus OS Large version 2.80~33-large-24. I currently have a couple of 64 Gbyte cards bought as Black Friday bargains but want to use smaller cards in the future as most of the space is wasted. Currently the rootfs ext4 file systems do not fill my partitions leaving 19.6 Gbytes unused and un-formatted in each partition whilst each actual ext4 file system already has 91% of 1.2 Gbytes occupied. I also understand that the rootfs is now read only which has a number of consequences including an inability to add packages with opkg.

I have cloned and backed up my existing system using dd on a standard Linux desktop (Mint Cinnamon flavour) and I am using gparted. I understand there are various changes made to the rootfs portion during [major] upgrades but do not understood what exactly is done or may be done in the future. Ideally I would like to reduce the two rootfs partitions and increase their file-systems to fill them allowing extra headroom for the future and possibly return them to read/write. I should then be able to clone onto a smaller microSD card whilst retaining a generous data partition.

But what will happen at the next update to such a non standard configuration? Any advice welcome.

As this is my first post I should note I have filled in my profile with some background information.

Venus OSRaspberry Pi
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.


This is what it looks like on my 4Gb sd card with venus-v2.80_33-large-24 installed

root@raspberrypi4:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               983.7M    809.8M    124.5M  87% /
devtmpfs                428.0M      4.0K    428.0M   0% /dev
tmpfs                   461.0M    640.0K    460.4M   0% /run
tmpfs                   461.0M    892.0K    460.2M   0% /var/volatile
/dev/mmcblk0p1           43.6M     23.3M     20.3M  53% /u-boot
/dev/mmcblk0p4            1.2G      4.2M      1.1G   0% /data
overlay                 461.0M    640.0K    460.4M   0% /service
overlay                 461.0M    892.0K    460.2M   0% /var/lib

Have also shrunk and used dd to move 64 to 4GB and have not found any problems with this.

By the way, there is a small bash script that shrinks automatically .img file that I have used with great success.

pcurtis avatar image pcurtis johnny-brusevold ·
@Johnny Brusevold Thanks for the link to the script. I am currently using gparted on a separate Linux box but it means accessing the boat. It all seems to be working fine but my concern is what happens during a upgrade so I am keeping backup images (using dd and gzip which seems to work well with small images but very slow for a big card)
1 Answer
mvader (Victron Energy) avatar image
mvader (Victron Energy) answered ·

Be aware that the file system (size) is not the same as the partition (size).

So partitions are sized, I think, to fill the complete card. That happens at first boot of your pi, and perhaps at any subsequent boot as well in case you manually alter that - you’ll have to try to find out. Or, read the source code. This auto increasing of partition size is a pi-only thing in our sources.

But file system holding Venus OS is the size of the files included in it + a fixed percentage of free space. Leaving a lot of the partition empty; especially on a large disk like yours. File system size will differ per build, usually slowly increasing upwards each subsequent version we release.


To remount the file system as read/write, AND increase the filesystem size to use whole of partition, both handy when wanting to use opkg, see resize2fs script. Its documented in the Venus OS root access document.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

@mvader (Victron Energy) Thanks for information. The changes I have made survive a reboot of the system. My concern is whether they survive or prevent an update to a new minor or major version and I think I will have to wait and see. I am hopeful - if the resize2fs is OK my changes should also be OK. Is there likely to be a update soon?

Hi, a fw update usually only replaces the filesystem, aka rootfs. nothing more.

Unless we add scripts or things that alter partitions; which we’ve done for the Venus GX a few times

pcurtis avatar image pcurtis mvader (Victron Energy) ♦♦ ·

@mvader (Victron Energy) I have just done the last update and the basic partitions did not change but the new rootfs no longer fills the partition. I have not used resize2fs [yet] as i am happy to keep the rootfs read only. I have other comments on the update in the github thread.

Sorry, but I don’t understand what you’re after, also not why it would be a problem to have the filesystem not fill the entire partition. Its expected that a fw updates causes the filesystem to be small again; a fw update replaces the file system. And note that there are two rootfs-es.
pcurtis avatar image pcurtis mvader (Victron Energy) ♦♦ ·

Sorry, I can not have made myself clear. I know there are two rootfs systems which are used in turn for updates and backup. I do not mind if they fill the partition but want to keep the overall partitions small rather than ~one third of the SD. I am happy for them to be read only at present but realise they need to have extra space and be read/write if I add any packages using opkg which can be achieved using resize2fs. I have achieved what I want and I now know most updates will have no impact.

This what I had before the last update. I can not show the latest without a visit to the boat to extract the SD card.venus280-33-repartitioned.png