I’ve obviously been living in a cave for a while, but I only recently discovered that Panix are offering “virtual colocation” via Xen virtual machines. One very nice feature – they offer NetBSD in addition to the customary Linux. Pricing is competitive and they also offer a free backup service, which is a nice addition. Not quite sure why their default NetBSD virtual machine includes X11 though?
I’ve been having some problems with my workstation lately, some of which I’ve attributed to running bleeding edge software on a non-mainstream platform. Yes, NetBSD-current on a sparc64 machine is not always a recipe for success. The major problems were bus errors when running certain X applications (primarily fluxbox) and some X applications not building shared libraries.
Before possibly wasting time on issues that had already been resolved, I decided to install a new build. Unfortunately releng haven’t released any new builds since early December, which meant I’d have to build a release myself. No problem, except my regular build system (an SMP i386 NetBSD system) has been overheating of late, so I decided to resort to a native build. Not the fastest (none of my sparc64 systems is particularly fast by modern standards), but at least it’d work.
My first build failed with the following error:
*** Failed target: cp-name-parser.c
*** Failed command: /usr/obj/build/tools/4.99/sparc64/bin/nbyacc -o /nfs/src/export/src/netbsd/current/usr/src/gnu/dist/gdb6/gdb/cp-name-parser.c /nfs/src/export/src/netbsd/current/usr/src/gnu/dist/gdb6/gdb/cp-name-parser.y
Hmm… Not too meaningful. Reasoning that my source tree was out of sync, I updated it and kicked off the build again. Same error.
After much head scratching, I guessed that the paths to the input and output files were possibly too long. The long paths are a result of my slightly convoluted filesystem layout as a result of multiple NFS servers. After a failed attempt to use a null mount (which worked, but for some reason the build still used the underlying location), I resorted to mounting the source tree directly in /usr/src and building from it.
Success!
NetBSD enigma.pimp.org.za 4.99.7 NetBSD 4.99.7 (ENIGMA_499) #1: Sun Dec 31 17:52:25 SAST 2006 root@enigma.pimp.org.za:/usr/obj/sys/compile/ENIGMA_499 sparc64
Yesterday I finally got around to adding a second head and setting up Xinerama on my dual Creator3D Sun Ultra 60 running NetBSD/sparc64 -current (4.99.4). Setup was fairly straighforward – I started with a fresh XF86Config generated by X -configure and added the necessary stanzas for the second video card and monitor.
The only slight problem I had was a missing fb1 node in /dev, with the result that XFree86 didn’t even find the second card. After much hair-pulling, I realised what the problem was and ran MAKEDEV std_sparc64 in /dev to fix it. The reason for the missing device node was that my machine had been upgraded from 3.1 to -current and I had neglected to update /dev during the upgrade. Oh well, all’s well that ends well 
Dual Creator3Ds are only supported by 4.0 and later – if you try and boot 3.1 and earlier on a machine with a pair of them, you may find your console “disappearing” when the second card is initalised. To get around that, remove the second card, upgrade and then reinstall the card.
Some useful resources:
Update: fixed the broken link to my XF86Config
A few weeks ago I contacted Internet Solutions and they are now kindly hosting a local pkgsrc distfiles mirror. To use it, simply add the following to your /etc/mk.conf:
MASTER_SITE_OVERRIDE=ftp://ftp.is.co.za/NetBSD/packages/distfiles/
If a file isn’t found at the local mirror, the pkgsrc fetch Makefile target will fetch it from another (non-local) mirror.
A few weeks ago I collected some more Sun hardware from a friend of mine who seems to know the location of the best dumpsters in town. It was quite a collection: a pair of Ultra 60s, a Ultra 2, a pair of Ultra 1s, a Sun 8mm tape drive and a StorEdge L280 DLT changer.
One of the Ultra 60s had a single 360Mhz CPU, 1GiB RAM, a 9GiB disk, gigabit Ethernet and a pair of Creator3Ds. The other had a single 360Mhz CPU, 512MiB RAM, a pair of 18GiB drives and a single Creator3D. The Ultra 2 only had a single 200Mhz CPU, but had 512MiB RAM. The Ultra 1s were pretty low end – both had 143Mhz CPUs, 64MiB RAM and a quad fast ethernet and one had a 2GiB disk, the other being diskless.
I’ve given the one Ultra 60 and the Ultra 2 to Jonathan Groll and the Ultra 1s will probably be given to some deserving homes amongst CLUG members. My Ultra 60 is already running NetBSD-current (currently 4.99.4 kernel and userland) and working well, but more on that in a later post.
It’s incredible, but a few years ago it was impossible to get any moderately decent Sun hardware locally, but these days it seems to be falling from the sky. At rough count I currently have 13 unused Sun machines (6×32-bit, 7×64-bit). Now I just need to get myself a nice Blade 1000, 2000 or 2500 and I’ll be a very happy camper. Of course NetBSD still needs to get working sparc64 SMP and UltraSPARC-III CPU support, but that’s minor stuff 
On Saturday I got two Sun UltraSPARC systems from a friend, in exchange for my unused SGI O2. Although the O2 was a great little machine, I hadn’t used it for about a year and SGI’s poor support for IRIX (ie no easy way for me to get patches) meant it would probably have languished in my pile of unused systems for a while longer.
The two systems I got were an Ultra 10, 333Mhz, 256MiB, 9GiB IDE, Creator3D and an Ultra 2, 300Mhz, 256MiB, Creator3D and no disks. I’ve already stripped my Ultra 5 and put its RAM, SCSI controller, disk and USB 2.0 card into the Ultra 10 and it seems noticeably faster – probably a combination of the Creator3D and the extra cache on the 333Mhz CPU (2MiB vs the 256KiB on the Ultra 5’s 360Mhz).
The Ultra 10 is running NetBSD-current (4.99.1) and once Solaris 10 Update 3 has been released, I’ll be installing it on the Ultra 2.
Yep, it’s true – it takes longer to build Firefox 2.0 than it does to build 1.5. Timings on a 500Mhz EV56 AlphaServer 800 running NetBSD:
real 612m43.097s
user 534m11.005s
sys 80m52.159s
Contrast those with my previous results and you’ll see that it takes about 4 minutes longer to build 2.0. It’s bloat I tell you
As Rafiq says, our local LUG is in need of sponsorship for its stand at this year’s Futurex exhibition. About half the money needed (R10,000 – about US$ 1,250) has been collected so far, but we still need every donation we can get. For more info on donating, see the sponsorship page on the CLUG site.
I’ve made my donation (guess who I am on the list – have you?
Recent Comments