Art
Computing
Contact info
CV
Electronics
Geek culture
Home brewing
Math
Music
Physics
Rants
Ψ/Φ
Style
Teaching
Theatre
WHAT'S UP
Bought used via Huuto.net in March 2009. I had been interested in these small and quiet ARM servers for over a year, but this time I actually felt the need, and got a very nice deal.
Basically the same as the Pro version: 400 MHz ARM9, 128 MB RAM, SATA, GigE, USB 2.0. The motherboard has traces for a second SATA connector.
I followed the instructions and files at the GenLink page rather loosely, as I already have some Gentoo experience. The site has plenty of resources for further hacks, and includes instructions for some other distros like Debian. It operates under the umbrella of NAS-Central with hacking info for related devices.
IMHO, the GenLink base could be much closer to a vanilla Gentoo install (whatever that means ;) and I chose to stay as vanilla as possible. For instance, why mess up the usual /usr/portage hierarchy with other directories and symlinks?
As of special software, you only need the orion5x overlay for micro_evtd, and there are some additional quirks with the startup scripts. But I basically run and maintain this like any other Gentoo box, complete with cross-compiling distcc.
I naturally did a few beginner's fumbles during the install. If you use EM-mode, note that the IP address in that case is 192.168.11.150, as mentioned elsewhere at NAS-Central. I ended up doing most of the install on another machine, with the drive connected to an external adapter. I recommend it as faster and easier. For example, in EM-mode you have very limited selection of software, such as vi being the only editor :-j
One of the fumbles was resizing the / partition in em-mode, and promptly making the new filesystem. However, the kernel had used the old partition size. Actually, this is just the behaviour that fdisk warns about, but most recent systems actually recognize the updated size, so that is what I expected.
XFS is the filesystem used in the factory installation, but it is still acting up in Linux after all these years. Use something else.
A succesful boot is indicated by a looong beep and some flashing lights. It may seem like an error message, but soon after that you can ssh in.
Since Linux 2.6.25, the essential drivers are in the mainline kernel. Following the NAS-Central instructions worked like a charm. As usual, if you know what you're doing, you can probably save some effort. So basically make zImage as in the olden days, do the special bit with the kernel image, and then make modules_install as usual.
There are many packages that don't have the arm or ~arm keyword, even though they compile and run fine. In /etc/portage/package.keywords you can add, for example ~x86 to certain packages. Meaning that if a package is deemed ~x86, it will now compile on your system. Of course, in the long run, you should probably file a bug report to get the keywords into portage.
Some packages will fail to emerge. This is a fact of life in Gentoo, especially with the ~unstable keyword. Or if you are using compiler options that actually let you use all of your modern CPU. You can simply mark these failing versions in /etc/portage/package.mask and wait for better versions, or try to fix the problem otherwise.
However, there is a class of emerge problems that I have encountered when updating packages from the base install: linking fails because the package #includes headers from its old, installed version. So far it has happened with these:
This has been reported by others, for example the readline issue on arm. I do not believe this is peculiar to the less common, or embedded systems, though.
One solution, reported by others in similar cases, is to cross-compile completely on a different machine. As I have already set up the tools for cross-distcc, this one is easy to try. So far it has solved the emerge issues for these:
Cross-emerging is also generally useful, mainly from speed and RAM considerations. I am very new to this, so there is not much advice here yet. It seems to work best for 'monolithic' packages with few dependencies. GCC and Glibc are good examples, and they are also some of the biggest packages you will need on such a small system, so the payoff is excellent. Of course, cross-emerging is essential for real embedded systems like wireless routers, where there is no hope of running a complete emerge.
You can even cross-emerge packages onto a live system. Simply mount the / partition via NFS, naturally over a restricted local network.
These days, the machine is running the following major applications:
in addition to local daemons such as vixie-cron, syslog-ng, ddclient and fail2ban. For most services and administration, I ssh in and use screen. I believe you could add a USB video adapter, plus some input devices, to make a complete thin client ;)
Admittedly, when using Gentoo, a system like this will spend a considerable fraction of its time emerging new packages. On the other hand, there is much less software than on a workstation, and it is not like GCC and Glibc are updated every day, or even every week/month.
Nevertheless, before installation I did consider Debian briefly. It seems to be the best supported binary distro for Buffalo machines, even having official support in the latest release. However, I have a lot of Gentoo infrastructure around, and knowing its weaknesses and strengths goes a long way. As many a Gentooman will testify, this metadistro is not just for ricers, it is also very much about knowing and controlling your system.
This is my first ARM machine, and started its Gentoo life in Kuopio. In that area, "käsj" more precisely means 'hand', or possibly also the hand-arm assembly. It's also a generally funny word and short enough for typing frequently. In some languages "sj" is pronounced like "sh", thus I have decided to pronounce the name as "cash", or more appropriately "cache".