search

tom472 / mediabox

Container based media tools configuration
MIT License
431 stars 84 forks source link

ARM version of the installer script #21

Closed Fr33loader closed 6 years ago

Fr33loader commented 6 years ago

Hi guys,

Love the project, looks very promising!

Unfortunately, my installation always blocks at the stage "Configuring Deluge daemon access - UHTTPD index file - Permissions".

Hardware / software config:

I ran all pre-configuration steps prior to starting the script.

rock64@rock64:~$ docker version
Client:
 Version:       17.12.0-ce
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    c97c6d6
 Built: Wed Dec 27 20:07:05 2017
 OS/Arch:       linux/arm64

Server:
 Engine:
  Version:      17.12.0-ce
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   c97c6d6
  Built:        Wed Dec 27 20:05:10 2017
  OS/Arch:      linux/arm64
  Experimental: false

Problem

I tinkered with the installation script a bit to give a bit more feedback during the installation -- it appears the script is stuck in an endless loop at line 131 of the installation script: while [ ! -f delugevpn/config/core.conf ]; do sleep 1; done

Any idea what's causing this?

Fr33loader commented 6 years ago

I did a "workaround" by copying the conf file from the original repo (https://github.com/binhex/arch-delugevpn/blob/master/config/nobody/deluge/core.conf) to my delugevpn/config/cpre.conf folder.

The setup script runs its course after that tweak, and finishes by linking to a webpage. I tried opening that webpage (i.e. the server IP) from another computer in the network, but it cannot connect. Given that this is a headless server, I can't check whether the page is accessible from the local IP, but I tried to connect with curl and got an error, so I assume this is an installation problem:

curl: (7) Failed to connect to 192.168.0.189 port 80: Connection refused

After some further research, I can definitely confirm it's an installation problem. Only the Portainer container was properly installed, the other docker containers keep rebooting.

I tried to get the log files for each of these docker containers, but the /var/lib/docker folder is empty. Only error I can find is through Portainer, where it shows for each of these containers:

standard_init_linux.go:195: exec user process caused "exec format error"

I'm assuming all of this has to do with the fact that my hardware is ARM based?

tom472 commented 6 years ago

Yes this is due to the ARM architecture - this is currently for intel/amd.

However - that being said, a good bunch of these containers that do have ARM versions.

If you wanted to tell me like the bare minimum of the the containers you are looking to spin up I'd take a stab at configuring an ARM version of the project.

Let me know.

Fr33loader commented 6 years ago

What a service! That would be absolutely brilliant.

Bare minimum would be:

Preferably (but less required): Jackett.

In all honesty, a working version of Delugevpn would be perfect. The others I can install relatively easy outside of Docker (though for a variety of reasons I prefer Docker).

Any plans of adding support for SABNZBD with VPN in the future? (Binhex has a good repo: https://hub.docker.com/r/binhex/arch-sabnzbdvpn/). That would complete the whole media server setup.

tom472 commented 6 years ago

Hey @Fr33loader - Give me a bit of time and I'll see what I can do.

As for adding SABNZBD .. I might add it I don't have / use newsgroups so if I did add it I wouldn't be able to provide much if any support for it.

Stay tuned and I'll see what I can do.

Fr33loader commented 6 years ago

Much appreciated!

Fr33loader commented 6 years ago

By way of update: I gave it a shot myself and (in essence) ran the same install script, but with armhf images of the same docker containers:

There is a plex and plexpy docker armhf version as well, but unfortunately the plex install kept giving errors, so I installed that separately (most important for me is running deluge inside a container). Other than that, it works like a charm.

tom472 commented 6 years ago

That's awesome - Thanks for coming back and providing the info on the containers you used.

When you say you installed Plex separately - do you mean still as a container, or directly on the Rock64?

Thanks again for the info - hopefully I can get this together as a project fairly soon.

Fr33loader commented 6 years ago

I installed it directly on the Rock64 in the end. I tried installing it as a docker container first, but that didn't work out (docker container worked well, but the PMS install was full of errors). I believe I tried the lsioarmhf/plex container. In all fairness, I gave up relatively quickly, and there are a few other containers I could've tried (besn0847/arm-plex or jaymoulin/rpi-plex for example).

tom472 commented 6 years ago

OK got it .. thanks again for the info, I hope to get to this soon. Out of curiosity .. how do you like the Rock64? How is the performance with several containers running?

Fr33loader commented 6 years ago

So far so good. I have the 4GB ram version and must say I'm rather impressed.

Internet speeds are very good (close to theoretical max) and stable (no spikes), idem with disk write speeds. The Xenial minimal installation is relatively stable and bug-free so far and the system does not generate much heat. It's a bit of tinkering to get things started (community is still relatively small), but it's not much different from an RPI in many ways so you can recycle a lot of information. System load is great, I have a bunch of containers running and during normal use the strain is very minimal (single digit percentage strain on each of the four cores). Transcoding on my iphone works great too, though server strain on all cores is near 100% then (depending on the codecs - HEVC 265 is too tough).

Overall, I'm very happy; it's a very low-budget solution considering the specs you're getting.

tom472 commented 6 years ago

Awesome - thanks for the review - I have been eyeing the Rock64 for a while. Probably grab one shortly to mix in with my RPi's

kspillane commented 6 years ago

I have a couple RPi2's sitting right next to me waiting for a project.

I am sure they would not work in any form of production (and I wouldn't want them to), but I can try over the weekend to see if I can code for it, if it hasn't been committed already.

Should be as simple as check the architecture type for armhf and then setting variables in .env to use the different images.

tom472 commented 6 years ago

@kspillane Yeah that's pretty much how i was going to attack it.

@Fr33loader Provided a pretty solid list of the ARM containers that fit the same purposes of the normal Mediabox containers.

I was going to play around with all the images first to make sure they function / work as expected and there's no gotcha's. Then do the architecture check and move forward from there.

kspillane commented 6 years ago

I am going to work on this in my free time today, should have something by this evening.

kspillane commented 6 years ago

Update

65% completed - That's it for today
Testing on ThunderX ARMv7 w/2GB RAM. VPS (because I can't fine my SD card adapter for my RPi)

Issues

tom472 commented 6 years ago

Wow!! that's awesome - Do you have it in a repo yet? I have a Pi I can test with.

Netdata is probably not even really necessary for a smaller ARM device - but I'll still look around.

Plex is kind of tough on ARM or so I've heard and containerizing even harder. I have been using an awesome RPi distro called DietPi and have tested/run its version of Plex on a Pi successfully. I haven't had a ton of time to dig through their code yet, but it looks like the line linked below is where they determine if you are ARM and then there is a URL location it uses to grab an ARM build from - not really sure if we can then go further down the rabbit hole and see if there are any containers based off those ARM builds.

https://github.com/Fourdee/DietPi/blob/5cc4e59a128ff3998802e4a80fa5751d11f7a88f/dietpi/dietpi-software#L6339

kspillane commented 6 years ago

Initial ARM installer commit: https://github.com/kspillane/mediabox/commit/68d267c9484bd0bf8b25239672193eb7de49b6ef

Let me know what you think, and also fi it works on your RPi.

tom472 commented 6 years ago

Looks great so far - I'll try to test soon -

Is there a way to do "voting" on Github?

I want to pose the following Question to potential Mediabox users:

Should this all be one project that detects your arch OR a separate project for each? i.e Mediabox & Mediabox-ARM

Thoughts?

kspillane commented 6 years ago

I say keep them together if we can, to keep it simple. All we are really doing here is setting which images we use depending on the architecture. The only real issue would be hoping those arm containers stay updated.

In all honesty, I don't know why anyone would want to run a full media stack on an ARM system. The Plex transcoder can easily eat up my CPU usage when transcoding x264, as will mono when Sonarr and Radarr are hard at it, and NZBGet will too when it is unpacking downloaded nzbs, and I am running my stack on a beastly Dell PowerEdge 2950.

Maybe setup a slack page or something to get better userfeedback? Or hope more people come along and see the project page?

tom472 commented 6 years ago

See - that's kind of my thinking too is that the full stack on an ARM box, while cool, might not be all that effective. So is it worth the effort in keeping it in the main project and hoping the ARM containers stay up to date.

I'd kind of rather have people find their way to Mediabox "proper" so to speak and then mention that if you want to try and use an ARM device we have a "working" solution for that too.

I think that if there becomes mention of Mediabox "working" on ARM there might be a quick influx of users, issues etc. due to the much lower cost barrier of entry with an ARM device. And, for sure, we know the performance is going to suffer but ARM device users may associate that experience with Mediabox "as a whole" and not necessarily based on that there are using a generally under-powered device for what the project actually can do when on proper hardware.

kspillane commented 6 years ago

Well then why not make a new branch for ARM, should be pretty easy to keep the code lines merged. Or provide a caveat that ARM systems have performance problems, maybe, I am just assuming they do. Really, plex is going to be the only issue, everything else would probably work fine. And having services like netdata, minio, duplicati, or even running it as a seed box would be pretty neat on a cheap arm box. I used to run FreePBX on my RPi2 with no issues.

I say test in on an RPi2 or better and see how it works.

Fr33loader commented 6 years ago

Chipping in: on a personal note, I'd prefer one project. I'd imagine many users are hobbyists, so this would keep things as simple as possible.

I get your point on the performance, but I think that people buying ARM device (PI, Odroid, Rock64) are aware of the limitations, so they'd know to blame it on the device instead of on the software.

kspillane commented 6 years ago

Hey @Fr33loader ! If you want to test out the ARM support and see how it works for you, it is here:

https://github.com/kspillane/mediabox/tree/enhance-ARMSupport

The more ARM platforms we can get it tried out on, the more info we will have about how it works.

tom472 commented 6 years ago

@kspillane Thanks for the post - I have been a little swamped and haven't had a chance to test this on a Pi yet. I hope to have a bit of time this weekend.

tom472 commented 6 years ago

As the Mediabox project has grown over time I am not sure if an ARM version makes sense anymore. At the time of making this comment - Mediabox is running 16 containers by the time it fires up now, I'm not sure if this would be practical on any ARM device at this point.

Not saying the idea is totally dead - but definitely off the radar for now.