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
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
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
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.
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.
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.
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.