Unable to update WebUI

I’d previously been using git to update the WebUI, and that seemed to work fine. Tried using update_webui.sh this time around, and I get something telling me to tell the author that “node-gyp rebuild” failed.

The following is some output from npm-debug.log:
153 verbose pkgid posix@4.0.2
154 verbose cwd /usr/games/minecraft
155 error Linux 4.9.30-unRAID
156 error argv “/usr/bin/nodejs” “/usr/bin/npm” “install” “–no-spin”
157 error node v5.12.0
158 error npm v3.8.6
159 error code ELIFECYCLE
160 error posix@4.0.2 install: node-gyp rebuild
160 error Exit status 1
161 error Failed at the posix@4.0.2 install script ‘node-gyp rebuild’.
161 error Make sure you have the latest version of node.js and npm installed.
161 error If you do, this is most likely a problem with the posix package,
161 error not with npm itself.
161 error Tell the author that this fails on your system:
161 error node-gyp rebuild
161 error You can get information on how to open an issue for this project with:
161 error npm bugs posix
161 error Or if that isn’t available, you can get their info via:
161 error npm owner ls posix
161 error There is likely additional logging output above.
162 verbose exit [ 1, true ]

Updating via git or via the script should pretty much be the same. Here’s what the script does:

git fetch
git pull origin master
npm install --no-spin

So probably the same steps you’re already doing (except the --no-spin which gets rid of the progress spinner).

However, the error traceback you provided tells us a different story altogether (that this issue likely would be an issue no matter which way you updated).

The posix module failed to build. You can reproduce this behavior manually with:

cd /usr/games/minecraft
npm install posix

(the paths may vary on your system, seeing as how you’re using unRAID).

But are you able to locate your installation and run npm install posix? It could be that that module (at this version) doesn’t build on that sort of system. Quite honestly, I’ve had zero experience with unRaid–it’s not something I maintain personally.

What’s weird is that the posix dependency has been the same since 2015, so there’s no good reason it should fail now, unless there has been something big that changed about your Linux environment.

Anyway, best first step is to manually build it: npm install posix. If it doesn’t build, it’s an npm problem with the environment and we’d have to attack that first. (likely, we might manually build 4.1.x, instead, to see if recent updates address the issue you’re having).

Thanks for the timely response!

So with unRAID, I’m running MineOS in a Docker container. running ‘npm install posix’ gives:

npm ERR! Tell the author that this fails on your system:
npm ERR! node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs posix
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR! npm owner ls posix
npm ERR! There is likely additional logging output above.

In npm-debug.log there is:

155 verbose cwd /usr/games/minecraft
156 error Linux 4.9.30-unRAID
157 error argv “/usr/bin/nodejs” “/usr/bin/npm” “install” “posix”
158 error node v5.12.0
159 error npm v3.8.6
160 error code ELIFECYCLE
161 error posix@4.0.2 install: node-gyp rebuild
161 error Exit status 1
162 error Failed at the posix@4.0.2 install script ‘node-gyp rebuild’.
162 error Make sure you have the latest version of node.js and npm installed.
162 error If you do, this is most likely a problem with the posix package,
162 error not with npm itself.

Any help there?

Open up package.json and modify line 70

"posix": "4.0.x",

to

"posix": "4.1.x",

and try rebuilding. Right now, we’ve isolated the issue to this dependency simply not building, so we need need to see if it’s solved in a newer version, or if not, trying and updating npm and downgrading/upgrading nodejs.

In the event that doesn’t work either, we’re gonna have to go down the route detailed in this github issue; it’s not pretty, but something along the lines of using a different npm build command: CXX=c++ npm install posix

Changed appropriate line in package.json. Still throwing the same error

this time. What do I need to do to change npm and/or node versions?

Let’s try the full gamut. First, try this:

CXX=c++ npm install posix

And see if it works. If not, we’ll update npm. As root:

npm install -g npm

This should hopefully update it to npm 5.0.x and you can try the builds again (both with CXX and the one without)

Alright, leaving everything as-is from before (posix 4.1.x) and running:

CXX=c++ npm install posix

gives:

gyp ERR! build error
gyp ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/usr/lib/node_modules/npm/node_modules/which/which.js:13:12)
gyp ERR! stack     at F (/usr/lib/node_modules/npm/node_modules/which/which.js:68:19)
gyp ERR! stack     at E (/usr/lib/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/node_modules/isexe/index.js:42:5
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/node_modules/isexe/mode.js:8:5
gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:82:15)
gyp ERR! System Linux 4.9.30-unRAID
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/games/minecraft/node_modules/posix
gyp ERR! node -v v5.12.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! posix@4.1.1 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the posix@4.1.1 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

So I tried:

npm install -g npm

Which seems to complete fine (at least there were no obvious errors). However, upon trying to update the webui again, I’m greeted with what looks to be the same error as before:

gyp ERR! build error
gyp ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/usr/lib/node_modules/npm/node_modules/which/which.js:13:12)
gyp ERR! stack     at F (/usr/lib/node_modules/npm/node_modules/which/which.js:68:19)
gyp ERR! stack     at E (/usr/lib/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/node_modules/isexe/index.js:42:5
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/node_modules/isexe/mode.js:8:5
gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:82:15)
gyp ERR! System Linux 4.9.30-unRAID
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/games/minecraft/node_modules/posix
gyp ERR! node -v v5.12.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! posix@4.1.1 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the posix@4.1.1 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2017-06-07T16_33_56_281Z-debug.log

I’m not really familiar with Docker myself, so I’m not sure if it’s something to do with how the dockerfile was configured or anything. Would it help for you to see that?

Sorry, I’m not really familiar with unRAID, so it didn’t occur to me that these were all done in a docker instance.

No, a docker instance is not likely to have the gcc build toolchain present, so actually upgrading the webui will not work. (yes, it’s possible to install that and that likely is 100% of the problem).

Some modules require being built by make, as you can see in your error. So docker instances are expected to be rebuilt through the dockerfile rather than upgraded from within.

But with that said, when you were doing a git-based webui update before, did you not do the npm install command? Because that should likely fail 100% of the time based on the fact you dont have the build toolchain available in your container.

Though, strangely enough, it also likely means you can set up another mineos instance in unraid (is that possible?) and just copy over the /usr/games/minecraft/modules/posix directory–after all, the posix module hasn’t changed–just that your container fails to rebuild it. So if you take a working directory from a similarly-built container… you could still very well get this working.

TL;DR it looks like the only issue you’re having is that you cannot build the module, not that the module is too old or unworkable.

Apologies, I should have specified that this was in a Docker container at the start.

When updating via Git, I didn’t actually run the npm command. Dunno why. I think I must have missed it the first time I looked it up, and never really looked again.

I’ve got your dockerfile set up within unRAID now (was previously using atribe’s fork of it, I think), and am currently on commit d9a604b. I’m sure I can transfer over servers, all that should be fine. I suppose I could try and copy the posix dir over from this new one to the problematic instance of MineOS, but would that solve anything?

Just to be clear: I shouldn’t be updating via Git at all, and should only be letting unRAID/Docker handle the updates based on changes to the dockerfile? (Have I just shown how little I understand Docker?)

This might be the best place to start. Not much has changed in terms of npm dependencies over the years, but d9a604b is still pretty old, committed on Oct 13, 2016. It’s likely that posix is one of the only modules that actually require the build environment, so copying over the posix directory has the following advantages (potentially):

  • allows you to use the most recent commit, which is highly recommended in general
  • takes minutes at most to test if it works
  • if it works, you can just save the posix directory somewhere else on the FS and rinse/repeat on each update

Also, if you used the official mineos docker file, it should have pulled from the HEAD of the master branch, which should be much newer than that… building might take longer than the posix copying so let’s try that first.

Well, I actually went ahead and moved everything over to the new instance, as I’d rather be using the official docker file anyway, but it’s still showing as being on d9a604b. This was just a bog-standard grab and install from Docker Hub. The only thing I changed was the repo from “hexparrot/mineos” to “hexparrot/mineos:latest” in the hopes that that would pull the most recent version, but apparently not. Is there something else I can do, or something on your end, perhaps?

I think this was the reason I started updating the webui via git in the first place, if memory serves. :stuck_out_tongue:

Alright, I see now that you were actually downloading from the Hub rather than the dockerfile (which I read as “Dockerfile”, a literal file of that name from github.com/hexparrot/mineos-docker.

It seems like it’s been 7 months since my docker hub image was updated, so I went and updated it. Both latest and node-jessie point to the same, updated UI.

I sometimes forget that this docker hub image gets downloaded–7 months was much too long between updates. Go ahead and pull from the docker hub again and you should be 100% up to date, using all the nice, modern module versions and all the UI fixes and enhancements I’ve made since.

Awesome. I’ve got people playing on servers at the moment, but I’ll update once they’re unused.

Out of interest, if I were to point unRAID to the mineos-docker repo, should it work? Might have to look into that…

Thanks for all the help with this. I’ve no idea how you manage it, but your turn-around time is fantastic.

Actually I’m not too sure how that would work, with my limited experience with unRAID (and to some degree, even docker).

I’m looking into webhooks, which apparently is the thing that solves this–each commit I make to mineos-node should (in a perfect world) just trigger the build on docker hub instead of waiting for me to build it and then push it.

Hopefully shortly I’ll be able to say “the docker hub image is always 100% up to date with all commits, no matter what”.

I think I might have figured out webhooks.

Now, upon each commit on master for hexparrot/mineos-node, it should trigger a new build in docker hub at:

hexparrot/mineos

It probably would be better if I could keep it at hexparrot/mineos, but that involves me deleting the repo and recreating it, which I’m hesitant to do; I’ll see about the implications of doing so.

Edit: Ignore this! This is what I did, after all. Only one shall exist.

Alright, doing some testing with this. I have another instance running from mineos-docker, currently on commit d3eb568, which looks to be the latest commit (the dockerhub mineos files is on 878043b - 9 days ago vs. 11 hours for the mineos-docker repo). I’ll keep an eye on commits and post back if/when I get an update notification. Thanks again for all the help!

1 Like

Hi is the hexparrot/mineos-docker instance using Java 8 or Java 7? I can’t get it to work with 1.12 and I’m wondering if it’s because like my old docker it’s using Java 7?

Starting from 1.12, Minecraft will no longer support Java 6 or 7. If you are using the latest launcher, you do not need to worry about this as Minecraft ships with its own version of Java. If you know you are using your own version of Java however, you’ll need to make sure you’re using Java 8.

Edit: I can’t get 1.11.2 to work in an unraid docker either. I can install and access the webui, download profiles, but I can’t start servers - the EULA never appears

Edit 2: I was using the node docker - switched to the new https://hub.docker.com/r/hexparrot/mineos-docker and worked like a charm - thanks!

So something interesting here @hexparrot:

Checked for container updates last night, and as it stands now, the one based off hexparrot/mineos-node DOES have an update for it, and the one based off hexparrot/mineos-docker DOES NOT.

Should this not be the other way round, based on the changes you made with webhooks? I’m not complaining; it seems advantageous if this is repeatable, I just wasn’t aware the updates would work like this.

Edit for play-by-play:
Ran the update, got the following right before completion:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="MineOS" --net="bridge" -e TZ="Europe/London" -e HOST_OS="unRAID" -e "USER_PASSWORD"="mcUser23" -p 25565-25575:25565-25575/tcp -p 8443:8443/tcp -v "/mnt/user/appdata/mineos/":"/var/games/minecraft":rw -v "/mnt/user/backup/minecraft/archives/":"/var/games/minecraft/archive":rw -v "/mnt/user/backup/minecraft/restore-points/":"/var/games/minecraft/backup/":rw --cpuset-cpus=0,1,2,3 hexparrot/mineos:latest
53a83fe2b2d9f4304d186d3cc3f2f11be26657366aa2bd132fab58523193e717
/usr/bin/docker: Error response from daemon: containerd: container not started.

Starting the container gives:

container_linux.go:247: starting container process caused "exec: \"/entrypoint.sh\": permission denied"
container_linux.go:247: starting container process caused "exec: \"/entrypoint.sh\": permission denied"

Edit again for completeness:
Tried copying the contents of /var/games/minecraft to the functional container (the one based off mineos-docker), started the container, but none of the servers are seen. Is there something else I should be doing? I know I could use the import folder, but that wouldn’t preserve backup data, and things like that, if I’m remembering correctly.

Looks like the servers ARE there, and DO start, but they don’t actually show up on the front-end, but the couple of servers I had set to auto-start, are in fact up.

Okay, I’l have to look into this. At this point, I’m abandoning hexparrot/mineos-docker. I went ahead and trashed hexparrot/mineos then rebuilt it so that still, only one should ever exist: hexparrot/mineos.

Although the failing to start is definitely a problem–I was able to start them without issue, but if you’re getting an error, you’re also not alone.

EDIT: found the hexparrot/mineos problem. OH JEEZ, bad entrypoint.sh from wget, I have no idea why my docker build . worked, but the hub uploaded version is definitely broken–fixing it right now; the auto build is running as we speak.

Applied the update to the mineos-node container, still getting the same [quote]container_linux.go:247: starting container process caused “exec: “/entrypoint.sh”: permission denied”[/quote] on start.

Anything I can look at that would be of help?