Hi, I own a Raspberry 5 and use a micro sd card to run volumio. For the music source, I put them in an M.2 ssd and connect it with the Raspberry. However when I open Volumio, it can’t find any music.
please label the disk as “issd” or ihdd"
So I am gonna rename the disk “issd” in my PC?
that would be the easiest way without installing additional software on the rPi
thanks
Hi
@Wheaten Could you tell more about the renaming of the M.2 ssd to “issd” or “ihdd”?
Background / Explaination
I had a M.2 SSD working well with older versions of Volumio (more than 2years ago i think)
Then it stopped working (did some posts here / bugs reports, but never pushed too much)
I could never understand why, hope it would be resolved with some updates. Even with the bump to kernel 6.6, i tried, no success
It is perfectly readable by another linux computer.
So, i would be interested having more details…
PS: it is connected through USB
Renaming the label, Volumio understands it’s a physical mounted drive and needs to scan it for music… However connected via USB Volumio just see it as a USB device, in this case label is not needed.
If you’re drive is failing, please post a log, as otherwise it will be a guessing game.
- Remove the USB drive from your system.
- Reboot you divice, leave the M2 unconnected
- Wait until Volumio is fully loaded
- Connect the USB drive and send the log.
Ok, i will do as suggested.
(renaming to “issd” didn’t do anything, and for the time being, i always plugged the USB drive prior to powering Volumio)
Edit: here are the log http://logs.volumio.org/volumio/TUbR9mK.html
[didn’t work: no music seen]
@nerd
Can you take a look, seems a driver issue?
Apr 14 06:53:10 volumio kernel: usb 1-1.5: new high-speed USB device number 5 using dwc_otg
Apr 14 06:53:10 volumio kernel: usb 1-1.5: New USB device found, idVendor=174c, idProduct=0850, bcdDevice= 0.31
Apr 14 06:53:10 volumio kernel: usb 1-1.5: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Apr 14 06:53:10 volumio kernel: usb 1-1.5: Product: X850 V3.1
Apr 14 06:53:10 volumio kernel: usb 1-1.5: Manufacturer: SupTronics
Apr 14 06:53:10 volumio kernel: usb 1-1.5: SerialNumber: 20200100003F
Apr 14 06:53:10 volumio kernel: usb 1-1.5: The driver for the USB controller dwc_otg_hcd does not support scatter-gather which is
Apr 14 06:53:10 volumio kernel: usb 1-1.5: required by the UAS driver. Please try an other USB controller if you wish to use UAS.
Apr 14 06:53:10 volumio kernel: usb-storage 1-1.5:1.0: USB Mass Storage device detected
Apr 14 06:53:10 volumio kernel: scsi host0: usb-storage 1-1.5:1.0
Hey @laluciol6990, @Wheaten,
The SSD is being detected by the kernel, and storage initialization proceeds cleanly:
usb 1-1.5: Product: X850 V3.1
usb 1-1.5: Manufacturer: SupTronics
usb 1-1.5: The driver for the USB controller dwc_otg_hcd does not support scatter-gather
usb 1-1.5: required by the UAS driver. Please try another USB controller if you wish to use UAS.
usb-storage 1-1.5:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-1.5:1.0
sd 0:0:0:0: [sda] 512 GB
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled
sd 0:0:0:0: [sda] Attached SCSI disk
This shows that:
- The USB controller does not support scatter-gather, so UAS is skipped, but
- The fallback to usb-storage works correctly
- A block device
/dev/sdais created and attached
This confirms the hardware stack is working at the kernel level. There is no driver failure, no I/O error, and no enumeration fault. At this stage, there is no reason to suspect a driver compatibility issue as the device is handed off to sd and fully attached.
What is missing from the log is any mention of:
- Partition discovery (e.g.,
sda1,sda2, etc.) - Filesystem type detection (e.g., ext4, exfat, ntfs)
- Filesystem mount messages or udev involvement
This suggests the SSD may not contain a recognizable partition table, or the partitions are present but in an unsupported format, or without a label.
To understand why your SSD isn’t showing up in Volumio, we need to inspect what the system sees on the device. Please follow these steps:
Check SSD Structure from Volumio
-
Connect via SSH
-
Use an SSH client (like PuTTY on Windows, or Terminal on macOS/Linux)
-
Connect to your Volumio device using its IP address
-
Login as:
username: volumio password: volumio
-
-
Run disk listing command
Type the following and press Enter:
sudo lsblk -fThis will list all storage devices, partitions, and filesystem types.
-
Check for filesystem labels and types
Then run:
sudo blkidThis will show filesystem details like UUIDs, labels, and partition formats.
-
Post the output
Copy and paste both outputs (
lsblk -fandblkid) back here in full. This tells us:- If the SSD has partitions
- If it’s formatted in a usable format (like FAT32, exFAT, ext4, etc.)
- If it has a label that Volumio expects
Once we have this information, we can explain exactly why it’s not showing up.
Until that’s confirmed, there’s no point discussing labels or mount paths — the block layer shows the disk, but nothing yet confirms that Volumio has anything to mount or scan.
Kind Regards,
Hi
Thanks for the directions to provide infos.
Results of 1st command “sudo lsblk -f”
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs 0 100% /static
sda ext4 issd 9b631dcf-fbd2-4dc5-b596-7f7e4eea916b
mmcblk0
|-mmcblk0p1 vfat boot F663-2A72 7.8M 91% /boot
|-mmcblk0p2 ext4 volumio f4d8320a-f5aa-4b94-8af9-4085ebdfe8c4 1.2G 46% /imgpart
`-mmcblk0p3 ext4 volumio_data 460a119c-2cff-496a-b400-8fb4dd33fb65
mmcblk0boot0
mmcblk0boot1
Results of the command “sudo blkid”
/dev/mmcblk0p1: LABEL_FATBOOT=“boot” LABEL=“boot” UUID=“F663-2A72” TYPE=“vfat” PARTUUID=“5a66c742-01”
/dev/loop0: TYPE=“squashfs”
/dev/mmcblk0: PTUUID=“5a66c742” PTTYPE=“dos”
/dev/mmcblk0p2: LABEL=“volumio” UUID=“f4d8320a-f5aa-4b94-8af9-4085ebdfe8c4” TYPE=“ext4” PARTUUID=“5a66c742-02”
/dev/mmcblk0p3: LABEL=“volumio_data” UUID=“460a119c-2cff-496a-b400-8fb4dd33fb65” TYPE=“ext4” PARTUUID=“5a66c742-03”
/dev/sda: LABEL=“issd” UUID=“9b631dcf-fbd2-4dc5-b596-7f7e4eea916b” TYPE=“ext4”
Additionnal info
Looking for problem with this Suptronic board, some mentionned not being able to use UAS at some point, because of the a chip JMS578, and there were posts showing how to update the firmware to do so.
I have not done so yet and it doesn’t seem necessary given that you mention " * o UAS is skipped, but
- The fallback to usb-storage works correctly"
Reference, just for info https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update#how_to_use
(hope this help and doesn’t mess with the analysis)
Hey @laluciol6990,
The SSD is formatted with ext4 directly on /dev/sda, with no partition table. This is valid in Linux, but Volumio requires a partitioned disk for automount to work.
We see:
sda ext4 issd
No sda1, which means there’s no partition - just a raw filesystem on the whole device.
Volumio’s automount logic expects:
- A partition table (MBR or GPT)
- At least one filesystem-bearing partition
- A label on that partition
Fix: Repartition and Format with parted
Connect the SSD to a Linux PC or SSH into Volumio.
Warning: This will erase all data on
/dev/sda.
sudo parted /dev/sda --script mklabel msdos
sudo parted /dev/sda --script mkpart primary ext4 0% 100%
sudo mkfs.ext4 -L issd /dev/sda1
Then power down your Volumio, if you can, disconnect power for 5-15s; then power back up.
After starting Volumio: Check Again
SSH into Volumio and run:
lsblk -f
sudo blkid
Now you should see something like:
sda
└─sda1 ext4 issd ...
Post the updated output before we proceed to verify mount location and music visibility.
Kind Regards,
Hi.
I did similar actions from another Linux PC using PARTED GUI.
Only issue i ran into was changing the ownership of the drive but it is now connected, recognized and synchronizing files from disk called “mSata”. (screenshot of music files being recognized)
Thank you very much for your help!
lsblk -f returns
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs 0 100% /static
sda
-sda1 ext4 mSata c55a7d38-d71f-4bcf-a3e3-8434c1bc12ab 437.2G 2% /media/mSata mmcblk0 |-mmcblk0p1 vfat boot F663-2A72 7.8M 91% /boot |-mmcblk0p2 ext4 volumio f4d8320a-f5aa-4b94-8af9-4085ebdfe8c4 1.2G 46% /imgpart -mmcblk0p3 ext4 volumio_data 460a119c-2cff-496a-b400-8fb4dd33fb65
mmcblk0boot0
mmcblk0boot1
sudo blkid returns
/dev/mmcblk0p1: LABEL_FATBOOT=“boot” LABEL=“boot” UUID=“F663-2A72” TYPE=“vfat” PARTUUID=“5a66c742-01”
/dev/loop0: TYPE=“squashfs”
/dev/mmcblk0: PTUUID=“5a66c742” PTTYPE=“dos”
/dev/mmcblk0p2: LABEL=“volumio” UUID=“f4d8320a-f5aa-4b94-8af9-4085ebdfe8c4” TYPE=“ext4” PARTUUID=“5a66c742-02”
/dev/mmcblk0p3: LABEL=“volumio_data” UUID=“460a119c-2cff-496a-b400-8fb4dd33fb65” TYPE=“ext4” PARTUUID=“5a66c742-03”
/dev/sda1: LABEL=“mSata” UUID=“c55a7d38-d71f-4bcf-a3e3-8434c1bc12ab” TYPE=“ext4” PARTUUID=“88737db6-01”
I can send a new log file if needed.
Origin of the problem (i think)
- I was using “Disks” from the distribution to format and create filesystems
(i always was) I never really created a partition with it, just the file system - It may not have been an issue in the past (Volumio 2.x… ? or previous version of “Disks” create a partition automatically?)
- Something changed
- Now, i would always use Parted for drive initialization/setup/partitionning
Thank you very much!
Hey @laluciol6990,
Glad it worked. For completeness of the analysis i would very much welcome new set of the debug logs. If I am not mistaken, there was a warning thrown with voltage under-run. With USB attached storage this is a “ticking bomb” with corruption waiting to happen.
Kind Regards,
Hi
Here it is : http://logs.volumio.org/volumio/dwQx8eO.html
(i have used this setup with Volumio 2 for years without much issues, until at some point, the USB-mounted ssd stopped being recognized / i didn’t set it up correctly after formatting. Raspberry Pi + Allo Kali Reclocker + Piano Dac 2.1. PSU connected to the Allo modules powering everything. PSU is 5V-3A, inittially from Allo but their basic offering)
Regarding the “Disks” / “Parted” tools, the discussion here is right on point:
https://forums.linuxmint.com/viewtopic.php?p=2535074&sid=66130102b77971ede0af049505f78964#p2535074
(just if it helps people some day)
Hey @laluciol6990,
Thanks for the log. This line stands out immediately:
Apr 14 16:33:34 volumio kernel: hwmon hwmon1: Undervoltage detected!
This is a hardware-level report from the Raspberry Pi’s PMIC (Power Management IC). It means at some point the core voltage dropped below safe thresholds, which can result in:
- Unreliable USB bus behavior
- Drive detection failures
- Audio glitches or crashes
- Filesystem corruption if writes are interrupted
Undervoltage = Unreliable Behavior
This matters especially in your case:
- You’re powering a Raspberry Pi 5, which draws more current than previous models
- You’re also powering:
- Allo Kali reclocker
- Allo Piano DAC 2.1
- A connected M.2 SSD via USB
- All are sensitive to voltage stability
Even if it worked in the past with Volumio 2, the new setup with updated raspberry Pi, updated kernel, new boot firmware, or added USB load may cross the critical threshold.
What I Need from You
Please describe your entire power path, in detail:
-
PSU
- Brand/model
- Exact output rating (label), e.g. 5V 3A
- Whether it’s shared or dedicated to the Pi
-
Connection Path
- How is power delivered to the Pi? (USB-C? GPIO? Header on Kali?)
- Where are the Allo boards getting power from?
- Are any GPIO pins used to inject or distribute 5V?
- How is the SSD powered - directly from USB port? Is a powered hub used?
-
Cabling
- Include any splitters, jumpers, or backfeed scenarios
- Cable types and lengths (important for voltage drop)
Example of a good answer:
PSU is Allo 5V/3A → DC barrel into Kali 5V input. Power is then passed via GPIO to RPi 5. SSD is plugged into USB 3.0 and powered from Pi directly. No powered hub.
Once I see the power layout, I’ll tell you exactly where the risk point is - and whether undervoltage is triggering SSD detection failure or something else.
Also, once we confirm power is stable, we can re-test SSD behavior cleanly.
Kind Regards,
Yes, we’re already aware of the discussion and we are past that point.
The shell method using parted + mkfs.ext4 directly resolves the exact pitfalls described in that thread:
- MBR table is now present
- Partition is correctly defined and formatted
- Filesystem is valid and labeled (
issd)
All of Volumio’s automount expectations are now met - no need for graphical tools or guesswork.
Kind Regards,