Posts by rvleij

Just an update to my own feature request.

I'm currently up to version 8 to get this working, there are dependencies to newer versions of iptables as well as other kernel modules (most can be modules, others will have to be included in the kernel), I'm getting it to work. The size difference in kernel and image are very small. If I get this working I'll follow the guide to a create a pull request with all changes, the size diffs etc, then you can either accept or reject the PR. As it looks now, even though I have started a bit bigger project than I figured, it's relatively small changes to make this work and then we'll have much better capabilities to run Docker services on those boxes. I'll also have a look at the Docker add-on, which is running quite an old version of Docker, now that I'm into this stuff anyway.

OK, with some investigation in how this stuff works I managed to compile a Generic image for amd64/x86 (applause for myself).

Now my question is (after of course I verify that it works tonight what is the "increase in kernel size" we're looking for? In my target dir I have the following size for a 9.2.6 image / update file (and I see there's a kernel as well there). Is that what you're thinking about when it comes to comparing the original and this one? Or do you want me to compare something else, like after I load it? I'll check back with the results on if this got my stuff working, but so far it seems like a very simple feature toggle in the kernel config for projects/linux that's needed.

ubuntu@buildbox:~/LibreELEC.tv$ git status
HEAD detached at 9.2.6
nothing to commit, working tree clean

255909903 Jan 25 22:46 LibreELEC-Generic.x86_64-9.2-devel-20210125203928-6bd7e98.img.gz
16589696 Jan 25 22:45 LibreELEC-Generic.x86_64-9.2-devel-20210125203928-6bd7e98.kernel

After trying this out, it works fine. But the included pkg version of iptables is too old to support what docker tries to do setting up the forwarding chain. Tomorrow I'll build another image with newer iptables pkg version included and try again. Too bad I threw away my build machine in AWS...

Quote from chewitt

LE is focussed on simple client access to Kodi. However we are open-source and our build-system is pretty simple to figure out so you're welcome to build a customer image where the kernel has additional modules enabled for Docker swarms support. If the resulting increase in KERNEL image size is small .. tell us how much and we may consider a pull-request on GitHub to add support to the core distro. If no pull-request comes and/or the file-size increase is large then we're happy your custom image works for you, but this is a niche requirement and it's not needed for the other 99.9999% of our userbase. Does that sound fair?

Yeah, sounds fair. I'll try to figure out how to roll my own and install it. As I wrote, I do understand that not a large % of the LE userbase is running Docker Swarm and I only found a few people that asked about this before. Since we're locked at home anyway, I think I'll get some time to figure this out.

I might be stretching the use of LibreElec, but my HTPC is used as a Docker host as well as media machine for Kodi.

And to split the work a bit between my NUC and some other machine (Pi4 with external storage), I'm running Docker Swarm. It's all fine with the Docker add-on.

But one major issue is that it's not possible to run this way, since the kernel used doesn't seem to have VXLAN support enabled, at least that's my conclusion from the errors I'm getting when trying to start services in the Docker swarm. This is especially a problem if you run reverse proxy for services on either Swarm node, since you can only run one proxy that should be able to reach multiple services on multiple hosts.

I found on the forum that this had been request before, but it wasn't a long thread since I don't think it was explained why this is needed.

So in short: if you want to run some Docker containers on the LibreElec machine, this works great. If you want to create a Swarm with some other machines and create reachability among them (for example for reverse proxy etc), then it's a problem due to the lack of VXLAN support in the kernel.

Thanks