N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://deb.nodesource.com/node_6.x xenial InRelease' doesn't support architecture 'arm64' #375
Comments
|
Looks like this was previously commented on at #262 - not sure if a policy has changed since then. |
|
There haven't been any policy changes at this time. We currently only support |
|
What is the "official" way to show that demand? ;) |
|
@mmoll You just did. No promises, and we don't currently have |
|
BTW, if any questions should arise, I'm running ARMv7 (ODroid C1s) and ARMv8 (ODroid C2s) build nodes for theforeman.org, we're using pbuilder (managed by Puppet, triggered by Jenkins) to build our packages and that's working quite well. |
|
I'll add my vote for |
|
I just stumbled about the same issue and would very much appreciate this architecture (arm64) being supported in near future. I'm working with ODROID C2-s. |
|
Voting for arm64 support as well! |
|
Voting for arm64 |
|
What do you guys think about simply installing the I know that people fear performance drops when using armhf binaries on arm64 architecture but the tests we ran show that's negligible. |
|
@ThomasKaiser multiarch could also be disabled for whatever reasons and there might be problems with native extensions (e.g. node-sass). |
|
So this needs some testing :)
Do you know of any arm64 based OS image doing that? IMO this would be a rather stupid move since still some huge packages like eg Firefox or Chromium show a lot of instabilities/crashes when using their native architecture while |
No, but nothing would hold anybody off that.
At least when I tested chromium about two months ago on aarch64 (Odroid C2) it worked fine. |
Slightly off-topic but do you get Octane V2 to run without freezing? I reference this Chromium issue for another another reason: memory constraints (see also here). Mini servers with aarch64 CPUs but just 512MB RAM like NanoPi NEO 2 are reality now, a lot more will follow soon and On a related note: I already thought about adding a variant to Armbian's build system to combine 64-bit kernel with a 32-bit |
|
It would be a bad idea to mislabel an armhf binary as aarch64 and expect it to work everywhere. While many of the single-board ARMv8 based computers also run armhf binaries, there are also powerful data center class systems in place now (and more in a pipeline) that are 64-bit only. How are the ARM binaries being built now? If the build process is sufficiently automated it should be a small matter of CI integration to get aarch64 build/test on Packet's fast 2A servers (96 cores, 128G memory). @chrislea is there some part of the project team that's in charge of CI that I could engage with? |
Just for the record: Nobody is talking about this but we speak about multiarch that allows armhf binaries inside an arm64 Debian/Ubuntu distro with CPU cores brought up in AArch64 state so it doesn't matter whether the CPU is '64-bit only' or not (64-bit would mean only AArch64 but no AArch32 -- please compare with 'Naming conventions' and 'Boot_modes' here. |
|
@ThomasKaiser very brief, as this is really off-topic: at the moment I have only headless aarch64 build slaves without X, so no idea. Regarding swap: I use iSCSI over Gigabit ethernet as block storage, so the situation is a bit different. |
|
@mmoll Ok, understood. Just for the record: This is Octane 2.0 benchmark for nodeJS running in Xenial 16.04.2 on Pine64 with kernel 4.9.0 (cpufreq scaling and throttling disabled and running with boring 864 MHz only to prevent any 'strange effects'). Same numbers:
Edit: So by trusting into passive benchmarking attempts there is no advantage running 64-bit Binaries (I've to admit that I'm not a passive benchmarking fan for obvious reasons. Might be interesting whether some people could just give it a try, compare both attempts and let |
|
Memory consumption running Now switching back to the Memory consumption with Still same performance numbers (did a kernel update to 4.10 in between) but memory consumption 'slightly' differs. With the (full armbianmonitor -u debug log) |
|
Thanks for the pointer to Octane. Similar test results on the Packet 2A server. (96 core, Cavium). |
|
@vielmetti your results with the Cavium confirm single-threaded behaviour of this Octane benchmark. ~2000 score on the most boring 64-bit ARM SoC around (Allwinner A64) running at 864 MHz and just 2.5 times faster on your 96 core beast. Anyway: the interesting question for me is still whether there's a performance drop or not when running NodeJS I got yesterday some feedback in a developer channel confirming memory requirements somewhat but pointing also to some tunables. |
|
@ThomasKaiser The memory requirements are interesting and relevant. If there's any kind of benchmarking you might suggest to exercise all of the cores at once - which might be frankly as simple as Octane + GNU Parallel. Let me try that first. shows a max of about 53G of memory used when 96 jobs are running at once, or 537G per each. So this exercise, at least, doesn't suggest that the memory footprint matters as much as it might. That's not really as much of a surprise as it might be, though I am aware of e.g. a similar Java workload on ARMv8 where we are memory bound even on a 128G machine because of the desire to scale out sideways. |
|
In the meantime I tried it with v7.8.0 (V8 version : 5.5.372.43, with v6.10.1 before it was V8 version 5.1.281.95) as suggesteted by @apritzel. With arm64: armhf: I think looking at 'combined results' is misleading so let's take a closer look: Some of the tests get a minor performance improvement when running as Some others perform neutral and the biggest win when running While it would be still interesting how armhf/arm64 performance numbers and memory requirements differ with different CPU implementations (especially Cavium as 'true server' design) I think I will focus on another attempt first: Using a whole 32-bit userland and compare memory footprint on a 512 MB board (since that's the real use case for me: getting Node-RED run somehow on mini servers where performance doesn't matter that much but memory footprint a lot more and especially swapping/paging would be a disaster) |
|
And now running Octane 2.0 some numbers (especially Splay and SplayLatency) look totally different. Only Difference: now used |
|
@ThomasKaiser - Node-RED will run on very memory constrained systems. I'd look at http://nodered.org/docs/hardware/raspberrypi especially where it says |
Sure, but all Rasperries run a 32-bit userland anyway while those now emerging way more interesting ARM boards with 64-bit CPUs (NanoPi NEO 2, NEO Plus 2 and even the low-end Pine64) come with 64-bit distros and especially this test here shows that memory footprint is totally different when comparing V8 in So still hoping for others simply giving it a go and rolling out the |
I'm on the exact opposite side. |
|
Hello everybody here - we've added support for |
|
Hmm... making some noise led to the wrong result ;) Anyway: if people are happy wasting memory for questionable performance increases I'm happy with. Anyone stumbling accross this and concerned about memory constraints: just follow the 32-bit Armbian for NEO 2 reference above. And also just as reference an example how to deal with NodeJS on ARMv6-ARMv8: ThomasKaiser/install-iot-stuff@b223b27 BTW: Funny that only Rasperries are mentioned in your |
|
Hi All need your help, I tried to install mongodb un ubuntu 18.04 and i got the following error below. thanks for the help N: Skipping acquire of configured file 'multiverse/binary-arm64/Packages' as repository 'https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 InRelease' doesn't support architecture 'arm64' |
I'm looking to install Node v6 on ARMv8 (aarch64) on Ubuntu. I see at https://nodejs.org/en/download/current/ that there's a version compiled at 6.9.1. So far so good.
However, when installing from apt-get I see
Is there some other repository I can go to to get node@6 on xenial? thanks.
The text was updated successfully, but these errors were encountered: