I have a weird one. Maybe someone else has run into this.
I’m on version 4.096 and I just installed volumio on a 2tb nvme drive into a x86 system. After i install the software, i start it up and let it do its thing. No problems. After i shut it down and connect the 2tb drive to my main computer andbuse disk genius to transfer 1.6tb of music. When i do, it says i don’t have enough space. 283gb to be specific. Even though the drive shows 1.9tb.
I figured, maybe it’s something wrong with the software, so i plug the drive back into the board and trybto use WINSpc to transfer via network. I run into the same issue where it says there is not enough space.
To confirm the drive is good, i created an NTSF system and transfered almost 2tb of music wothout any problem.
The thing is, i have another board with a 2tb nvme drive that i transfered almost 2tb of music to wothout issue.
What could the problem be? Is it a volumio partitioning issue? Any help would be appreciated.
You shouldn’t change anything with the partitions on a Volumio drive. You should have the bulk of available storage in the directory /data/INTERNAL
You can’t access that if you unplug the drive and try to read it from another system. To transfer your media, use File Manager or a file transfer program like Filezilla.
Disk genius allows me to see the proper partitions from volumio. I have access to the INTERNAL section. But that still doesn’t answer the issue because i tried transfering via WinSPC into INTERNAL with the same issue.
Your description is consistent with the data partition not having been expanded to fill the available disk space. Volumio resizes the data partition on first boot, but if that process did not complete properly, the partition would remain at its initial size - which would explain the ~283GB limit you are seeing.
To investigate, I need the following from the Volumio system (with the 2TB NVMe drive installed and booted):
SSH into the device and run these commands, then paste the full output here:
The fdisk and lsblk output will show the actual partition layout and sizes on disk. The df output will show how much space the filesystem sees. Together these will confirm whether the partition was resized and whether the filesystem was expanded to match.
You mentioned you have another board with a 2TB NVMe that works fine. Did you install Volumio the same way on both? Same image, same version, same installation method? Any differences in the NVMe drive model or the x86 board itself would also be worth noting.
I just returned the nvme drive and bought another. I will have to log when i recieve that one.
I did let volumio install to let it size the partition.
The other board i have, was installed with a version at least 3 or 4 versions back and has been updated. I transfered the files via WINspc with no problem. It’s a different board and nvme.
Your fdisk output confirms the partition table is correct - sda3 spans the full 1.9T as expected. However, sda3 does not appear in df at all and has no filesystem size reported in lsblk. The overlay is running at 264MB, which is the fallback state when the data partition cannot be mounted. The ~238-283GB limit you are seeing is consistent with the filesystem on sda3 having been corrupted during first-boot resize rather than the partition itself being wrong.
The short version: the first-boot resize script parses parted output in MB. On devices reporting sizes in TB, the value gets truncated to a single digit. The resulting bad geometry corrupts the ext4 metadata on the data partition. On microSD this drops the system into emergency mode. On x86 EFI boot continues but sda3 fails to mount, leaving the system running on the overlay fallback.
The repair requires an e2fsck followed by a resize2fs against sda3. I have a Storage Manager plugin in beta that includes filesystem check/repair and resize functions and handles large disks correctly. It would be worth trying as an alternative to the manual SSH repair steps.
For the plugin: what did Storage Manager report? Any error message, status, or did it appear to complete and the problem persisted?
For the SSH commands: what was the exact output of e2fsck and resize2fs?
After both attempts, please run df -h and paste the output here.
And a fresh log link from http://volumio.local/dev - the previous one predates both repair attempts.
Without that, all I know is that something happened on a computer somewhere, and it did not produce the outcome you wanted. That is not quite enough to go on.
Volumio Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Welcome to Volumio for x86_64 (6.12.57-volumio x86_64)
volumio@mp21:~$ sudo e2fsck -f /dev/sda3 -y
e2fsck 1.47.0 (5-Feb-2023)
e2fsck: No such file or directory while trying to open /dev/sda3
Possibly non-existent device?
volumio@mp21:~$ sudo resize2fs -p /dev/sda3
resize2fs 1.47.0 (5-Feb-2023)
open: No such file or directory while opening /dev/sda3
volumio@mp21:~$
When i use Storage manager, I cannot select any drive and when i click data partition resize, it shows 292MB free and says partition already ay full size.
@Jersinger
You say you are using an NVME drive, so /dev/sda3 is wrong.
NVME drive partitions are adressed as /dev/nvme<controller>n<namespace>p<partition>
In your case you need to use /dev/nvme0n1p3 for the data partition.
Proof is in your log, output from the mount command
/dev/nvme0n1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro)
/dev/nvme0n1p2 on /imgpart type ext4 (rw,relatime)
/dev/nvme0n1p3 is not shown here because it is part of an overlay filesystem.
volumio@mp21:~$ sudo resize2fs -p /dev/nvme0n1p3
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: Device or resource busy while trying to open /dev/nvme0n1p3
Couldn’t find valid filesystem superblock.
volumio@mp21:~$ Volumio Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Welcome to Volumio for x86_64 (6.12.57-volumio x86_64)
volumio@mp21:~$ sudo e2fsck -f /dev/nvme0n1p3
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p3 is in use.
e2fsck: Cannot continue, aborting.
volumio@mp21:~$ sudo resize2fs -p /dev/nvme0n1p3
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: Device or resource busy while trying to open /dev/nvme0n1p3
Couldn’t find valid filesystem superblock.
volumio@mp21:~$
^C
volumio@mp21:~$
Yes, that won’t work as the partition /dev/nvme0n1p3 is busy as part of Volumio’s overlay filesystem with the read-only squash file.
You can’t do this in a running system.
Boot Volumio from a usb stick and then try again, that should work.
