It seems like I am all alone to solve my problem.
I knew this topic helps you test the new kernel and now buster.
But I was under the impression that testers get help too…
Anyways, my second OSMC Vero 4k+ just arrived, so I have put it in place of the old one and it booted properly, has network access, I had it update it’s packages, but did not add neither buster to it not the videoimprovevero49 repo. It works, can access the server, watch videos off the server. I just wanted to move the xmls from the old one to the new by SCP so that I do not have to go through the pain of:
adding all the sources
with their scraper settings,
the autofs config,
the advancedsettings substitutions
Which is why would like to solve this without a complete reset and reinstall in the first place.
So I moved the my first Vero4k+ to my living room 4k TV and hooked it up with wired network.
It still boots into pitch black screen after the initial spash and the blue OSMC logo screen instead of Kodi, BUT! after a while:
The usual Kodi screen comes up (I use the original kodi skin)
however without connection to the MariaDB server
also not able to connect to the NFS shares
also tried to connect through Wifi instead of Wired network. Which is weird because:
I can see on my (separate) PiHole DHCP server that it received IP leases for both its wired and wireless Interfaces
I can see it as an attached device on my router too
If I turn off the wired interface and then back on, connect I MyOSMC shows it has received the DHCP info successfully
Have you seen such Kodi loading delay, can it be because of some kind of a network misconfiguration?
Any idea why it is not responding to the network even though it seems to be connected both from the outside (router, DHCP server) and inside (MyOSMC)?
Should I try the buster upgrade only without the videoimprovevero49 on the new Vero4k+ to see if that is screwing thing up or videoimprovevero49?
Can I switch to a text console on OSMC itself for troubleshooting as remote SSH is not accessible?
Not directly after the upgrade but since the first restart after the upgrade.
Directly after the upgrade I have been able to watch videos (from NFS).
But once I had the problem with the green video player I have rebooted.
Black screen since then maybe waiting for the network. When Kodi does load, I can connect to both the wired and the wireless network in MyOSMC, DHCP config us received for both (192.168.192.158 and 192.168.192.12) but it does not work in Kodi, I cannot go into Videos / Files / .
I have tried to config the same IP, mask, gateway, DNS server manually too, still no success.
Next thing I can try is a local command line console, appreciate if you can give me any ideas to check beyond ifconfig, ethtool, ping, traceroute.
Login locally and check the above (maybe disable Wifi so that we concentrate on Wired first)…
Ping your router IP and the run arp -na you should see a list with IP and MAC Adress. If you see “Incomplete” then there is a L2 network issue.
So in the last few days the device found it’s way back on the network. However after much watching on Sunday I got the green screen playing again and sure enought not able to connect to the network. Now this seems more than a coincidence. Stays that way after a second reboot too.
Sure enough this time I got the local command line, arp -an shows incomplete only for the MySQL/NFS server, the router IP and DHCP server ip are okay, I can also ping the later two.
In the meantime the NFS / MySQL server has also been doing deluge for many days happyly and can ping the router and the DHCP server…
Coincidentally the router, the DHCP and the tow Vero 4k+ boxes are connected on Ethernet and are linux boxes, the NFS / Mysql server is connected on wifi an is a Windows 10.
Any idea what can be the source of te arp error and how to reset it now instead of waiting on Arp timeouts?
My initial impression is that it doesn’t appear to be a networking issue on the Vero4K itself. Since if you can ping the router from the V4K, I’d have thought you should also be able to SSH to it from a router-connected device (excluding the NFS / MySQL server). The fact that you have the NFS / MySQL server on wifi is a bit of a red flag. Wherever possible servers should always be cable-connected.
In addition to what @fzinken said, it could be an issue with cabling, the NFS/MySQL server itself (or its wifi) or whatever router/switch you have on your network.
I wish it was cable connected, however the unit I rent has no UTP cabling. However the Wifi is provided by the same router as what is doing the switching of the Ethernet. So I would expect no ARP messages to be lost. And it has been operating for years without problems so unless it has just started to deteriorate I would be looking at the device that did have a major upgrade and is exhibiting the problem, which is the buster and 4.9 upgraded Vero4k+.
I have been clearing the arp tables on all devices and got the erring Vero back on the network. However I did not get the logs then, and will have to do it step-by-step manually as your script does not redact passwords (e.g. advancedsettings.xml db connection ones).
I did remove all the DHCP reservations except the one for the NFS/MariaDB server. Let’s see if this makes the network detach go away. Will report back if it does.
It is important to highlight it so far always coincided with the green video play.
What I can still offer is to upgrade the repos in apt/sources.list to buster but not add the veroimprove49 repo to see if either of the problems (green video, ARP) come with buster or with the 4.9 kernel. Should I?
I believe I have the same issue. The only thing I can think of that may have caused an issue was I changed the sources.list before I ran the step 1 upgrade, so I went straight to Buster from whatever I had. I believe I was up-to-date, but I can’t be sure.
I had been using the Vero successfully since the upgrade without rebooting, but I wanted to log out to try another profile. The log out option didn’t have any effect so I rebooted and got the same error as oajungen here:
Right before or after the last line on his screen (about bluetooth) I got a line alternating between “A start job is running for Set Time using HTTP query” and “A start job is running for wait for Network to be Configured.” After a minute or two, I got into the GUI, but the power button menu wouldn’t open after hitting the power button (I don’t think I’ll be able to get to the CLI or the OSMC page from the GUI). After a while, my screen went black. I haven’t seen it on the network since the initial reboot.
Assuming it connects in the future, I’ll try out whatever I can from the posts above through SSH. Until then, is there anything I can try besides pulling the plug to see if it will reboot correctly?
So your problem is only when connecting to Wifi?
From an upgrade point it looks ok, but as there where some smaller updates since you last updated I suggest you update ones more while you are connected right now.
I think the problem was that it was failing to connect to the previously working 5Ghz. It was waiting for a network connection, then would load OSMC, then go to a black screen after a couple minutes. Would a bad network connection cause the black screen, though?
I am not sure how I finally got into MyOSMC, but once I did, I unsuccessfully tried to reconnect to my 5Ghz network so I went with 2.4Ghz. I haven’t had wifi issues on 5Ghz since I got the device almost a year ago and it started directly after the first reboot from a GUI update. I normally do an SSH update, but I didn’t this time. Here’s a wifi log: http://paste.osmc.tv/uxisaqizoc
Sorry to hijack this thread. I hope this is related and provides some hints to @petersasi. If not, I can break it out, although I am unsure how to do it cleanly like you did with this thread.