Problem with volumio_data not expanding

MyVolumio MyVolumio Help and Support
1

Due to having to re-install have been able to repeat the problems had with the volumio_data partition when I did first install.

After completing first boot using Ethernet, then doing a reboot to bring up only on WiFi.
Noted the following when checking file systems mounted. Note the “overlay” showing only 262Mb
volumio@volumio:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 2.2G 642M 1.5G 31% /imgpart
/dev/loop0 283M 283M 0 100% /static
overlay 262M 67M 175M 28% /
devtmpfs 474M 0 474M 0% /dev
tmpfs 486M 0 486M 0% /dev/shm
tmpfs 486M 4.8M 481M 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 486M 0 486M 0% /sys/fs/cgroup
tmpfs 486M 20K 486M 1% /tmp
tmpfs 486M 0 486M 0% /var/spool/cups
tmpfs 20M 44K 20M 1% /var/log
tmpfs 486M 0 486M 0% /var/spool/cups/tmp
/dev/mmcblk0p1 61M 37M 24M 61% /boot
tmpfs 98M 0 98M 0% /run/user/1000

Checking on the actual partition table noted:
volumio@volumio:~$ sudo fdisk /dev/mmcblk0
[sudo] password for volumio:

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/mmcblk0: 58.3 GiB, 62562238464 bytes, 122191872 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: 0x21c5cc5b

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 1 125000 125000 61M c W95 FAT32 (LBA)
/dev/mmcblk0p2 125001 4882812 4757812 2.3G 83 Linux
/dev/mmcblk0p3 4882813 122191406 117308594 56G 83 Linux

As expected of a 64Gb Micro SDRAM the 3rd partition should be all of what is left, 56Gb+ as shown.

Copied one ripped CD album onto the volumio using SMB
volumio@volumio:~$ cd /data
volumio@volumio:/data$ ls
INTERNAL albumart backgrounds configuration favourites playerstate playlist plugins volumio-update.tmp
volumio@volumio:/data$ cd INTERNAL/
volumio@volumio:/data/INTERNAL$ ls
Rivertribe

Taking the Micro SDRAM and mounting on an Ubuntu desktop get:
Taking Micro SDRAM out and mounting on a Ubuntu Linux system get the following:
Filesystem Size Used Avail Use% Mounted on
/dev/sde1 61M 37M 24M 61% /media/gordon/boot
/dev/sde2 2.2G 642M 1.5G 31% /media/gordon/volumio
/dev/sde3 262M 67M 175M 28% /media/gordon/volumio_data

Same as found mounted on the Raspberry Pi only 262Mb on the volumio_data partition

A check of the partitions shows same as on the Pi:
:~$ sudo fdisk /dev/sde

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sde: 58.3 GiB, 62562238464 bytes, 122191872 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: 0x21c5cc5b

Device Boot Start End Sectors Size Id Type
/dev/sde1 * 1 125000 125000 61M c W95 FAT32 (LBA)
/dev/sde2 125001 4882812 4757812 2.3G 83 Linux
/dev/sde3 4882813 122191406 117308594 56G 83 Linux

My question is how does this happen and how do I enable this to full size ?

Note copying files to the SDRAM whether via SMB to the volumio host or when mounted in an Ubuntu desktop fails after 262Mb

Apologies for long post however since this happened again thought it worthwhile to capture and show what am seeing.

Last time had to manually configure the partition as mounted then re-mount ?

2

would you be able to reproduce this do you think?
Also good to know the exact version you have now and was it a clean install?
In case you upgraded, from which version?

3

In response

  1. would you be able to reproduce this do you think?
    Has happened twice now, this is second install after corruption

  2. Also good to know the exact version you have now and was it a clean install?
    I’ll check tonight my time, was downloaded less than two weeks ago current one. Previous failure requiring manual was about 2+ months ago.

  3. In case you upgraded, from which version?
    Not an upgrade fresh install

Am going to install a new one on separate SDRAM, a smaller one and try that as well. Just in case the 64Gb is the problem? Using the larger capacity as I have some 400+ CD’s I own that have Ripped.

4

Confirming was a clean install of:

volumio-2.526-2019-01-12-pi

Have manually fixed the partition on the 64Gb SDRAM.

Will test again on weekend my time, an AWST

5

Not met this situation yet, we need to check if we have regression somewhere in the boot process.
This is a fresh install without any manual intervention before the first boot?

6

It could well be that our auto resize script does not work properly with 64 gb sd card. In fact, we never tested it directly with such size. Going to get one and see

@gé what do you think?

7

I don’t think is is size-related.
@gordont: would you have the opportunity to look at the boot partition after you did the first boot using a PC?
Do not reboot, do a shutdown and take the SD out.
Check on a PC to see if the “resize-volumio-datapart” file is still present on in the BOOT partition.
Something must be failing here, with your help we can make this top priority.

8

on a second thought: yes, we should check “parted” to see how a resize on a 64Gb SD card works in practise.
As I used a 750Gb usb disk(and larger) before, there “should” not be an issue, but better test.

9

Will redo on weekend, as background am burning the image to the Micro SD using the following:
Ubuntu 16.04
Etcher 1.4.9
Only oddity the SDRAM slot on the computer is not working instead using a USB device with slots for micro SD, SDRAM, Compact Flash and SIMs. Hence the /dev/sde in original post.

Based on your responses here you are looking for a repeatable with the 64Gb SDRAM, that is same one. Where you are looking for:
Burn image to device
Boot Pi first time Or ??
Stop take out SDRAM
Insert SDRAM into desktop, my Ubuntu
Check on partition boot for a file “resize-volumio-datapart”?

Should be looking for that file prior to using in Pi ?

10

Doing an image to a smaller SDRAM, this time a 16Gb micro SD. Here is initial image write on Ubuntu desktop
$:/media/gordon/boot$ df -h
Filesystem Size Used Avail Use% Mounted on

/dev/sde3 262M 160K 241M 1% /media/gordon/volumio_data
/dev/sde1 61M 37M 24M 61% /media/gordon/boot
/dev/sde2 2.2G 286M 1.8G 14% /media/gordon/volumio

An fsck before running in a Raspberry Pi gives
Device Boot Start End Sectors Size Id Type
/dev/sde1 * 1 125000 125000 61M c W95 FAT32 (LBA)
/dev/sde2 125001 4882812 4757812 2.3G 83 Linux
/dev/sde3 4882813 5468750 585938 286.1M 83 Linux

Confirming that the file “resize-volumio-datapart” exists and is an empty file on the boot partition, output ls
bcm2708-rpi-0-w.dtb bcm2710-rpi-3-b.dtb config.txt kernel7.img start_db.elf
bcm2708-rpi-b.dtb bcm2710-rpi-3-b-plus.dtb fixup_cd.dat kernel.img start.elf
bcm2708-rpi-b-plus.dtb bcm2710-rpi-cm3.dtb fixup.dat overlays start_x.elf
bcm2708-rpi-cm.dtb bootcode.bin fixup_db.dat resize-volumio-datapart volumio.initrd
bcm2709-rpi-2-b.dtb cmdline.txt fixup_x.dat start_cd.elf

Next boot into a Raspberry Pi - note this time a Pi 2, will do the the 64Gb on the Pi 3 over the weekend, Friday night here as am doing this.
Ok so results are in after first boot then power off Raspberry Pi:
Checking on the boot partition from Ubuntu desktop the “resize-volumio-datapart” file has gone.
The partitions mounted show up as:
Filesystem Size Used Avail Use% Mounted on
/dev/sde1 61M 37M 24M 61% /media/gordon/boot
/dev/sde3 262M 256M 0 100% /media/gordon/volumio_data
/dev/sde2 2.2G 642M 1.5G 31% /media/gordon/volumio

An fsck however shows:
Device Boot Start End Sectors Size Id Type
/dev/sde1 * 1 125000 125000 61M c W95 FAT32 (LBA)
/dev/sde2 125001 4882812 4757812 2.3G 83 Linux
/dev/sde3 4882813 31116287 26233475 12.5G 83 Linux

Ok so should I use an alternate image writing, eg use dd instead off Etcher?

11

Repeated the exercise with the 16Gb SDRAM, using dd on command line. Same outcome as above!!

Did not get to the 64Gb version, need to backup and be prepared for this.

Keen to here an update what other logging capture, data points, files need to look at and capture to provide.

12

This is really weird, I cannot reproduced this, not with my only PI3 and with an old RPI 2 I borrowed yesterday.
Showing here the results for the PI 2: after the first boot with an 8GB SD card I get

df -h Filesystem Size Used Avail Use% Mounted on /dev/mmcblk0p2 2.2G 642M 1.5G 31% /imgpart /dev/loop0 283M 283M 0 100% /static overlay 4.9G 525M 4.1G 12% / devtmpfs 222M 0 222M 0% /dev tmpfs 233M 0 233M 0% /dev/shm tmpfs 233M 4.6M 228M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 233M 0 233M 0% /sys/fs/cgroup tmpfs 233M 16K 233M 1% /tmp tmpfs 233M 0 233M 0% /var/spool/cups tmpfs 20M 40K 20M 1% /var/log tmpfs 233M 0 233M 0% /var/spool/cups/tmp /dev/mmcblk0p1 61M 37M 24M 61% /boot tmpfs 47M 0 47M 0% /run/user/1000
This shows the overlay partition as 4.9G, as expected considering “parted” shows this on my Debian desktop:

[code]gkkpch@VolumioOS-1:~$ sudo parted -s /dev/sdb print unit MB
Model: TS-RDF5 SD Transcend (scsi)
Disk /dev/sdb: 7882MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 512B 64.0MB 64.0MB primary fat32 boot, lba
2 64.0MB 2500MB 2436MB primary ext4
3 2500MB 7882MB 5382MB primary ext4
[/code]
In case there would be a general issue with 2.526, I would have expected reports from other users.

What happens when you flash a fresh image and doing a manual resize on your Ubuntu machine, using this:

END="$(sudo parted -s /dev/SDx unit MB print free | grep Free | tail -1 | awk '{print $2}' | grep -o '[0-9]\+')" sudo parted -s /dev/SDx resizepart 3 ${END} e2fsck -fy /dev/SDx3 resize2fs /dev/SDx3
Where SDx is your device, show the results with

sudo parted -s /dev/SDx unit MB print

Still the same?

13

Problem is odd, will do this tonight and check on outcome.

FYI have resolved the not expanding one of two ways. Manually delete, then create the third partition at post flash time. That is not as sophisticated as your solution, manual intervention. Copy out what folders/files are on volumio_data at this time and put back.

Other approach post first boot did same, main difference the partition using fsck is showing full size the mount is not. Then manually re-create the volumio_data partition with folders/files copied and copied back.

Ugly approach though has worked. Able to use the partition to copy up ripped music library and install plugins.

14

Attempted 16Gb and a 64Gb micro SD yesterday evening my time. Both same result in terms of expanding after first boot on a Raspberry Pi.

Then did both only on the Ubuntu and followed the instructions on resizing all good that worked and first boot the partition was the right size.

So my last thought is to use a different platform, have an iMac, and another laptop running Ubuntu 18.04. Both have working SDRAM slots. Perhaps my issue is the platform as that is the consistent point for all attempts. Three SDRAM’s, using Etcher, and doing manual dd to copy.

15

Last round used a different computer laptop running Ubuntu 18.04 with a working SDRAM slot. Tried with both a 16Gb and a 64Gb Micro SDRAM.

Installed latest image on both, 2.526, using Etcher 1.4.9. Then booted in a Pi3 B model. Result same before putting into the RPi3B the 3rd partition volumio_data shows 262Mb in size with 230Mb used and shows same using fdisk. Note the resize-volumio-datapart file was there on the boot partition.

After first boot take out of Pi and mount into the Ubuntu laptop. No resize-volumio-datapart file evident in boot partition. Size of volumio_data remains at 262Mb when mounted. Though real size is as it should be, fdisk or:

For 64Gb
Ubuntu18.04:~$ sudo parted -s /dev/mmcblk0 print unit MB
Model: SD 00000 (sd/mmc)
Disk /dev/mmcblk0: 64.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 512B 64.0MB 64.0MB primary fat32 boot, lba
2 64.0MB 2500MB 2436MB primary ext4
3 2500MB 64.0GB 61.5GB primary ext4

For 16Gb
Ubuntu18.04:~$ sudo parted -s /dev/mmcblk0 print unit MB
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk0: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 512B 64.0MB 64.0MB primary fat32 boot, lba
2 64.0MB 2500MB 2436MB primary ext4
3 2500MB 15.9GB 13.4GB primary ext4

At a loss now to explain this, maybe a non Linux platform? Etcher is a recommended image writing tool on Volumio instructions so am assuming not that.

16

I don’t see this issue with dd but haven’t tried very hard to exactly reproduce.
Here is how I use dd.

  • insert card into ubuntu machine
  • dmesg |tail -20 #look for messages like
 sd 8:0:0:0: Attached scsi generic sg3 type 
 sd 8:0:0:0: [sdc] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
  • Copy with
 sudo dd bs=1M if=volumio-2.526-2019-01-12-pi.img of=/dev/sdc

The copy can take quite some time, be patient. dd will give a summary of how much it wrote when it is done.

17

Yes did that as alternative to using Etcher.

Weird not sure why the auto expand is not working for me it is what it is. Have built the device and is working after manual intervention for the file system in question. So all happy now.

18

Closing out this thread. For the second time now my Volumio on a Pi3B with Touch Screen has corrupted. This time happened with upgrade to 2.555 which came out on 18th February. Previous corruption my own fault insufficient power trying to operate touchscreen with pi through one power supply. Having changed that one was all working until the upgrade.

Taken SDRAM out and checked file systems via an Ubuntu 16 desktop all came up ok. Attempt to boot no luck, am up for another re-install.

Given issues experienced with the non expanding file system and then uploading the 400 CDs have ripped will take time. This is frustrating and has been noted in this thread seems to be isolated to me, the file system not expanding.

Real let down actually appreciate what Volumio is and the wonderful efforts of the key community people involved. However this failures for me will drive me to look elsewhere, sadly though few straightforward options. Musicbox is lacking support and update though have had reasonable success with. OpenELEC, Kodi et al are more than am looking for.

Wish me luck this time around hope latest build does do the auto expand then it’s re-install touch screen and as interested keyboard for, and upload music.

19

I too have this problem.
I am a new volumio user, and installed the image from Feb 2019 onto a Samsung EVO plus 32Gb card using Etcher/Balena from an ASUS laptop running Ubuntu 16.04

Installed card into a Raspberry Pi 2B+
I did not notice the non-expansion because everything seemed to work just fine. (BTW Thank you)

I successfully created playlists, however during my attempts to add the irremote plugin, I noticed an out of space on filesystem message.
Now, understandably, the volumio web app doesn’t respond but ssh access is still possible.

I am about to reflash, but would check anything on guidance from folks wiser than me.

Regards, Alf

volumio@volumio:/$ df
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  2.4G  675M  1.6G  31% /imgpart
/dev/loop0      298M  298M     0 100% /static
overlay         274M  268M     0 100% /
devtmpfs        497M     0  497M   0% /dev
tmpfs           509M     0  509M   0% /dev/shm
tmpfs           509M   35M  475M   7% /run
tmpfs           5.3M  4.1k  5.3M   1% /run/lock
tmpfs           509M     0  509M   0% /sys/fs/cgroup
tmpfs           509M  4.1k  509M   1% /tmp
tmpfs           509M     0  509M   0% /var/spool/cups
tmpfs            21M   21k   21M   1% /var/log
tmpfs           509M     0  509M   0% /var/spool/cups/tmp
/dev/mmcblk0p1   63M   39M   25M  61% /boot
/dev/sda1        31G   30G  1.3G  96% /media/KINGSTON
tmpfs           102M     0  102M   0% /run/user/1000
20

Additional info from card now mounted on Ubuntu.

[code]alf@ASUS-ROG-Ubuntu:~$ df | grep mmc
/dev/mmcblk0p2 2275928 658596 1482004 31% /media/alf/volumio
/dev/mmcblk0p1 61522 37156 24367 61% /media/alf/boot
/dev/mmcblk0p3 267388 261488 0 100% /media/alf/volumio_data
alf@ASUS-ROG-Ubuntu:~$ sudo parted -s /dev/mmcblk0 print unit MB
Model: SD EB1QT (sd/mmc)
Disk /dev/mmcblk0: 32.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 512B 64.0MB 64.0MB primary fat32 boot, lba
2 64.0MB 2500MB 2436MB primary ext4
3 2500MB 32.0GB 29.5GB primary ext4

alf@ASUS-ROG-Ubuntu:~$
[/code]