2.129 Swap space on Raspberry Pi

Similar situation as before https://volumio.org/forum/posting.php?mode=reply&f=21&t=5380

Flashed the new image onto the card and couldn’t get HTTP running. SSH’d into it, noticed there was no free disk space. So I had to edit /bin/dynswap.sh
to lower swap use.

This time 80M wasn’t enough, I have 5 megs free ram and 4 megs free swap and the web UI doesn’t load every time I try to open it. I’ll try to find a suitable value through experimentation, but as you can clearly see from the mount points below, /data/swapfile cannot possibly be 512M with these sizes:

volumio@volumio:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  2.2G  509M  1.6G  25% /imgpart
/dev/loop0      253M  253M     0 100% /static
overlay         262M   91M  151M  38% /
devtmpfs        233M     0  233M   0% /dev
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           242M  4.7M  237M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs           242M   16K  242M   1% /tmp
tmpfs           242M     0  242M   0% /var/spool/cups
tmpfs            20M   28K   20M   1% /var/log
tmpfs           242M     0  242M   0% /var/spool/cups/tmp
/dev/mmcblk0p1   61M   29M   33M  47% /boot
tmpfs            49M     0   49M   0% /run/user/1000

Why is the / partition so small?

Do people use Volumio on a Raspberry Pi at all, and if so, how did you work around this issue?


You may have a problem with your flashing procedure (unproperly unmounting after flashing or else).
Can you try with etcher app?
At first boot partitions are resized and /data is on main ext4 part so plenty of room for swapfile, unless you use very tiny SD.
if partitions are corrupt after flashing, maybe resizing fails…

I did write the MicroSD with Etcher.

Of course some kind of corruption is always possible, but I do know how to eject a device from my computer, thanks :wink:

That the partition is resized is new to me, that is a bit suspicious.

Either way, it’s a different bug if the resizing causes a partition that can’t hold it. Maybe something should abort at
that stage or otherwise complain. How’s the new size determined?

Besides that, I lowered the amount of swap space to 128M (didn’t really waste time estimating, 7M free ram, 3M used swap
this time around. Actually profiling this stuff takes a long time and there’s the swappiness setting to help). This combined
with maybe using only OTA updates from now on can float me a long way.