Monthly Archives: February 2015

Nodejs v0.12.0 on Debian ARMv5/QNAP

I have written before about building NodeJS for ARMv5 (a QNAP TS-109 running Debian). Since nodejs 0.12.0 just came out, of course I wanted to build this version – but that did not go so well.

Just standard ./configure and make gave me this error after a while.

In file included from ../deps/v8/src/base/atomicops.h:146:0,
                 from ../deps/v8/src/base/once.h:55,
                 from ../deps/v8/src/base/lazy-instance.h:72,
                 from ../deps/v8/src/base/platform/mutex.h:8,
                 from ../deps/v8/src/base/platform/platform.h:29,
                 from ../deps/v8/src/assert-scope.h:9,
                 from ../deps/v8/src/v8.h:33,
                 from ../deps/v8/src/accessors.cc:5:
../deps/v8/src/base/atomicops_internals_arm_gcc.h:258:4: error: #error "Your CPU's ARM architecture is not supported yet"

This was quite expected though, since earlier versions (v0.10.25 was the last I built) did not build that easily. So I forced armv5t-architecture and tried again:

export CFLAGS='-march=armv5t'
export CXXFLAGS='-march=armv5t'
make
...
Segmentation fault
make[1]: *** [/home/kvaser/nodejs/node-v0.12.0/out/Release/obj.target/v8_snapshot/geni/snapshot.cc] Error 139
make[1]: Leaving directory `/home/kvaser/ndejs/node-v0.12.0/out'
make: *** [node] Error 2

It took almost 7 hours to get here. I stopped compiling and started reading instead.
It seems:

  • V8 is not supported on ARMv5 anymore (last supported version was 3.17.6 I think)
  • Building V8 as a shared library is not very easy
  • Even if I manage to build 3.17.6 as a shared library, there is no guarantee
    it would work with nodejs v0.12.0
  • Just replacing the v8 directory of v0.12.0 with an older version of v8 and hope everything just builds and runs perfectly seems… unlikely (but I have not tried and failed, yet)
  • The Raspberry Pi, with its ARMv6 CPU, is supposed to work with v0.12.0, but a little hack is required at this time (RPi 2 with ARMv7 seems safe)

The good thing is that nodejs (v0.10.29) can be installed in Debian 7 (wheezy) using backports. This is a rather nice and consistent way to install software not already in Debian Stable.

It is, after all, not strange that V8 is not maintained for an architecture that has not FPU. JavaScript uses 64-bit floats for all numbers, including integers.

Qemu Failed too
I tried running nodejs in Qemu (which works for a PowerPC G4), but this failed:

kvaser@kvaser:/opt/node-v0.12.0-linux-x86/bin$ qemu-i386 -L . ./node 
./node: error while loading shared libraries: rt.so.1: ncanoot  penrshaoed cbjeit f: No such file or directory

This is the actual result – not a copy-paste-mistake… so I believe something (byte order?) is seriously wrong.

Bad OS X performance due to bad blocks

An unfortunate iMac suffered from file system corruption a while ago. It was reinstalled and worked fine for a while, but performance degraded and after weeks the system was unusable. Startup was slow, and when on, it spent most time spinning the colorful wheel.

I realised the problem was that the hard drive (a good old rotating disk) had bad blocks, but this was not obvious to discover or fix within Mac OS X.

However, an Ubuntu live DVD (or USB I suppose) works perfectly with a Mac, and there the badblocks command proved useful. I did:

# badblocks -b 4096 -c 4096 -n -s /dev/sda

You probably want to make a backup of your system before doing this. Also, be aware that this command will take long time (about 9h on my 500GB drive). The command tests both reading and writing to the hard drive. It restores the data, so for a working drive it should be non-destructive. I work with 16MB chunks because reading and writing default 512 bytes is slower.

On my first run, about 250 bad blocks were discovered.
On a second run, 0 bad blocks were discovered.

The theory here is that the hard drive should learn about its bad blocks, and map around them. The computer is now reinstalled and it works very fine. I dont know if it is a matter of days or weeks until the drive completely breaks, or if it will work fine for years now. I will update this article in the future.

Finally, if you have a solid state drive (SSD)… I dont know. I guess you can run this a lot on a rotating drive without issues, but I would expect it to shorten the life of an SSD (but if it has bad blocks causing you problems, what are your options). For a USB-drive or SD-card… I doubt it is a good idea.

Conclusion
To be done…

Read OpenWRT reject log (with fwreject)

I configured the firewall on my OpenWRT router to reject outgoing traffic (LAN to WAN) by default, and then explicitely allow protocols and ports as needed. By configuring the firewall to log rejected packages I could identify what legitimate traffic was blocked, and open up the firewall. However, the default logging to the syslog is not particularly easy to read (neither using command line or a web browser). Also, the log is mostly full of other log lines, the log lives very short time (just a few minutes) to not waste memory on the router, and the log lines contain information not needed.

I understand there are powerful products to gather logs on central log servers and analyze them there. I did not want that, but rather a simple web interface directly on the router.

I asked for a simple tool on the OpenWRT forum, no result.

So, I wrote my own tool, fwreject, and published documentation and binaries on DropBox.