No space left on device on fresh volumio 3 (Raspi-4) 64GB SD card

Yes, because that is being installed as part of the plugin.
You can’t resize in the PI, because the SD card IS already re-sized during the first boot.
We saw that and you can check as I mentioned above.
You could try to re-size the data partition before using the flashed SD in the PI.

  • You need the SD card reader (which one do you use?) and insert it with the 2nd card into a USB slot.
  • Boot
  • Run sudo fdisk -l to make sure that the 2nd SD is /dev/sda
  • Run
echo "$(sudo parted -s /dev/sda unit MB print free | tail -n 2 | grep Free | awk '{print $3}' | awk -F 'MB' '{print $1}')"
  • Note the returned, it should be a number equal or higher than 1
  • Run
echo "$(sudo parted -s /dev/sda unit MB print free | grep Free | tail -1 | awk '{print $2}' | grep -o '[0-9]\+')"
  • Mark the returned value and use it in the re-size command instead of <END>
  • Run
sudo parted -s /dev/sda resizepart 3 <END> 
sudo e2fsck -fy /dev/sda3
sudo resize2fs /dev/sda3

Done, now boot from the 2nd card.

I doubt whether it makes a difference, but never say never until you know the source of your problem.

I will try that.
Before, I just took my 1st SD card (64GB) and put it with a USB-SD-card-adapter into my other Raspi.
I tried with gparted to extend the /dev/sdb3 (volumio_data), but gparted could not do this.
Isn that strange - see my screenshot that I uploaded.
Thanks

Weird, but that should work, did you unmount /dev/sda3 first?

I solved it.
I used my Windows-PC and the BalenaEtcher to flash the SD card from scratch.
This, then, worked out of the box.
It seems that the PI Imaging Toold does not work correctly for the volumio image.
Thanks for your help.
Best regards
Eduardo

Glad it worked for you. Recently more have reported the opposite: that RPi Imager works better with Volumio than Etcher.

I too have a 64G sd card (Samsung EVO) and it looks like all the space is not available.
overly looks to only be 19G.
volumio@volumiop4:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 2.5G 425M 1.9G 19% /imgpart
/dev/loop0 364M 364M 0 100% /static
overlay 19G 150M 18G 1% /
devtmpfs 919M 0 919M 0% /dev
tmpfs 959M 0 959M 0% /dev/shm
tmpfs 959M 14M 945M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 959M 0 959M 0% /sys/fs/cgroup
tmpfs 959M 0 959M 0% /var/spool/cups
tmpfs 20M 376K 20M 2% /var/log
tmpfs 959M 40K 959M 1% /tmp
tmpfs 959M 0 959M 0% /var/spool/cups/tmp
/dev/mmcblk0p1 92M 54M 38M 59% /boot
/dev/sdb1 29G 29G 198M 100% /media/MUSIC32
tmpfs 192M 0 192M 0% /run/user/1000

I have tried various install/flash methods (balena, dd, opensuse imager, raspi imager).
this is the best I have seen and was from an opensuse imager flash.

Any thoughts or comments?

Maybe you didn’t wait long enough for the filesystem to expand before first use. Apparently it takes a while. I have a 64GB card as well and see overlay is 54G with 49G available.

My solution was Not to use a usb-2-microsd card adapter in my other raspi4 with pi imager Tool. Instead i used rufus on my Windows PC that has a slot for sd-card. So i used a sd-2-microsd converter.

All the ideas trat were replied to me like “wait longer” had noch impact on my situation.

One thing that is VERY bad is using a micro SD to SD adapter sometimes delivered with the micro SD card.
ALWAYS use a proper USB card reader which takes the uSD directly, without a card adapter.

Why? I always use an microsd adapter…when flashing, I use SD port from my laptop

Then you’re one of the lucky ones.
General consensus is (google the subject) that these adapters are way from reliable.

1 Like

Thanks you,
You have added another stress on the list :smiley:

So i have done some further testing.
Waiting and trying reboots seems to make no difference in my environment.
The 64G card showed 19G for the overlay above but after a re-image was only showing 130M.
I tried the method outlined here Out of Disk Space (overlayfs seems incorrect) - #18 by akelge but this caused the card to be non-bootable.
A 16G card I had was not resizing either so i used the resize2fs method and that worked fine.

I had this problem with a 32GB card as well. The partition layout was correct, just the ext4 filesystem doesn’t resize, and I think maybe because of the overlay, you can’t online resize, and you can’t obviously umount the root.

root@volumio /tmp/a/dyn: fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29 GiB, 31104958464 bytes, 60751872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8d45ba47

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *          1   187500   187500 91.6M  c W95 FAT32 (LBA)
/dev/mmcblk0p2       188416  5468159  5279744  2.5G 83 Linux
/dev/mmcblk0p3      5468160 60751871 55283712 26.4G 83 Linux

root@volumio /tmp/a: df -h
Filesystem         Size  Used Avail Use% Mounted on
/dev/mmcblk0p2     2.5G  500M  1.8G  22% /imgpart
/dev/loop0         446M  446M     0 100% /static
overlay            131M  123M     0 100% /

I removed the SD card, and ran the resize2fs with the SD card connected to my main system.

Expanded fine, so hopefully now I can get the touchscreen plugin installed and working.

It can’t be the overlay, because it is created after an attempt to resiize the data partition.
This is part of the init before linux is started and we have seen this occasionally with certain sd cards, so far nobody knows why this happens.
Unfortunately we never had such a card to “play” with, therefore debugging the init part has been impossible.

Ah, so the init environment may be using different software from resize2fs which I used from my main workstation?

I didn’t re-install to see if it would happen reliably on the SD card I have. I think it is a Sandisk 32GB (32GB anyways). And it is just the card I already had, previously used for OpenELEC, until MrMC on the AppleTV replaced it.

So it should not be a well-worn card, as, like with Volumio, it is essentially boots and streams files over the network, but neither is it new.

I would be willing to do some additional debugging, if that would be useful. For starters, if it possibly matters, I imaged the SD card using Pi Imager on Ubuntu, using a USB SD card reader. I used a Kingston adapter with the reader. I didn’t use the adapter when I resized the filesystem manually, as I realized the USB reader has a micro slot, and didn’t need the adapter. The adapter would be just one of the cheap ones that came with a micro SD card.

I think the adapter is not a problem in this case, but I mention it because I think it can be in some cases (and until I test I can’t be sure).

I could try erasing the SD card and re-imaging with the Pi imager again tonight, and see if I can reproduce the problem. If I can then maybe I can do any additional debugging that might be useful.

are you also able to use a Windows machine?
If yes, then try both win32diskimanger and pi imager.

as gkkpch already mentioned, it happens now and then, but never been able to replicate and find a root cause.

All I know from personal experience is that for me Sandisk is more problematic than other brands.

when you are using linux, then the best thing you can do is

dd if=<filename> of=/dev/sd<x> bs=4M
sync

where

  • <filename> is the .img name of the unzipped Volumio download
  • sd<x> is the unmounted usb drive you are writing to, e.g. sdb

Been using this with Volumio development for > 8 years, never had a miss.

I’ll experiment tonight. I’ll try to reproduce the problem by using Pi imager, and the Kingston adapter.

If it does re-occur, I’ll try imaging again without the adapter, and finally with a straight dd using the downloaded image instead of the Pi imager software, to see if any of those things make a difference.

Here’s hoping I can make it fail.

Hello,
To correct the problem:

  1. Activate SSH with web URL http://IP_raspberry/dev
  2. Connect via SSH user volumio
  3. Use the command

sudo resize2fs /dev/mmcblk0p3

  1. Reboot system

Before :

volumio@volumio:~$ df -h |grep overlay
overlay 131M 128M 0 100% /

After:

volumio@volumio:~$ df -h |grep overlay
overlay 56G 128M 53G 1% /

sincerely,