Public Alpha Test: Audio Without Compromise - Volumio on Bookworm Begins

Volumio Development Volumio Beta Testing
, , , ,
102

Hey @Robert.Hecht,

Thanks again for the detailed update.

Before reflashing manually, could you please try one more thing if you attempt the OTA update again:

  • After the OTA process finishes and the 15-second reboot countdown appears,
  • Quickly open http://<your-device-ip>/dev in your browser,
  • Click “Send Log” before the reboot occurs,
  • Then share the log link here.

This way, we might capture valuable information about what is happening immediately after the update process, before the system restarts.
It would help us better understand if the issue is during the update application phase.

If not possible or if the reboot is too fast, no problem - in that case, manual reflash remains the safe path.

Kind Regards,

103

Hi @nerd ,
here comes the log
http://logs.volumio.org/volumio/0tqgjrG.html
after OTA before reboot.

104

Hey @Robert.Hecht,

Thanks again for providing the logs - it’s very helpful.

Apr 27 20:04:38 smx volumio-remote-updater[8772]: reading seed file kernel_current.tar: IO error: No space left on device
Apr 27 20:04:38 smx volumio-remote-updater[807]: zsync done
Apr 27 20:04:38 smx volumio-remote-updater[807]: PROGRESS: 90, STATUS: "Cleaning old files", ETA: "1m"

From the log details, the OTA update failed because of a “No space left on device” error during the staging of the update files.
This caused the update process to exit early even though the UI still showed a completion message.

As a next step, before reflashing manually, you might want to check the available disk and partition sizes via SSH:

  • Connect to your device with SSH.
  • Run the command:
    df -h
    This will show the size and free space of all mounted partitions.

We are particularly interested in the partition used for /imgpart (where OTA staging happens) and root (/).

If the /imgpart partition is low on space or fragmented, it would explain why the OTA could not complete.

If space is tight, a manual reflash of the 0.061 image is the safe solution to restore a clean and stable setup.

Kind Regards,

105

Hi @nerd

volumio@smx:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           379M  6.3M  373M   2% /run
/dev/sdc2       3.3G  3.1G     0 100% /imgpart
/dev/loop0     1004M 1004M     0 100% /static
overlay          51G   87M   48G   1% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
efivarfs        128K   61K   63K  50% /sys/firmware/efi/efivars
tmpfs           1.9G   48K  1.9G   1% /tmp
tmpfs            20M   48K   20M   1% /var/log
tmpfs           1.9G     0  1.9G   0% /var/spool/cups
tmpfs           1.9G     0  1.9G   0% /var/spool/cups/tmp
/dev/sdc1       169M   66M  103M  39% /boot
/dev/sdb1       932G  781G  151G  84% /media/T7
tmpfs           379M     0  379M   0% /run/user/1000
volumio@smx:~$
volumio@smx:/imgpart$ ls -al
total 3208549
drwxrwxrwx 3 root    root          4096 Apr 27 20:04 .
drwxrwxrwx 1 root    root          1024 Apr 24 22:51 ..
-rwxrwxrwx 1 root    root      68514816 Apr 24 22:51 kernel_current.tar
-rwxrwxrwx 1 volumio volumio   68514816 Apr 24 22:51 kernel_fallback.tar
drwxrwxrwx 2 root    root         16384 Apr 24 15:19 lost+found
-rwxrwxrwx 1 volumio volumio          0 Apr 27 20:04 rcksum-xdBZVZ
-rwxrwxrwx 1 root    root           141 Apr 24 15:22 remoteConfig
-rwxrwxrwx 1 root    root    1052258304 Apr 24 15:24 volumio_current.sqsh
-rwxrwxrwx 1 volumio volumio 1050402816 Apr 27 20:04 volumio_current.sqsh.part
-rwxrwxrwx 1 volumio volumio 1052258304 Apr 24 15:24 volumio_fallback.sqsh
volumio@smx:/imgpart$
106

Hey @Robert.Hecht,

Thanks for checking and sharing the partition and /imgpart contents - this makes the situation very clear.

The issue is exactly what we suspected:
Your /imgpart is completely full (100%) because leftover files from previous updates are still present.

Specifically, these large files are blocking space:

  • kernel_fallback.tar
  • volumio_fallback.sqsh
  • volumio_current.sqsh.part (incomplete download)

Before trying OTA again, you should manually clean up /imgpart:

Here is what you can safely delete:

sudo rm /imgpart/kernel_fallback.tar
sudo rm /imgpart/volumio_fallback.sqsh
sudo rm /imgpart/volumio_current.sqsh.part

After that, run:

df -h

again to confirm that /imgpart now has free space (should be around 1.2 GB or more available).

Only then, retry the OTA update.

If space does not clear properly or if you prefer, flashing the USB manually with 0.061 is still a safe solution.

Still, I need to understand why sqsh has size exceeding ~700MB.

Kind Regards,

107

Hi @nerd ,
I wonder where these files come from because I did flash a 0.060 manually and did not update via OTA before… Anyway:

volumio@smx:~$ sudo rm /imgpart/kernel_fallback.tar
volumio@smx:~$ sudo rm /imgpart/volumio_fallback.sqsh
volumio@smx:~$ sudo rm /imgpart/volumio_current.sqsh.part
volumio@smx:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           379M  7.6M  371M   3% /run
/dev/sdc2       3.3G  1.1G  2.1G  35% /imgpart
/dev/loop0     1004M 1004M     0 100% /static
overlay          51G   87M   48G   1% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
efivarfs        128K   61K   63K  50% /sys/firmware/efi/efivars
tmpfs           1.9G   48K  1.9G   1% /tmp
tmpfs            20M   88K   20M   1% /var/log
tmpfs           1.9G     0  1.9G   0% /var/spool/cups
tmpfs           1.9G     0  1.9G   0% /var/spool/cups/tmp
/dev/sdc1       169M   66M  103M  39% /boot
/dev/sdb1       932G  781G  151G  84% /media/T7
tmpfs           379M     0  379M   0% /run/user/1000
volumio@smx:~$

The log after the OTA before the reboot:
http://logs.volumio.org/volumio/bTtMovB.html

The log after the reboot - it’s still 0.060 active… And 0.061 is still offered by OTA…
http://logs.volumio.org/volumio/pBicMEG.html

After this procedure the file system shows up like this:

volumio@smx:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           379M  6.2M  373M   2% /run
/dev/sdc2       3.3G  3.1G     0 100% /imgpart
/dev/loop0     1004M 1004M     0 100% /static
overlay          51G   87M   48G   1% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
efivarfs        128K   61K   63K  50% /sys/firmware/efi/efivars
tmpfs           1.9G   48K  1.9G   1% /tmp
tmpfs            20M   48K   20M   1% /var/log
tmpfs           1.9G     0  1.9G   0% /var/spool/cups
tmpfs           1.9G     0  1.9G   0% /var/spool/cups/tmp
/dev/sdc1       169M   66M  103M  39% /boot
/dev/sda1       932G  781G  151G  84% /media/T7
tmpfs           379M     0  379M   0% /run/user/1000
volumio@smx:~$ ls -lh /imgpart/
total 3.1G
-rwxrwxrwx 1 root    root      66M Apr 24 22:51 kernel_current.tar
-rwxrwxrwx 1 volumio volumio   66M Apr 24 22:51 kernel_fallback.tar
drwxrwxrwx 2 root    root      16K Apr 24 15:19 lost+found
-rwxrwxrwx 1 volumio volumio     0 Apr 28 07:39 rcksum-osS92y
-rwxrwxrwx 1 root    root      141 Apr 24 15:22 remoteConfig
-rwxrwxrwx 1 root    root    1004M Apr 24 15:24 volumio_current.sqsh
-rwxrwxrwx 1 volumio volumio 1002M Apr 28 07:38 volumio_current.sqsh.part
-rwxrwxrwx 1 volumio volumio 1004M Apr 24 15:24 volumio_fallback.sqsh
volumio@smx:~$

Cheers, Robert

108

Hey @Robert.Hecht ,

Thank you very much for the detailed investigation and logs.

I have assessed the storage layout situation specifically for x86 Alpha builds.
Unfortunately, the size increase you are seeing is inevitable.

The root cause is that we are still constrained by Volumio V3 partitioning requirements, which were originally optimized for much smaller system images and update packages (typically under 700-800MB).
Today, with Bookworm, larger kernels, updated libraries, and updated squashfs compression, the Alpha system image is significantly bigger - and the current /imgpart layout is simply no longer sufficient without manual cleanup between updates.

In short:

  • The current 3.3GB /imgpart partition is a legacy limit.
  • Alpha system images are now close to 1GB compressed, and with fallback and update in flight, we simply run out of space.
  • We already heavily compress the squashfs and kernel artifacts, so there is no simple fix by optimization alone.

For now:
After every OTA, it is necessary to manually clean /imgpart (removing fallback .sqsh and .tar files) before retrying an update.
In the future, we will need to design a new partitioning scheme for x86 to properly accommodate these larger images - but this would require a reflash anyway, not a live update.

Thank you again for your careful and valuable testing. It really helps us map the next steps clearly.

Kind regards,

1 Like
109

Hi @nerd ,
finally I had to flash the 0.061 manually (my fault - I deleted one file too much - volumio_current.sqsh). :wink:
Now 0.061 is running and I’ll report again when OTA updating to 0.062 ff.
Cheers,
Robert

110

We had a similar issue when migrating from V2 to V3, and for these technical reasons we decided not to offer an upgrade path. Everybody reflashed their device.
As x86 is less of a DIY platform, it may be an acceptable solution when the root cause can not be solved.

111

i need to add:
This is clearly not a Bluetooth issue, it also happens while doing “play here” while the output path set to a usb audio DAC with hw volume control. So please interpret this as a remark, not a bug.
The initial wifi configuration issue has been located by @nerd, I could confirm the fix with a test image. It will be added to one of the next releases. It needs to go through internal QA as it would also affect the future released buster versions (we need to avoiding regression).

112

Hey @gkkpch,

I was halfway through scratching my brain and dissecting the Khadas Tone2 Pro USB quirks, wondering if Bluetooth had decided to join the party.
Good to cross it off the list.

Kind Regards,

113

The sensor is probably detected (In the kernel configuration Volumio enabled the same sensors as in a standard Ubuntu kernel), but there is no generic code implementing the rotation with X11.
This is outside my skill set, sorry.

114

Loaded up .061 on a RPi 5 16GB, Hifiberry DAC+ADC Pro. Issues: no mouse or pointer, no keyboard input. Music files 36,416 but after reboot only 7K+ show. Must rescan after each boot. Sounds great and no issues playing MP3, FLAC or DSD files.

Edit: sorry I forgot, no wifi setup until I used network cable to router, then rebooted and got wifi connect set up.

Edit; after another rescan and reboot only 636 files show.

I’ll give it another shot in beta. Rescans take forever just to do it after each reboot.

115

Hey @dave99,

Thanks for giving 0.061 a spin and sharing your observations.

Unfortunately, without logs it’s very difficult for us to investigate or confirm anything about the missing files, input device issues, or Wi-Fi behavior you reported.
Logs are critical at this stage to catch early issues before they disappear after reboot or rescans.

If you decide to give it another shot later, it would really help if you could:

  • Open http://<your-volumio-ip>/dev after encountering an issue,
  • Click “Send Log” before rebooting,
  • Share the log link here.

That way we can properly track down what is happening in the background.

Kind regards,

116

So I wrote a backup of Volumio 3.802 on my SD card to test the screen rotation in the Touch Display plugin.
The screen rotation doesn’t work also.
Nothing specific to Bookworm.
Sorry for the false statement.

117

@MitchStoner

Please continue this conversation in the correct topic, as this is intended for Bookworm.

118

Good afternoon!

Dear @nerd,
I have to state: this is a masterpiece!
Congratulations and many, many thanks for your countless effort and your huge engagement on this!

Today I was able to install your latest bookworm alpha release and it works like a charm.
System Information:

OS info
Version of Volumio: 0.061
Hostname: korellmusik
Kernel: 6.6.62-v8+
Governor: conservative
Uptime: 0 days, 0 Hrs, 13 Minutes, 42 Seconds

Network info
Interface: wlan0
IP Address: xx.xxx.xx.xx
MAC Address: 2c:cf:6xxxxxxxx2
Type: wireless
Speed: nullMb/s

Audio info
Hw audio configured: HiFiBerry DAC2 Pro [Pi5]
Mixer type: Hardware
Number of channels: 2
Supported sample rate: 22050 44100 48000 88200 96000 176400 192000

Board info
Manufacturer:
Model: Raspberry Pi 5 Model B Rev 1.0 / /
Version: d04170 /
Firmware Version: 2025/02/12 10:51:52 version f788aab6 (release) (embedded)

CPU info
Brand: BCM2712
Speed: 2.4 GHz
Family: Cortex-A76
Model: 1
Number of cores: 4
Physical cores: 4
Average load: 23%
Temperature: 55°C

Memory info
Memory: 8147960 Ko
Free: 6219580 Ko
Used: 1928380 Ko

Software info
Mpd version: Music Player Daemon 0.24.3 (0.24.3)

Storage info
INTERNAL storage - Size: 54317Mo
Used: 1328Mo
Available for storage: 50095Mo (92%)

Additional Hardware in my setup:

HifiBerry DAC2 pro is listed above in system information.
In addition I have connected:

System installation went without any issue - Hotspot was created and I could connect, configure and restart. To my pleasure the locally connected display worked immediatly - without any additional step and shows up Volumio Logo and startup message (this in wrong direction, but this doesn’t matter to me)

Plugin installation first went wrong - by my own fault because I was confused and forgot to enable plugin-test-mode - which is clearly advised by you.
Second attempt went without any issue, as well.
I’ve installed the following plugins (in their respective order):

  • Touch-Display - works including correct screen rotation and touch-functionality
  • Spotify - works immediately
  • Rotary Encoder II - same config as before - works without any issue
  • Now Playing - Works out of the box
  • System Information - works (output above in System Information)

The BT remote connection was easy as on Buster, have used bluetoothctl as advised in this posting (and I am using a similar hardware).
To get this working I had modified /etc/triggerhappy/triggers.d/audio.conf and modified all entries from 1 to 0 (zero) - The list of button-names was appropriate but the channel doesn’t fit …
e.g.:

KEY_NEXTSONG 0 /usr/local/bin/volumio next 

instead of given entry:

KEY_NEXTSONG 1 /usr/local/bin/volumio next

The one and only “misbehaviour” I have identified so far is a not working reboot.
Could not figure out when and how but sometimes the system does the reboot (in terminal as well as in Volumio GUI) - sometimes not…
Hard to get a logfile for this…
For me this (in real life) doesn’t matter, too - because in “production” :slight_smile: environment a reboot is a seldom event and I do have a smart plug which I can switch off and on remotely …

What I had expected but is not true: I had assumed that startup on a raspi5 with bookwork will be a little bit faster but this is (currently) not the case. May becomes true if installed on NVME - alpha test environment is on SD-card because I do not want to kill my working copy and I’m not able to flash the alpha-image to NVME. (I’m sure this can be performed by a unix guru with magic commands but I’m far away from this and would need the raspi imager or balena etcher do do this for me… )

Thanks again for a great work!
Really impressive!

Warmest regards,
Ralf

119

Many thanks for your incredibly thorough test and detailed feedback - this is exactly the kind of real-world validation we hoped for at this stage.

It’s great to see everything from DSI and touch, to BT remote and plugins working as expected in your setup. Your clear reporting really helps us measure where things stand.

The reboot irregularity is noted - we’ll need to understand that behavior better, even if it’s infrequent. If you ever catch a reproducible pattern or are able to capture a log before a failed reboot, it would be a big help.

Thanks again for the time and effort. Much appreciated!

Kind Regards,

1 Like
120

Dear @nerd you’re really welcome!
I will try to capture some patterns of reboot-failures if possible.
Looking forward for upcoming updates - ever a reason for pushing reboot :slight_smile:

Just an additional information for your records:
I’ve told nonsense in the above posting - I do NOT have the Waveshare display - sorry this one is in another project.
For my Volumio I’m using the Raspberry Display 2.
Sorry for confusion and any inconvenience this might have caused!

Warmest regards,
Ralf

121

Hello I’m running a RPi 2B with an Isc2 DAC. Fresh install did not get a wifi hotspot .Second time I started with an ethernet cable. Played some music files and tried Radio Paradise Plugin . All Good . Cannot set up wireless network, I wonder if this USB wifi Dongle isn’t supported . It worked well with Volumio3
Log file reference http://logs.volumio.org/volumio/JVdtGjn.html