Can you lay your hands on a 32gb or another brand 16gb card and flash that then see if the problem continues?
I’m ahead of you, I ordered a 32GB card to be delivered tomorrow.
Cool cool.
I’ve put v2.673 onto a brand new 32GB microSD card. I’ve configured only Volumio Virtuoso, Qobuz, Tidal and Spotify.
The next time an update appears, I’ll return here to report.
Hi,
card size should not be an issue, I do all my tests with a bunch of 8Gb cards, works fine.
To speed things up a little, I’m going to suggest not to wait for a next update, instead do the following test.
There are 2 important things I need to know. I call them Check #1 and Check #2 later on. They should give us an idea whether your OTA update fails while creating the backup and preparing the new update, or whether something goes wrong when volumio reboots to execute the 2nd part of the update, before volumio boots a 2nd time to start the new version.
This is what I would like you to do with using a 2nd SD card.
- Remove your current Volumio SD card, I call this card #1.
- Take a 2nd SD card (card #2) and flash this older: volumio-2.655-2019-10-17-tinkerboard
- Boot your TB from card #2 and do the update from the system menu, you do not need to configure Volumio as this won’t have any influence.
- When the update is “done” and the system starts the reboots, immediately pull the power plug and remove card #2, put it in an SD card reader (e.g. the one you used for flashing).
- Boot the TB from card #1, when ready insert the SD card reader with card #2.
- SSH into your TB with the volumio user and create a folder
mkdir tmpmount - Confirm with
sudo mountthat your SD card is /dev/sda - then
sudo mount /dev/sda1 tmpboot
cd tmpboot
Check #1: does the folder have a file called “kernel_update”
- then
cd ..
sudo umount tmpboot
sudo mount /dev/sda2 tmpboot
cd tmpboot
Check number 2: does the folder have the following files:
kernel_current.tar, kernel_factory.tar, kernel_fallback.tar, volumio_current.sqsh, volumio_factory.sqsh and volumio_fallback.sqsh?
OK, there was a little confusion as you wrote two different folder names tmpmount and tmpboot. I stuck with tmpmount.
My primary card is SDA1 and the secondary one in the card reader is SDA2.
Check #1: Yes, the folder in SDA1 contains kernel_update
Check #2: No, the folder in SDA2 is empty
I hope this helps. Happy to do some more tests.
Raspberry PI3 B+ here, done what you asked for on a card with the previous version.
The first partition has a 0 size file called kernel_update and this is the content of the second one.
volumio@volumio:~$ ls -l tmpmount
total 1572460
-rw-r--r-- 1 volumio volumio 224 Dec 16 20:21 config.txt.bak
-rwxrwxrwx 1 root root 60689408 Jan 1 1970 kernel_current.tar
-rw------- 1 volumio volumio 60692480 Dec 16 20:23 kernel_current.tar.part
-rwxrwxrwx 1 root root 60689408 Jan 1 1970 kernel_factory.tar
-rwxrwxrwx 1 volumio volumio 60689408 Jan 1 1970 kernel_fallback.tar
drwxrwxrwx 2 root root 16384 Nov 14 12:29 lost+found
-rwxrwxrwx 1 root root 125 Nov 14 12:32 remoteConfig
-rwxrwxrwx 1 root root 352616448 Nov 14 12:40 volumio_current.sqsh
-rw------- 1 volumio volumio 353218560 Dec 16 20:23 volumio_current.sqsh.part
-rwxr-xr-x 1 volumio volumio 352616448 Dec 16 20:24 volumio_factory.sqsh
-rwxrwxrwx 1 volumio volumio 352616448 Nov 14 12:40 volumio_fallback.sqshinteresting, let’s give it a little more time to catch feedback
sorry about that, typed it from the top of my head and did not notice the mistake…
bit surprised with /dev/sda2 being empty, that should not be empty at all, otherwise you would not be able to boot at all, please check it again…
This is because the updater did not finish the download part of the update process properly.
Did you wait until the system requests you to reboot? Let it power down and then pull the plug before it restarts
I pulled the plug when there was the “reboot in n seconds” countdown so I thought all the process was over. If I’m not wrong there was also the option to stop the countdown and reboot now.
Anyway I’ll try again when I’m home.
yeah, it is difficult to get the right sport to pull the plug. best when it powered down, before the restart.
PI should give you a good few seconds before our initramfs fiddles with, and with that, changes our results from the first update part.
As a follow up to the above I’ve just updated to V2.692…
Volumio updated and rebooted automatically as part of the update process: Volumio is still showing the previous version number.
I manually restarted Volumio (twice): Volumio is still showing the previous version number.
I completely powered Volumio down and restarted it: The version number has now updated and is correct.
So, in essence, although Volumio is updating to the new version correctly it doesn’t report the correct (new) version number until it has actually been completely manually powered down and then restarted.
2.692 has just appeared. I’m going to try doing that now.
I have tried twice to update to 2.692 from 2.673, with a complete power cycle between both attempts. No joy with my Tinker Board S. It stays resolutely on 2.673.
I’m beginning to think Volumio is jinxed for me.
I’ve tried both performing the shutdown and just pulling the plug. Still no joy.
So, I repeated the process, waiting for the countdown to expire and the browser loose connection, waited another couple of seconds, disconnected the main etc etc… and got the same result I showed before.
Let me do an hypothesis: it seems to me rather improbable that the download did not complete because of a few seconds of early shutdown. Maybe the download process, which had to complete before the reboot, signaled erratically its completion, or the managing process didn’t catch it right.
I also tried an OTA on my current running version, the 12/1 release towards the 12/19 one, let it reboot and settle, verified that the old version was still showing on the “system” tab, then shutdown and mounted the card with the USB reader on the same Raspberry running Raspbian and the result is in the attached screenshot: a Midnight Commander window showing first and second partition of my current Volumio card after the failed OTA.
The kernel_update 0 bytes file has disappeared from the first partition, but the .part files with yesterday’s timestamp are still there in the second partition.
Hope this helps.
yes, this appears to be a problem, as you can see, the new volumio version (.sqsh) file still has an active download extension (.part) attached, so it is not complete and not renamed to volumio-current.sqsh, so the"old" current one gets booted. Something must have gone wrong here, but what?
Not having a failing system may be difficult to debug.
The next 2 weeks nothing will happen due to the festive season, I’ll follow up after New Year…
Is there any progress on this bug, please?
There have been two updates recently and it is incredibly annoying having to burn a new microSD card and re-enter all my settings each time.