Thanks. I put default settings and now works fine. Thanks again!
Yep, we are already running it here
Stay tuned.
Sorry to add one more issue here. But I noticed Vero doesn’t play nice with DHCP router when ethernet port is used. I reserved an IP address for my Vero but it uses a different IP. Only solution right now is to manually set IP on the Vero. I tested on a Vero with 3.14 kernel and it worked as expected.
Log here https://paste.osmc.tv/zenozuzewo
I already tried the following several times:
- Restart Vero & router
- Disable & enable wired ethernet on ‘My OSMC’
Does the log show DHCP in action or is it showing the manually-set IP address?
did you set the DHCP reservation using the wired or wireless MAC address? is the vero set to DHCP?
if the set the DHCP reservation in your router correctly and the Vero is set to DHCP, it has NO choice but to use the IP given by the router
Should be dhcp.
Wired. I turned off Wi-Fi to be certain.
What should the IP address be?
What’s the output from:
connmanctl
services
services ethernet_xxxxxxxxxxxx_cable
IP should be 192.168.86.51.
In the log it’s always taking 192.168.86.26.
Sorry. I’ll execute what you advised tomorrow. Someone using it now.
Quick question on OSMC. Are you still releasing another beta or are you going straight to stable release?
Check that you haven’t configured the fixed the fixed IP address within DHCP’s auto allocation range. and double-check the MAC address.
I already did check the mac address against the ip address. I got it correctly.
I have my Vero 4K+ connected to a LG SK10Y soundbar/receiver and from there connected to a Samsung UE55NU8000.
I’ve just had a kind of video crash, second time today, during playback suddenly no video output.
The soundbar kept playing sound so I was able to hear I can pause and start again but no video output.
I rebooted by unplugging the power cable. The second time it happened I logged in with SSH and did “grab-logs -A”
https://paste.osmc.tv/hogadutoyo
Regarding the Docker issues:
It appears that the issue is as much with Docker as it is with OSMC / Debian nftables. It should be possible to get Docker running by creating a systemd “drop-in” file (using sudo):
osmc@osmc:~$ cat /etc/systemd/system/docker.service.d/ipt.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --iptables=false
then reboot.
That should get Docker up and running, though I don’t know if everything will work. I can certainly now run “hello world”.
osmc@osmc:/tmp$ sudo docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
4ee5c797bcd7: Pull complete
Digest: sha256:95ddb6c31407e84e91a986b004aee40975cb0bda14b5949f6faac5d2deadb4b9
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(arm32v7)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
I think the nftables part will need some finessing before it’s ready for prime time.
Edit: The drop-in method also works on the (4.19 kernel) Pi.
I was able to get everything to work as well using update-alternatives; and didn’t need a drop-n.
This is what I’m actually asking: what changes do we need to make for this to work out of the box? Are there still some missing CONFIG_ options?
I don’t follow. On 17 Feb you wrote:
I assume you chose option 1, iptables-legacy.
The drop-in allows you to run Docker using the default iptables-nft, without having to run the update-alternatives command. It appears to be an issue with Docker.
That said, the nftables side still needs some work, so in the interim, iptables-legacy will still be required.
Do you have the MAC addresses switched? I’ve had this happen and then remembered I needed to use the wired address, not the wireless.
Will be some more test builds with v19 shortly.
I just ran update-alternatives; didn’t select anything; didn’t add a drop-in.
Are you saying that by adding a drop-in, things are hunky dory without the user having to change anything? If so – we can include that by default for now until we can suitably remove it.
The main point is that 4.9 now has all the necessary support for Docker.