Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)
I'm using rpi2, with usb wifi working well. Tests on octoprint config page show and test things alot fast
I dont now what do anymore. Disabling update and announcements and using safe mode, still freezing on trying fetch data from update channel
You've changed the connectivity check IP to an internal one - are you a custom/non-standard DNS configuration on the Pi that made you change this? Or is it all running out of the box standard?
2022-02-02 16:56:51,143 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'base_url': 'http://192.168.5.114/', 'path': '/', 'query_string': 'l10n=en'}
2022-02-02 16:58:08,139 - octoprint.plugins.pluginmanager - INFO - Loaded plugin notices data from https://plugins.octoprint.org/notices.json
2022-02-02 16:58:18,067 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
2022-02-02 17:03:52,710 - octoprint.server.preemptive_cache - INFO - ... done in 421.57s
Based on this, the initial attempt to pre-render and cache the page takes 7min. No external requests happen in this process (unless somehow caused by misbehaving plugins). What I also see though is a GCODE analysis running which takes 12min right during startup, and right in parallel to the attempt at caching:
2022-02-02 16:55:29,911 - octoprint.filemanager.analysis - INFO - Starting analysis of local:base-y.gcode
[...]
2022-02-02 17:07:46,435 - octoprint.filemanager.analysis - INFO - Analysis of entry local:base-y.gcode finished, needed 736.52s
On a Pi 2 I could see the more limited system resources being a factor here.
Judging by the log (next time please share a system info bundle though) the issue here is that stuff that preemptive caching, something that usually should take no longer than half a minute, is taking a whopping 7min here. Since you already tried safe mode without success, the only guess I have right now is your system is simply at its limits during bootup. I don't see this freezing due to update or announcement checks in your log, those complete/fail way before the large time gaps in the log.
You could try (temporarily) renaming your upload folder so OctoPrint doesn't have to analyse what appear to be some larger files right on startup, restart and see if it helps:
mv ~/.octoprint/uploads ~/.octoprint/uploads.bck
sudo service octoprint restart
For some reason there are at least three files in there it should have analysed right after upload, never did though and now is attempting to do that on startup.
Also, please be advised that the recommended minimum hardware when it comes to running OctoPrint on a Pi is a Pi 3. The 2 is quite old and low powered in comparison & not recommended for that reason, so don't expect winning any performance championships with one.
ah! yes, i know about pi 2. I'm installing octoprint because this pi is abandoned for long time. But my printer has no LCD, so octoprint will be nice for basic usage as upload code and send print without PC connection
ok, i've alot tests to do at night, i'll post the results. Thank you guys, you are the best community