Node 16 base Alpine image is incompatible with some arm/v7 servers

[felddy]

Node 16 base Alpine image is incompatible with some arm/v7 servers

[vehrka]

Hi felddy,

no problem at all, Thank you for the time you give to the community!!!

Answering your requests:

1. Could you post the output of uname -a on your Raspberry Pi 4?

Linux cheraserver 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux

2. Is there a reason the command you are using is docker-compose up --build foundryvtt85 and not simply docker-compose up ?

Well, sorry for the mess, I C&P the first command I issued to the shell, but after the first build I have also tried with docker-compose up with the same results

Why are the timestamps in your log weird? Those aren't UTC dates and times. Any idea what is going on there? Do you get similar results running date +%Y-%m-%d\ %H:%M:%S ?

I have no idea of the issue with the timestamps 👀 The command you requested results in:

2021-05-26 18:59:47 (I'm on UTC+2 right now)

If I docker-compose up the 0.7.9 service I get regular timestamps:

foundryvtt79_1  | FoundryVTT | 2021-05-26 17:03:01 | [info] License verification succeeded
foundryvtt79_1  | FoundryVTT | 2021-05-26 17:03:01 | [info] Server started and listening on port 30000

[vehrka]

Hi,

no, I mean, I removed the images and used docker-compose up again with both versions 0.7.9 and 0.8.5 (not at the same time), 0.7.9 works like a charm but 0.8.5 refuses to work

[vehrka]

Hi!

$ apt list --installed libseccomp2
Listando... Hecho
libseccomp2/stable,now 2.3.3-4 armhf [instalado] 

Don't ask me why 😱

Thank you, again and again, for your dedication!!!

The not-too-distant-future™ sounds perfect ... But remember to taking it into account for the 0.8.6 🙏

Bests!

[felddy]

Sorry the container is giving you a hard time. Thank you for the detailed output.

The logs show node is crashing. Probably while trying to run the authenticate.js utility.

1. Could you post the output of uname -a on your Raspberry Pi 4?

2. Is there a reason the command you are using is docker-compose up --build foundryvtt85 and not simply docker-compose up ?

3. Why are the timestamps in your log weird? Those aren't UTC dates and times. Any idea what is going on there? Do you get similar results running date +%Y-%m-%d\ %H:%M:%S ?

[felddy]

This is very odd. I'm thinking there is an architecture mismatch of some kind going on.

I've got the same container successfully running on my Raspberry Pi 4, but with a 64 bit kernel. Just going to paste some of my details in here for you to compare. I'll continue to research this.

$ uname -a
Linux rp4 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb 22 11:37:54 GMT 2021 aarch64 GNU/Linux

$ cat /sys/firmware/devicetree/base/model;echo
Raspberry Pi 4 Model B Rev 1.4

$ lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           3
Model name:                      Cortex-A72
Stepping:                        r0p3
CPU max MHz:                     1500.0000
CPU min MHz:                     600.0000
BogoMIPS:                        108.00
...
Flags:                           fp asimd evtstrm crc32 cpuid

$ docker --version
Docker version 20.10.5+dfsg1, build 55c4c88

$ docker images 
REPOSITORY          TAG             IMAGE ID       CREATED        SIZE
felddy/foundryvtt   beta            8d7b379f2466   4 days ago     125MB

$ docker-compose ps 
        Name                      Command                  State                Ports                                        
---------------------------------------------------------------------------------------------------------------------
foundryvtt_foundry_1   ./entrypoint.sh resources/ ...   Up (healthy)   0.0.0.0:30000->30000/tcp ...

[vehrka]

grrrr... It seems that raspbian by default installs a 32bit system instead of a 64bit version.

I have just seen how to upgrade the 32 to 64 bit version ... I'm going to check and will tell you the results, thanks!!!

[felddy]

I had the same experience. I think the 64bit is almost going to be released as default.

In any case, that shouldn't cause the issue you are seeing. The container should work with 32 or 64 bit operating systems.

Let me know what you find.

[vehrka]

I'm affraid we have no progress :(

$ uname -a
Linux cheraserver 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST 2021 aarch64 GNU/Linux

$ cat /sys/firmware/devicetree/base/model;echo
Raspberry Pi 4 Model B Rev 1.2

$ lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500,0000
CPU min MHz:         600,0000
BogoMIPS:            108.00
Flags:               fp asimd evtstrm crc32 cpuid 

$ docker --version
Docker version 20.10.6, build 370c289 

$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED        SIZE
felddy/foundryvtt   0.8.5      29e633c04818   4 days ago     115MB
felddy/foundryvtt   0.7.9     ab25234dcbc1   5 months ago   93.9MB    

Tried to rebuild the images and still get the Illegal instruction (core dumped)

[felddy]

So... Can you explain what you mean by "rebuild the images"?

Are you doing anything more than: docker-compose up ?

See: https://github.com/felddy/foundryvtt-docker#running-with-a-docker-composition

[felddy]

I've got an idea. Try this command and see if it works:

docker run --rm node:16-alpine --print 'console.log("Got here!")'

You should see:

❱ docker run --rm node:16-alpine --print 'console.log("Got here!")'
Got here!
undefined

[vehrka]

Hey!, Yes I get the same error!!

$ docker run --rm node:16-alpine --print 'console.log("Got here!")'
Unable to find image 'node:16-alpine' locally
16-alpine: Pulling from library/node
e160e00eb35d: Pull complete
c77cb6aac8a7: Pull complete
28d892e33ac4: Pull complete
65caad7930a0: Pull complete
Digest: sha256:40f75a1647d1c5880e98ac16d9855a909748e945073691e7806374cdbede95ba
Status: Downloaded newer image for node:16-alpine


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xffd0126c  

With node:14-alpine and node:15-alpine works well!!

It seems that's there is an official solution for continue using node-16: using node:16-alpine3.12.

It seems that alpine3.13 and libseccomp2 < 2.4 doesn't work on some arm and raspbian come with libseccomp2 2.3.X

I made a quick test:

$ docker run --rm node:16-alpine3.12 --print 'console.log("Got here!")'
Unable to find image 'node:16-alpine3.12' locally
16-alpine3.12: Pulling from library/node
420c7481a3a7: Pull complete
da4bc935f1dd: Pull complete
521d2f1cd032: Pull complete
4abf60dcf6f7: Pull complete
Digest: sha256:ea32349cfa7b207081782cd0d3342cc6d18cda990c68446dead9efaea0018f75
Status: Downloaded newer image for node:16-alpine3.12
Got here!
undefined    

and it works, but I think it will be safer to use node-14 (the minimum for foundry) or node-15.

Is there a specific reason to use node-16? What do you think?

[felddy]

This is very telling. Thanks for running it down.

I think a move back to node:14-alpine would be the correct mitigation for this issue. (node:15-alpine EOL is June 1.)

https://nodejs.org/en/about/releases/

Just for my own curiosity... what version of libseccomp2 do you have installed?

# apt list --installed libseccomp2
Listing... Done
libseccomp2/testing,now 2.5.1-1 arm64 [installed]

Thank you again for opening the issue and doing all the diagnostics.

I'll start a PR for this in the not-too-distant-future™.