The errors are on usb 1-1, but it looks like the ethernet adapter is on usb 1-2:
Aug 11 22:45:34 osmc kernel: usb 1-2: new high-speed USB device number 6 using xhci-hcd
Aug 11 22:45:34 osmc kernel: usb 1-2: New USB device found, idVendor=0bda, idProduct=8153
Aug 11 22:45:34 osmc kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Aug 11 22:45:34 osmc kernel: usb 1-2: Product: USB 10/100/1000 LAN
Aug 11 22:45:34 osmc kernel: usb 1-2: Manufacturer: Realtek
Aug 11 22:45:34 osmc kernel: usb 1-2: SerialNumber: 000001
Aug 11 22:45:34 osmc kernel: usb 1-2: Unsupported device
Aug 11 22:45:34 osmc kernel: usb 1-2: Unsupported device
Ooh, it’s a Realtek (8152) chip, though fortunately not WiFi. The “Unsupported device” message is a bit concerning, though the device is successfully allocated to eth1 and starts up successfully, though with a 4-second pause before the link becomes ready:
Aug 11 22:48:34 osmc connmand[2345]: eth1 {create} index 4 type 1 <ETHER>
Aug 11 22:48:34 osmc connmand[2345]: eth1 {update} flags 4098 <DOWN>
Aug 11 22:48:34 osmc connmand[2345]: eth1 {newlink} index 4 address 00:E0:4C:30:10:A3 mtu 1500
Aug 11 22:48:34 osmc connmand[2345]: eth1 {newlink} index 4 operstate 2 <DOWN>
Aug 11 22:48:34 osmc kernel: r8152 1-2:1.0 eth1: v1.08.9
Aug 11 22:48:34 osmc connmand[2345]: Adding interface eth1 [ ethernet ]
Aug 11 22:48:34 osmc kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Aug 11 22:48:34 osmc connmand[2345]: eth1 {update} flags 36931 <UP,RUNNING>
Aug 11 22:48:34 osmc connmand[2345]: eth1 {newlink} index 4 address 00:E0:4C:30:10:A3 mtu 1500
Aug 11 22:48:34 osmc connmand[2345]: eth1 {newlink} index 4 operstate 0 <UNKNOWN>
Aug 11 22:48:34 osmc connmand[2345]: eth1 {update} flags 36867 <UP>
Aug 11 22:48:34 osmc connmand[2345]: eth1 {newlink} index 4 address 00:E0:4C:30:10:A3 mtu 1500
Aug 11 22:48:34 osmc connmand[2345]: eth1 {newlink} index 4 operstate 2 <DOWN>
Aug 11 22:48:38 osmc kernel: r8152 1-2:1.0 eth1: carrier on
Aug 11 22:48:38 osmc kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Aug 11 22:48:38 osmc connmand[2345]: eth1 {add} route fe80:: gw :: scope 0 <UNIVERSE>
Aug 11 22:48:38 osmc connmand[2345]: eth1 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Aug 11 22:48:38 osmc connmand[2345]: eth1 {newlink} index 4 address 00:E0:4C:30:10:A3 mtu 1500
Aug 11 22:48:38 osmc connmand[2345]: eth1 {newlink} index 4 operstate 6 <UP>
Aug 11 22:48:38 osmc connmand[2345]: eth1 {del} route fe80:: gw :: scope 0 <UNIVERSE>
Aug 11 22:48:38 osmc avahi-daemon[2311]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.0.16.
Aug 11 22:48:38 osmc avahi-daemon[2311]: New relevant interface eth1.IPv4 for mDNS.
Aug 11 22:48:38 osmc avahi-daemon[2311]: Registering new address record for 192.168.0.16 on eth1.IPv4.
Aug 11 22:48:38 osmc connmand[2345]: eth1 {add} address 192.168.0.16/24 label eth1 family 2
Aug 11 22:48:38 osmc connmand[2345]: eth1 {add} route 192.168.0.0 gw 0.0.0.0 scope 253 <LINK>
Aug 11 22:48:38 osmc connmand[2345]: eth1 {add} route 192.168.0.1 gw 0.0.0.0 scope 253 <LINK>
Aug 11 22:48:38 osmc connmand[2345]: eth1 {add} route 0.0.0.0 gw 192.168.0.1 scope 0 <UNIVERSE>
Aug 11 22:48:38 osmc connmand[2345]: eth1 {add} route 82.165.8.211 gw 192.168.0.1 scope 0 <UNIVERSE>
Aug 11 22:48:39 osmc connmand[2345]: eth1 {del} route 82.165.8.211 gw 192.168.0.1 scope 0 <UNIVERSE>
The last two lines (add/del route) are connman checking for a connection to the Internet. It looks like it succeeded.
During that 4-second pause before the ethernet link becomes available, the device tries to get the time from Google:
Aug 11 22:46:36 osmc http-time[2350]: No internet connectivity was detected within 60 seconds. Will try to send time query anyway.
Aug 11 22:46:36 osmc http-time[2350]: Unable to set time using HTTP query - no response received from servers.
At this point, I’d expect to see the ntp service also start – but it doesn’t. I just checked my Vero4K and my ntp is also not started, though the service is enabled. (I’ve confirmed this with a reboot.) So the only difference between my and your device is that the http-time service is able to connect to Google during the startup process.
Clearly the ntp service is having a problem at startup, though it can be manually started later on.