I fear armbian or debian will not provide any relevant clue if they do not run kernel >= 6.17
Note there was a change in 6.17 around the pmdomain - see the history on https://github.com/LibreELEC/Libr…rojects/Samsung and its reference to rebasing the patches applied to the kernel.
tetienne unsure what state you have your Samsung in? What changes were required? Are you saying that an image with 6.16.0 works but 6.16.1 fails? What are the logs? Does 6.18 work? SD is the place to start. You would need to share the uboot uart logs of the emmc boot? What uboot is being used?
Ok - think we have identified the issue.
Set iptables -P FORWARD ACCEPT back to iptables -P FORWARD DROP
- you are using a custom bridge.
- docker network ls
- iptables --list-rules
I expect your lines to look like the first two.
-A DOCKER -d 172.21.0.2/32 ! -i br-6b309bd08e7c -o br-6b309bd08e7c -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.19.0.2/32 ! -i br-edb5b4325218 -o br-edb5b4325218 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.17.0.6/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.17.0.5/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9999 -j ACCEPT
If you then ran (br-… to match your above)
iptables -A DOCKER-BRIDGE -o br-6b309bd08e7c -j DOCKER
I would expect it to work.
Not sure on the root cause or the right fix (for custom networks) but for the default docker0 network, you should not be having the problem.
Please run iptables -P FORWARD ACCEPT and let us know.
Looks to be ipv6 traffic not passing.
ip6tables --list
iptables --list
On my system show the docker chains in both. I have connectivity from the docker containers.
You need 20251128-85c6ad7 or greater for nft
Can you please confirm you are running 20251128-85c6ad7? Versions before this will not have the libraries.
cat /etc/os-release
Can you please check
ldd /storage/.kodi/addons/service.system.docker/bin/dockerd
ls -la /usr/lib/libnft*
Docker daemon is not running.
Can you please share:
systemctl status docker | cat
docker version
Whilst nftables is a mandatory library, it is not used by docker as-is.
The nftables change has changed the backend of iptables to nft.
I’m assuming that you have compiled your own docker addon? As the addon has yet to be made available on the addon server.
You can see my “iptables --list” in the PR
Display MoreHey Libreelec Masters
Kan someone explain what it means for nvidia users
2025-11-15 (c4b4dea): #10669 mesa: update to 25.3.0
what i can understand vaapi takes over and does hw acceleration as be fore but its nvidia capable now
Can i use my rtx5070 now? i hope heheh
Regards
Nvidia is still only included in Generic-legacy (X11)
INTEL/9462.NGWG.NV is a 2230 M.2.
Though based on dmesg iwlwifi is identified, but not coming up either.
lspci/lshw should show it.
But the USB device looks like some kind of wireless.
you may be able to figure out more using a ub7ntu live cd, or given it is a pc primarily made for windows, boot into windows and find out what these devices actually are, and the drivers I use.
we can see
Port 8: 0000.0101 power connect
We can see that there is likely a composite device plugged in to this bus. I’m guessing it is a USB device internal on you pc, that requires a driver. But can’t identify what this device is.
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/8p, 480M
|__ Port 008: Dev 002, If 0, Class=[unknown], Driver=[none], 12M
|__ Port 008: Dev 002, If 1, Class=Wireless, Driver=[none], 12M
Yes. We don’t have build capacity to run 2 full (13/12.2) and addons daily.
When there is change then the schedule kicks off, but when only addon changes are done, then addons need to be built … Also jobs are only run for 24 hours …
So the real answer is - the needed jobs are prioritised over “building for the sake of building” - of which le12.2 image would be.
Hope that give the insight into the schedule.
Now a lsusb -v please
Sorry. But I can’t follow what has been shared.
Just juggling builds.
Can you please share the boot dmesg and lsusb -t without any usbs plugged in?
Is there any error?
Then plug in the USB devices one at a time to identify which one is causing the error.
Once we identify the faulty device then we can look in to the lsusb -v data
