Thank you I’ll try to install now!
Hi guys,
Sorry to bother you with a retreated argument, but I’m going crazy and looking for help!
I have a raspberry PI 4 B 2GB updated to latest firmware as the guide suggests.
I can’t see in any way in the “system menu” option to transfer OS to USB, I tried connecting empty drives or FAT32 pen drive.
SO i flashed directly USB NVME adapter with a 500 GB drive and system booted, taking an age to have system available to SSH, 1min and 36 seconds and a little bit more 1min and 44 to have GUI (now playing) interface.
I managed to change boot order and set USB as first device:
BOOT_ORDER=0xf14
but loading time does not change, 30 / 40 seconds are lost without any activity on USB disk then starts and i can see Volumio logo on 1920X480 display, (Unable to see info at boot).
Reboot hangs the system, even after trying different values on
USB_MSD_PWR_OFF_TIME=2000
USB_MSD_STARTUP_DELAY=5000
But I can live without it!
thanks in advance for the help!
Alberto
Hey @Ciriola,
Volumio OS currently does not offer an option to directly transfer the OS to USB storage through the system menu. The “Install to Disk” feature is only available for directly attached storage (like a NVMe or SSD), not removable storage like USB drives. There’s no need to first flash Volumio to an SD card and then move it to a USB device. You can simply flash Volumio directly to USB storage in one step.
Many users also keep Volumio OS on a MicroSD card while using USB storage as their music library. Offering the ability to write directly to USB from within the system could cause issues — such as loss of the music library — as the process is irreversible.
The delay you’re experiencing is likely due to bandwidth limitations of the Raspberry Pi 4’s USB ports. All four USB ports share a single PCIe lane with a 4Gbps bandwidth. Additionally, the available power is limited to 1.2A, shared across all USB ports. Given that USB 3.0 SSDs can draw up to 900mA per port, these factors can contribute to slower performance.
Questions for Clarification:
- What is the exact model of your USB to NVMe adapter?
- Could you provide the specifications of the NVMe drive you’re using, and how it matches the available bandwidth?
- Are there any other devices connected to the Pi’s USB ports?
Additional Notes:
Time perception can be subjective. While USB-attached storage works, the actual performance depends heavily on the underlying hardware and system configuration. The “gluing” mechanism for USB storage is managed by the Raspberry Pi firmware, but performance benchmarks are often based on community contributions rather than official technical specifications.
Additionally, there’s ongoing debate about the resilience of USB storage versus MicroSD for running Volumio OS, but both options have their pros and cons.
Final Thoughts:
Don’t get discouraged. It’s easy to fall into the trap of misinformation online, even when the intention behind it is good. Verified technical specs and controlled environment tests are key to understanding performance limitations. If you have more details or questions, feel free to ask!
Kind Regards,
Thank you so much, nerd for you fast and so detailed reply,
got it!
this is not an exact science! 
My goal was to have a faster boot, as the SSD was already connected as storage for the songs,
I guess devices I used are working but not excellent, NVME adapter is chinese, and uses JMS583 USB 3.1 Gen 2 to PCIe Gen3x2 Bridge Controller
Also the drive is a "500GB Union Memory "coming from discontinued laptop, I have a second 250 GB ssd from Samsung which could be better, but i don’t think performance willincrease!.
Thanks and have a good WE.
Ciriola
The Raspberry Pi 4B has known issues with certain USB storage controllers, particularly when it comes to rebooting. These issues can cause devices to fail detection after a reboot or lead to boot failures when using USB storage as the boot device. Here are the main culprits:
1. JMicron JMS578 & JMS583 Controllers
- Symptoms: USB drive fails to be detected after a warm reboot (
sudo reboot), but works after a cold boot (power cycle). - Cause: These controllers have issues handling UAS (USB Attached SCSI) mode on Raspberry Pi 4.
- Workarounds:
- Disable UAS by adding
usb-storage.quirks=152d:0578:u(for JMS578) or152d:0583:u(for JMS583) to/boot/cmdline.txt. - Use a different firmware: Some JMS583 adapters allow firmware updates that can improve compatibility.
- Switch to a different USB-to-SATA adapter.
- Disable UAS by adding
2. ASMedia ASM1153 & ASM235CM Controllers
- Symptoms: Similar to JMicron, may disappear after a reboot, requiring a power cycle.
- Cause: UAS issues and power reset problems.
- Workarounds:
- Disable UAS with
usb-storage.quirks=174c:1153:u(for ASM1153) or174c:235c:u(for ASM235CM). - Try different firmware updates if available.
- Disable UAS with
3. Realtek RTL9210 & RTL9210B
- Symptoms: Failure to reconnect after a soft reboot, and sometimes boot failure when used as a boot drive.
- Cause: Firmware bugs in early versions.
- Workaround:
- Update firmware to the latest version (use Realtek’s update tools).
- Disable UAS with
usb-storage.quirks=0bda:9210:uif issues persist.
4. VIA VL715 & VL716
- Symptoms: May fail after reboot, especially when using NVMe enclosures.
- Cause: Power management issues with Raspberry Pi 4’s USB controller.
- Workaround: Use powered hubs or update firmware.
5. Generic USB-to-SATA Bridge Chips (Unknown Vendor)
- Symptoms: Some cheap adapters don’t work reliably and may disappear on reboot.
- Cause: Poor firmware or bad power handling.
- Workaround: Use a powered USB hub or a better-known controller.
General Recommendations
-
Use Known Good Adapters:
- StarTech USB3S2SAT3CB (works well with RPi 4).
- Sabrent EC-SS31 (compatible without quirks).
- UGREEN SATA to USB 3.0 adapter (some models are OK, but check the chipset).
-
Disable UAS for Problematic Controllers:
- Find the device ID with:
lsusb - Add the quirk to
/boot/cmdline.txt:usb-storage.quirks=152d:0578:u
- Find the device ID with:
-
Use a Powered USB Hub:
If power issues are suspected, a USB hub with external power can help stabilize certain drives. -
Update Raspberry Pi Firmware:
- Ensure you’re running the latest firmware by updating EEPROM (as explained in the first section of this thread):
sudo rpi-eeprom-update -a
- Ensure you’re running the latest firmware by updating EEPROM (as explained in the first section of this thread):
Would you like help checking your specific USB controller? Let me know what lsusb shows!
DISCLAIMER:
OTA upgrade will overwrite /boot/cmdline.txt and your changes will be lost.
Kind Regards,
Sure thing, which this entire thread is all about
just got a bit confused by adding stuff to cmdline,txt on raspbian,
So not sure which image it was related to,
Issue is also valid for some USB Thumbs from Sandisk.
9 out of 10 times it fails to reboot:
ID 0781:5583 SanDisk Corp. Ultra Fit
ID 0781:55a3 SanDisk Corp.
1 Like
Thanks, dear @nerd ,
checked your last post in “Prepare Raspberry Pi for boot from USB” but cannot identify how to identify the chipset.
Currently this is a Sandisk USB Stick - so Bus 2, device 2, I guess…
volumio@volumio:~$ lsusb
Bus 002 Device 002: ID 0781:5588 SanDisk Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1997:2433
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
You wrote in your posting:
Find the device ID with:
lsusb
Add the quirk to /boot/cmdline.txt:
usb-storage.quirks=152d:0578:u
I cannot identify where I have to place the device ID in the quirk … ???
Additional question: Volumio Install doesn’t have/know rpi-eeprom-update.
So I have to boot the Pi with an other SD card, right?
And rpi-eeprom-update writes in the hardware which persists - even if I change back to volumio boot?
Do you have an idea why touch functionality disappears in my SD card installation?
Warmest regards,
Ralf
Hey @rkorell,
Moved discussion to the USB storage preparation thread…
Please re-visit first post in this thread as it discusses use of the rpi-eeprom-update in details.
Please compare side-by-side USB ↔ MicroSD content of:
/boot/cmdline.txt
/boot/config.txt
/boot/volumioconfig.txt
/boot/userconfig.txt
Please do not copy over from one to another as it will break unique to each storage device partition’s UUIDs.
Kind Regards,
1 Like
OK, was not sure where to post - thanks for guidance.
You mean the four files in /boot ?
I initially cloned SD-card to USB-SDD - so I guess their UUIDs are the same.
This should not be a problem - they will NOT being present simultaneously in the same system.
I do NOT have copied the config-files (only modified cmdline.txt & userconfig.txt) but entered the proposed lines in SSH-enabled nano editor locally.
First on the USB device - this works.
Than switched back to SD-card (because reboot doesn’t work) and do on this card the exact same modifications - again via SSH / nano in exact same files …
I will follow your advise and reagardless my assumptions compare the four files side by side.
This will take a while because currently the USB SSD is inserted and I’m away from hardware so cannot switch currently…
Will report later on.
Thanks for your great and kind support!
Ralf
OK; status update…
as expected there is no difference in any of the file-pairings.
(to be honest: two times a space and a tiny difference in one comment but nothing practical important)
BUT: GOOD news: Touch now is working… ???
Yesterday the error survived six reboots with several delays in between.
Today a loooooong period off time.
After reboot - touch worked.
Spooky but at least things are now as they should be and I’m fine.
Thanks for your effort especially for “no reason” !!!
Warmest regards,
Ralf
Hey @rkorell,
This is interesting development indeed. I wonder if there are some powering variances at play. Perhaps it is worth checking. Whilst logged in with ssh client:
dmesg | grep -i voltage
Anything starting with under… or over… is concerning.
sudo vcgencmd version
Any older version than JUNE 2024 may simply be not aligned with newer kernels.
sudo vcgencmd get_throttled
0x50000→ Undervoltage detected.0x20000→ Underclock due to undervoltage.0x0→ Normal.
sudo vcgencmd measure_volts
Not sure if this will reveal anything if none of the previous steps shows anything wrong.
Kind Regards,
1 Like
indeed…
I could imagine an undervoltage when USB SSD is attached - so the opposite behaviour (SD card woks and USB device not) came “plausible” but it was opposite: SD card doesn’t work but USB stick works…
So to no surprise the voltage checks don’t show anything:
volumio@volumio:~$ dmesg | grep -i voltage
volumio@volumio:~$ sudo vcgencmd version
Nov 11 2024 15:48:13
Copyright (c) 2012 Broadcom
version 903570ba72a9e117f92e5499de439f59dd96e417 (clean) (release) (start)
volumio@volumio:~$ sudo vcgencmd get_throttled
throttled=0x0
volumio@volumio:~$ sudo vcgencmd measure_volts
volt=0.8600V
volumio@volumio:~$
To get both: more “security” (reliability) by avoiding SD-card AND can perform an reboot I’ve ordered an other combination of controller/harddisk and will see what will happen (ETA for hardware: tomorrow).
Dear @nerd ,
My new devices are arrived in the meantime.
This is EasyULT M.2 USB Adapter and KINGDATA SSD M.2 2242 SSD.
Today I followed your detailed description here in this thread (thanks for this) but unfortunately without success.
Initially I had some problems to install the newest firmware (my fault - I’ve tried a Buster image and got a 2023 release as latest.)
With bookworm version checked and updated now my EEprom is on Februar release, 2025:
pi@raspi5:~ $ sudo rpi-eeprom-update
BOOTLOADER: up to date
CURRENT: Di 11. Feb 17:00:13 UTC 2025 (1739293213)
LATEST: Di 11. Feb 17:00:13 UTC 2025 (1739293213)
RELEASE: latest (/usr/lib/firmware/raspberrypi/bootloader-2711/latest)
Use raspi-config to change the release.
VL805_FW: Using bootloader EEPROM
VL805: up to date
CURRENT: 000138c0
LATEST: 000138c0
Current Status: sudo reboot works (from USB) with standard Raspbian (edit: Buster) …
Doesn’t work with Volumio System on same USB device …
I’ve even tried your suggestions for
USB_MSD_PWR_OFF_TIME=0
or
USB_MSD_PWR_OFF_TIME=1000
or
USB_MSD_PWR_OFF_TIME=1000
USB_MSD_STARTUP_DELAY=3000
So last resort seems now
Find the device ID with:
lsusb
Add the quirk to /boot/cmdline.txt:
usb-storage.quirks=152d:0578:u
But with this advise I’m struggling because I don’t understand how to use the Device ID with the quirk statement and which one of the statements to use …
Any additional idea?
Thanks and warm regards,
Ralf
Hey @rkorell,
I think we are at wits end. At least for now.
One thing I wonder about:
standard Raspbian (Butcher)
If this is meant Buster - Volumio OS is on full freeze and only critical backend quirks are looked into.
If this is meant Bookworm - Volumio OS is undergoing development, currently alpha builds, not for share with the community yet.
Kind Regards,
indeed, this meant: Buster.
Sorry.
I’ve tried this because I got the impression that current Volumio based on Buster…
Ralf
1 Like
Seems failing to reboot is specific to Volumio on a rPi4. (rpi5 it works without quircks)
These thumbs reboot without issues when running raspbian.
I’ve updated the bootloader, added quirks (usb-storage.quirks=0781:5583:u, usb-storage.quirks=0781:55a3:u), modified boot sequences (BOOT_ORDER=0xf41, which are not used with Raspbian).
But reboot fails. Since Raspbian handles them without issues, seems something is missing in the Volumio image.
1 Like
Dear @Wheaten ,
Yes this seems to be true.
I have tried to reboot on same USB device with another Raspi-Image - works without any tweaking…
Just considering to use a Raspi5 - currently not sure what additional problems this will arise (display, USB remote …)
May give it a try.
This weekend I will finish my MagicMirror Project and will use beautiful weather for some recumbent trike trips …
So Volumio may the very next weekend…
Nevertheless: Thanks a LOT for your always great and kind support.
Kindest regards,
Ralf