Hi Sam, I have i issue with vero 4k+ i installed this latest kernel as said in first page and after reboot vero is not powering up. I tried other power cable and usb power no luck. It only shows red light. I’m trying to install original image and i cant because its not powering on.
I’m more than ready to test Docker for you on the next kernel release 
I can’t wait for it
I really don’t understand where you’re coming from.
First, let’s establish the baseline:
osmc@osmc:~$ uname -a
Linux osmc 4.9.113 #1 SMP PREEMPT Wed Feb 17 21:04:59 GMT 2021 aarch64 GNU/Linux
osmc@osmc:~$ docker --version
Docker version 20.10.3, build 48d30b5
That’s the latest version of Docker from its repo, plus the 4.9.113 kernel you supplied. The OS was updated to the latest version of all Debian packages.
If you do that, you must make a choice, even if it’s just pressing enter to keep the current setting:
osmc@osmc:~$ sudo update-alternatives --config iptables
There are 2 choices for the alternative iptables (providing /usr/sbin/iptables).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/sbin/iptables-nft 20 auto mode
1 /usr/sbin/iptables-legacy 10 manual mode
2 /usr/sbin/iptables-nft 20 manual mode
Press <enter> to keep the current choice[*], or type selection number:
If you just press enter, nothing will change.
Here’s Docker, while running with iptables-nft and without the drop-in:
osmc@osmc:~$ sudo systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─ipt.conf
Active: failed (Result: exit-code) since Sun 2021-02-21 10:15:03 UTC; 4s ago
Docs: https://docs.docker.com
Process: 4266 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
Main PID: 4266 (code=exited, status=1/FAILURE)
Feb 21 10:15:03 osmc systemd[1]: docker.service: Service RestartSec=2s expired, scheduling restart.
Feb 21 10:15:03 osmc systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
Feb 21 10:15:03 osmc systemd[1]: Stopped Docker Application Container Engine.
Feb 21 10:15:03 osmc systemd[1]: docker.service: Start request repeated too quickly.
Feb 21 10:15:03 osmc systemd[1]: docker.service: Failed with result 'exit-code'.
Feb 21 10:15:03 osmc systemd[1]: Failed to start Docker Application Container Engine.
Here’s Docker, while running with iptables-nft and with the drop-in. Note the --iptables=false appended to the command:
osmc@osmc:~$ systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─ipt.conf
Active: active (running) since Sat 2021-02-20 19:17:26 UTC; 14h ago
Docs: https://docs.docker.com
Main PID: 3085 (dockerd)
Tasks: 13
Memory: 41.2M
CGroup: /system.slice/docker.service
└─3085 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --iptables=false
Feb 20 19:17:25 osmc dockerd[3085]: time="2021-02-20T19:17:25.500571409Z" level=info msg="[graphdriver] using prior storage driver: overlay2"
Feb 20 19:17:25 osmc dockerd[3085]: time="2021-02-20T19:17:25.535559784Z" level=warning msg="Your kernel does not support cgroup blkio weight"
Feb 20 19:17:25 osmc dockerd[3085]: time="2021-02-20T19:17:25.536291784Z" level=warning msg="Your kernel does not support cgroup blkio weight_device"
Feb 20 19:17:25 osmc dockerd[3085]: time="2021-02-20T19:17:25.537917076Z" level=info msg="Loading containers: start."
Feb 20 19:17:25 osmc dockerd[3085]: time="2021-02-20T19:17:25.884133035Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.
Feb 20 19:17:25 osmc dockerd[3085]: time="2021-02-20T19:17:25.968734910Z" level=info msg="Loading containers: done."
Feb 20 19:17:26 osmc dockerd[3085]: time="2021-02-20T19:17:26.338148702Z" level=info msg="Docker daemon" commit=46229ca graphdriver(s)=overlay2 versio
Feb 20 19:17:26 osmc dockerd[3085]: time="2021-02-20T19:17:26.339921618Z" level=info msg="Daemon has completed initialization"
Feb 20 19:17:26 osmc systemd[1]: Started Docker Application Container Engine.
Feb 20 19:17:26 osmc dockerd[3085]: time="2021-02-20T19:17:26.492566660Z" level=info msg="API listen on /var/run/docker.sock"
No, not until nftables is sorted out. Until then, users will probbly need to fall back to iptables-legacy.
I’m using the USB image that I sent you.
I wasn’t prompted to make any changes interactively after running sudo update-alternatives --config iptables and then restarting the Docker service.
It would be good to know what ‘sorting out’ involves, and if there’s something that can be done on the OSMC side.
Sam
Gravity 3D issue…
Is there any update on this issue? Have AMLogic given an update on their progress? Many thanks.
Unfortunately we don’t have an update at this time.
Thanks
Sam
@sam_nazarko I recall you saying in another thread that you now have a fix for the issue of the Vero not triggering HDR properly when playing HDR VP9.2 videos. Is this fix likely to be released for the first time at the same time as we get Kodi v19, or might we see it sooner than that? (Or later?)
I think Sam said the next release will be v19, so no more v18 updates for now
Probably a bit later. @grahamh is doing some work on tone-mapping. We can probably include it with that.
To clarify: it needs changes in Kodi, not just the kernel; so it definitely has to come with v19 and not v18.9.
Sam
3 Likes
Just checking in to see if theres any ETA for the new kernel?
There’s a blog post here that mentions the update might/should be tied to the next Kodi point release 19.1
Kodi v19 Matrix is here. Here’s what you need to know - OSMC
I noticed today that toggling the “Force RGB output” option in the System settings doesn’t have any immediate effect. The value is picked up correctly then the box reboots, though. Is that expected behaviour?
Not sure what you mean by this. We would need logs.
This repo is effectively EOL and we have not released anything for some time.
I’m not sure how else I can phrase it…
If I start with the “force RGB” box not checked, then output is obviously YUV. If I check the box, nothing happens - output is still YUV. But if I then reboot, the box boots back up with RGB output. The same is true of unchecking the box - nothing happens until I reboot. That might be what’s supposed to happen, for all I know; but the “limited range” checkbox on the same screen takes effect immediately as soon as its value changes, and I was expecting the RGB box to work like that too.
I’ll post logs later if you like. I don’t honestly care very much, as I don’t use RGB output anyway, I just thought you might want to know…
Yes, that’s how it works. The help text explains it - but the text references were changed by Team Kodi so you may not be seeing the right text.
I’m not actually sure why it needs a re-boot (or a re-start of Kodi will do). I couldn’t possibly comment without fear of upsetting the boss 
Okay, fine. 
Sam - is the way forward to the “future” release of the next OSMC version from this test kernel/build, still only via complete reinstallation?
No - it should be OK to update normally.
what should the normal sources.list look like?
If you want to try the testing images, you will need buster-devel (but it’s not ready yet).
On release after testing, there won’t be any difference between buster-devel and buster.