[SOLVED] Stuck at A start job is running for network time synchronization

Max2Play Home 2016 (en) Forums Max2Play on Raspberry PI [SOLVED] Stuck at A start job is running for network time synchronization

This topic contains 13 replies, has 2 voices, and was last updated by  air_ii premium 5 months, 1 week ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • 9. April 2018 at 21:54 #35090

    Hello, just installed a 245 stretch version of M2P on a RPI 3 Model B+. More often than not, system startup gets stuck at a continuous loop of:

    • A start job is running for Network Time Synchronization
    • Failed Starting Network Time Synchronization
    • Stopped Network Time Synchronization
    • Starting Network Time Synchronization

    No matter how long I wait, it never ends. I have to restart and pray that next time it goes further (which it sometimes does not).

    Does anyone have a similar issue (and a solution)?

    BTW, I just purchased a premium license, but had to register again to be able to post in the forums. Is this normal?

    Kind regards

    10. April 2018 at 11:09 #35102

    Hi air_ii,

    Do you use a sound card or any other periphery on your Pi?

    10. April 2018 at 11:19 #35103

    Hi, Heiner, yes, I have a Justboom Amp + Raspberry Pi 3 model B+, powered by a 19V 90W power supply.

    10. April 2018 at 13:47 #35105

    I will just add that I am experiencing the same behaviour on two different sets of hardware.

    10. April 2018 at 14:52 #35107

    We are currently looking into this and hope to have a fix very soon. Thank you for sharing this issue.

    10. April 2018 at 17:19 #35110

    Sure. Let me know, if there is anything I can do to help you (logs, additional debugging, etc)

    11. April 2018 at 9:53 #35117

    Hi airlii,

    Please try renaming the Pi. This fixed the issue for us and it did not come back.

    11. April 2018 at 18:02 #35132

    It seems to be related to the router’s device list. If you find your pi there, remove the entry and try rebooting the pi.

    11. April 2018 at 18:12 #35133

    No luck. I’ve actually had mine already renamed (Settings / Reboot menu). Renamed it again, but to no avail.

    11. April 2018 at 22:52 #35136

    Nothing there. I’ve gone through all possible settings within my managed switch (HP1920) that does all the routing (internal) in my network. But it appears that the issue is there even when the LAN cable is disconnected (wifi off).

    12. April 2018 at 9:23 #35138

    Hi air_lii,

    Do you have an overview of the device’s recognized in your network and can you manually delete them?

    Please also try updating your system if you have not yet.

    13. April 2018 at 22:42 #35172

    I have a list of devices in my DHCP server client list and there is ARP cache on my switch. I flushed ARP cache (although there was no reference there to the system) and deleted my Pi from DHCP client list.

    However, I do not think it is related to my particular network setup, as it also happens when the Pi is disconnected from the network and also, it hangs in a place long before any DHCP request is sent (if it boots correctly).

    • This reply was modified 5 months, 1 week ago by  air_ii.
    13. April 2018 at 22:44 #35173

    What is also interesting is that if I boot the system from PXE/iSCSI, it never happens – most likely due to the network being up already. Too bad PXE boot is riddled with bugs on Pi, so it’s not an option, sadly.

    • This reply was modified 5 months, 1 week ago by  air_ii.
    15. April 2018 at 23:25 #35195

    I think I figured it out. It happened due to two different overlay audio drivers being loaded in config.txt:

    dtoverlay=iqaudio-dacplus
    disable_overscan=1
    
    dtoverlay=justboom-dac 

    By disabling dtoverlay=iqaudio-dacplus I got rid of the issue.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

Register here