Mar 12 22:07:18 volumio-p volumio[710]: info: CoreCommandRouter::volumioGetState
Mar 12 22:07:18 volumio-p volumio[710]: info: CorePlayQueue::getTrack 0
Mar 12 22:07:18 volumio-p ntpd[850]: Listen normally on 3 eth0 192.168.2.136:123
Mar 12 22:07:18 volumio-p ntpd[850]: new interface(s) found: waking up resolver
Mar 12 22:07:39 volumio-p systemd[1]: systemd-fsckd.service: Succeeded.
Mar 12 22:07:40 volumio-p systemd[1]: systemd-hostnamed.service: Succeeded.
Mar 12 22:07:42 volumio-p volumio[710]: error: Plugin system_controller system failed to complete 'onVolumioStart' in a timely fashion
Mar 12 22:07:42 volumio-p volumio[710]: info: Preparing to generate the ALSA configuration file
Steps to Reproduce
Please look to the time stamp.
The boot procedure needs 20 seconds more then for previous versions
I find out the system plugin in system_controller needs this time for
The 21 seconds is spent on the NTP time resolver queries before before moving to checking filesystem. At this point, the USB BOOT eligibility is not being examined yet.
To help you further, without any changes to any code - can you create your device debug log and post URL in this thread please?
The ntp entry is only random here. Also the filesystem check. The next entry created from system plugin is important. Please try to rename the json file and compare the boot time.
is dormant until you open System from main menu. This is where the eligibility is triggered for āInstal to Diskā checks. This is part of the upcoming change and tested in this thread: [BETA] Raspberry Pi boot from USB/NVMe
As a note - tested 3.631 on three Raspberry Pi 5 in a row and all finishing boot in 57sec flat from MicroSD with or without alleged culprit. Something else is going on.
Question - do you observe interface drop in debug logs?
3.631 is from official release channels. Now, we are reaching to NVMe which is from Alpha release channel. @2aCD - Which exact Volumio OS version are you testing on?
From internal quick check you seem to be caught up behind official release. It is hard to determine your build inline with the continuously changing landscape. There are four options here:
Wait for master branch to reach release level - limited support for custom build.
Use mpd-0.23.15-3 branch - testing - limited support for custom build.
Install official 3.631 release and enable test OTA and update - recommended and supported.
Use NVMe ALPHA testing release - should you decide to use this branch, be aware that this is temporary only until all tests are concluded.
Regarding proposed self.getUSBBootCapable() consumed in the ALPHA build, we will take it under revision and run further impact and regression tests. The last thing we need is to introduce to the ecosystem unknown factors.
Ok, I assumed that the master branch always corresponds to the last published version and does not contain any intermediate versions. Then see this thread as a hint to take a closer look at this function.
Iām renaming the thread because the official release is obviously not affected.
As a rule of thumb, master branch is the release channel. However, the devil lives in the detail - time when you executed built from master was where there were new release changes committed. Right now it reflects 3.631 however test OTA is around a corner to be merged. Hence suggestion to wait for the release.
