Monday, December 05, 2016

NetBSD cross compilation is a marvel

While trying to get a patched variant of NetBSD 7.0.2 to run on my Raspberry Pi 3 I had to build NetBSD many times.

And it was pretty amazing how this all worked.

You have a single entry point: ./build.sh And it does everything! It builds the kernel, the userland apps up to the install image you write on the microSD card.

Of course, having a top-level script that does everything is nothing new, it's basically the second question in the Joel Test.

What is amazing is the cross-compilation.

You have an x64 machine and build.sh will happily create the install image for any supported platform.

The Raspberry Pi image is just:

./build.sh -m evbarm -a earmv7hf -u -U release

then you look into the release dir, find arm7.img.gz and you are ready to go.

I ran the builds on a NetBSD virtual machine, but apparently build.sh will happily run with some small preparation even on Linux or macOS.

Sunday, December 04, 2016

NetBSD on Raspberry Pi 3

I have used quite successfully a Raspberry Pi 2 running NetBSD 7 as a customer proxy and I assumed 7.0.2 would run on a Raspberry Pi 3.

As it turns out, the Raspberry Pi 3 ARM Cortex-A53 processor is different enough from the previous Cortex A7 processor we have on the Pi 2 that it needs some kernel changes.

And while the bleeding edge NetBSD current- does work on the Raspberry Pi 3, the stable NetBSD 7.0.2 does not.

I even tried to compile my own NetBSD 7.0.2 and backport the patch that added Pi 3 support, plus up-to-date firmware, but it seems it's not sufficient. There are probably more related commits that need backporting.

So, if you have a Raspberry Pi 3 you can only use current- builds. Go on the nightly build server, grab an .img.gz and test it out!

But if you want a stable NetBSD release, you'll have to wait some more or get a Raspberry Pi 2 instead.

Getting the Raspberry Pi 2 is not such a bad thing because the Raspberry Pi 3 wireless will probably not work for a while anyhow.

Tuesday, September 06, 2016

Time Machine eating its own tail on a FreeNAS ZFS share

I work on a Mac and the OSX Time Machine is a very nice and simple feature to have backups.

While I have some other Apple gear I didn't get an Airport Time Capsule because I already had a tiny Airport Express, the Time Capsule is pricy and I'm not certain it does RAID.

So, what I use instead is the FreeBSD-based FreeNAS on an N54L MicroServer. FreeNAS allows you to easily create a Time Machine Apple Share and it works seamlessly.

The nice thing here is that the FreeNAS share is stored on a ZFS disk! And I have periodic snapshots for those shares.

So, on one side you have Time Machine storing periodic snapshots and only deleting when it needs space.

And on the other side you have the ZFS snapshots that guarantee that nothing is truly deleted!

This proves to be an interesting combination because Time Machine does not expect such a situation when you are low on disk space.

When you are low on disk space OSX's Time Machine will try to remove some data to free some space. But if you have recent snapshots on your ZFS filesystem, deleting files will not create any free space!

So Time Machine will keep on going back in history and delete more and more in order to have enough space to do a backup. I'm pretty sure eventualy it will try to delete the whole history.

Once Time Machine goes free space berserk you have to stop it and fix the problem on the ZFS side.

Either you delete some snapshots, you increase the filesystem quota or move it to a larger array.

In order to prevent the damage Time Machine did, you have to use zfs rollback to go back to a good snapshot. And in order to find a good snapshot it might be worth using zfs diff too.

The Oracle documentation for ZFS Solaris is good enough for this although you might also want to look at the FreeNAS User Guide for your version.

Time Machine doesn't seem to be bothered by a rollback and will gladly continue using the same share and finish the backup!

All in all I believe it's a pretty good combination. In an alternate universe OSX and Time Machine knows ZFS natively but until then FreeNAS gets the job done.

Tuesday, August 23, 2016

Signing NetBeans modules with a Time Stamping Authority (TSA)

Signing JAR files is a very good practice. And while a proper certificate is not worth the price and effort, self-signing is still a step in the right direction.

Ever since Java 5 jarsigner supported a Time Stamping Authority (TSA) with the --tsa and --tsacert parameters. A Time Stamping Authority is basically an online digital notary that certifies the point in time the jar was signed -- it is designed to prevent signing files after the certificate expired.

It turns out that while you can sign NetBeans modules using the FAQ steps, there is no support in the build harness for a TSA.

I found bug #243213 which also mentions NBM problems and I submitted a patch there.

So, if you want to also add a timestamp to your NBMs, apply this small patch on top of your NetBeans source repository and rebuild NetBeans.

Then, you just have to define in nbproject/project.properties another key with your TSA (I'm using StartSSL's here):

tsaurl=http://tsa.startssl.com/rfc3161


Wednesday, August 03, 2016

Forcing export of internal API in Java 9 with -XaddExports

I've long been a fan of NetBeans' module system and of OSGi so Java 9's modules are a big improvement to me.

Except modules are really good at enforcing API boundaries and stop allowing one to freely use any public class.

An error such as this is no fun:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.IllegalAccessError: superclass access check failed: class A$1 (in unnamed module @0x3fb6a447) cannot access class jdk.nashorn.internal.ir.visitor.NodeVisitor (in module jdk.scripting.nashorn) because module jdk.scripting.nashorn does not export jdk.nashorn.internal.ir.visitor to unnamed module @0x3fb6a447

I've assumed that this has to be tweaked at SecurityManager level and played with -Djava.security.manager and -Djava.security.policy and the very handy -Djava.security.debug.

Alas, that doesn't help. (Although I'm still convinced it should, unless there is a bug somewhere).

What one needs to use is the magical -XaddExports flag. This forces an export and allows the code to run:

java -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.ir=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.parser=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.runtime.options=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.runtime=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.ir.visitor=ALL-UNNAMED A


Wednesday, July 06, 2016

String.trim is an optimization hack

Turns out java.lang.String.trim() has its own unique definition of "whitespace" in order to be able to reuse the same underlying char array.

This blog post from 2008 talks in a lot of detail: https://closingbraces.net/2008/11/11/javastringtrim/

Monday, April 04, 2016

BSD on Raspberry Pi 2

Raspberry Pi 2 is the version that finally seems a good purchase to me with its quad core processor and 1GB of memory. If you need WiFi, Pi 3 is even better since an external WiFi dongle consumes more power.

But I would prefer to use an official release of a known operating system instead of using custom forks like Raspbian.

FreeBSD provides an official image, but to them ARM is a tier 2 platform "not supported by the security officer and release engineering teams". So, no freebsd-update. The existing image is for CURRENT ie. bleeding edge. RELEASE would be nice.

OpenBSD has no plans to support it.

The winner is NetBSD: they have an official image since NetBSD 7!

So now NetBSD and this little Pi 2 will replace a much bigger and nosier machine for a dedicated task. I'm curious how it holds up!