Being out of warranty (it was purchased about 16 months ago – let me not start ranting about batteries that fail after such a short period of light to medium use), I looked around for repair options. Replacement batteries are fairly easy to come by, but the Nano isn’t the easiest piece of hardware to disassemble. Having learned the hard way, I’m really not a big fan of repairing mobile phones and similar devices myself – I always end up snapping a piece of plastic or bending something beyond repair. Taking that into consideration, I decided to look online for someone to do the battery replacement.

Apple themselves will replace the battery for the princely sum of £46.13 (including shipping), which seems just a tad pricey – a new fourth generation 8GB iPod Nano costs only £107. The well-known Juice Your iPod will perform the service for a much more reasonable $32 (excluding shipping), but it seems a little silly to ship an iPod half way around the world to have its battery replaced. I then came across UK iPod Repairs, who’ll do the replacement for a reasonable £30, excluding shipping. I’ve placed an order with them and will be sending them the iPod tomorrow. According to the site, I should get the repaired item back by the middle of next week – expect an update once that’s happened.

Update:Unfortunately the problem wasn’t the battery, it was the logic board. As a replacement would’ve cost in the region of £80, I ended up buying a replacement fourth generation Nano for her (£105).

After struggling for several hours with a flash drive that refused to boot no matter what I did, I discovered an interesting fact – most bootloaders won’t boot from flash drives that have 2048-byte sectors. Of course, the flash drive I was using had 2048-byte sectors… Using a flash drive with 512-byte sectors worked perfectly first time.

Depending on operating system, it may not be that easy to tell the sector size of the flash drive. If using a Unix system, you should see something useful in the kernel ring buffer (displayed by dmesg) when you insert the drive.

A non-bootable drive will display something like:
sd 9:0:0:0: [sdh] 258687 2048-byte hardware sectors (530 MB)
or
sd0: 505 MB, 126 cyl, 64 head, 32 sec, 2048 bytes/sect x 258687 sectors

A bootable one will look something like:
sd 11:0:0:0: [sdh] 2061816 512-byte hardware sectors (1056 MB)
or
sd0: 1006 MB, 1006 cyl, 64 head, 32 sec, 512 bytes/sect x 2062328 sectors

There are a number of sellers offering the same plan for roughly half price on eBay, $199 Buy It Now. Positive feedback for these sellers is close to 100% and, as AppleCare is a worldwide warranty, it seems like a smart move to buy from them, rather than from Apple. Read the auctions more closely and things start to sound a little fishy though. The majority of the sellers who sell a lot of AppleCare packages provide the serial number electronically, rather than providing the retail package or any official paperwork from Apple. Only the serial number is required to activate the warranty, but surely the retail package should be available, if requested? Although the serial number provided may activate the warranty, how do we know that it wasn’t generated by a serial number generator?

I think in this case I’m going to be more prudent and pay a little bit more to buy an AppleCare plan that comes in the proper retail package – there are a number of sellers on eBay offering them and they’re also available from a number of reputable online retailers. The prices aren’t as low, but at least I’ll be more comfortable that I’m buying a legitimate product.

Something odd that we’ve both noticed is that when we put a 450Mhz CPU into a machine that we didn’t receive with a 450Mhz CPU, it wouldn’t boot up. There’s no mention of CPU speed jumpers in the service manual, so we both put it down to different motherboard revisions, phases of the moon and the lack of a chicken sacrifice.

A few days ago I discovered the Sun 450 MHz UltraSPARC-II Module Upgrade guide, which details the CPU speed jumper settings for the Ultra 60 (see pages 3-5 and 3-6). Bah. Why doesn’t Sun bother documenting these things in the service manual?

My boot server is running NetBSD 3.1 and I booted FreeBSD 6.2, so if you’re using different software you may need to make some adjustments. YMMV.

1. On the boot server, configure rarpd(8) as usual, adding the entry for your machine’s MAC address to /etc/ethers. For example (for a machine called test02):
   08:00:20:b2:2f:b6 test02
2. Extract the FreeBSD base fileset to the appropriate location on your boot server (for example, /export/install/fb62_sp64).
3. Extract the FreeBSD GENERIC kernel fileset to boot/ in your diskless filesystem.
4. Within your diskless root, symlink boot/GENERIC to boot/kernel (boot/GENERIC is a directory that contains the kernel and its modules).
5. Put boot/loaders from the diskless filesystem into your tftp root directory and symlink it to your machine’s IP address in hex. For example, the filename for 192.168.1.92 is C0A8015C.
6. Export your diskless root filesystem via NFS and add the necessary dhcpd.conf stanza. For example:
host test02.pimp.org.za {
hardware ethernet 08:00:20:b2:2f:b6;
fixed-address 192.168.1.92;
option host-name "test02";
option root-path "/export/install/fb62_sp64";
}
7. Boot your machine – “boot net” from the PROM should do it.

A few tips:

• It’s normally a good idea to update the machine’s OpenBoot PROM to the latest release. Old PROMs often have subtle bugs.
• Extracting FreeBSD filesets is simple:
cat 6.2-RELEASE/base/base.* > /tmp/base.tar.gz
tar -xzvpf /tmp/base.tar.gz -C /export/install/fb62_sp4


Update: Fixed incorrect command to extract sets (thanks John Messenger!)

My plan is to put together at least two dual CPU machines, one running FreeBSD and another probably running OpenSolaris. *sigh* If only NetBSD supported SMP on 64-bit SPARC systems.

It’s still early days, but I’m impressed with how everything Just Works under OS X. It’s not quite a traditional Unix system (NeXT always was a bit different, NetInfo for example), but a Mach kernel, a mostly-FreeBSD userland and a pretty GUI is good enough for me Of course, I’m still keeping my Ultra 60 running NetBSD as my second head – just need to get Synergy configured so that I can talk to both machines with a single keyboard and mouse.

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

• It took me a while to get the machine back together again with a working disk and the correct RAM. 200-pin DSIMMs are not the easiest things to add and remove.
• I have a distinct shortage of decent sized 1″ SCA disks. I eventually found a 7,200rpm 9GiB Western Digital drive that used to be in my AlphaServer 800 and used that.
• I needed to update the PROM to boot a 64-bit kernel, which took some time as I had to hunt down a hard disk with Solaris already installed in order to boot the PROM updater.
• Solaris is not quick to install using a 12x CD-ROM drive (the fastest I had at hand – didn’t feel like digging in the parts bin outside for a faster one).
• Slicing the disk incorrectly is not a Good Thing – the first install failed after /usr ran out of space.

After all that:
[1] mj@skunkworks:~$ uname -a
SunOS skunkworks 5.11 snv_52 sun4u sparc SUNW,Ultra-2


Not the fastest machine (single 300Mhz UltraSPARC-II CPU, 512MiB RAM), but it runs well.

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.

Some judicious Googling suggested that it could be a heat problem, so on the weekend I stripped the machine down and cleaned it out. It was full of dust – a thick layer on the power supply and over the CPUs’ heat sinks. After the cleanout, the machine has been rock solid – I’ve rebuilt a lot of pkgsrc packages and put it under a fair load and it hasn’t skipped a beat.

From John Baldwin:
Alpha was the first non-x86 port that was added to FreeBSD, and as such it has greatly aided the efforts to keep FreeBSD from being too i386-centric. However, recently the Alpha port has not had any active development or maintenance.
...
After considering all of this, it is time to part with Alpha for 7.0 and beyond. At this time it is still planned to provide 6.x releases for FreeBSD/alpha. The code will still be around in CVS history if someone suddenly shows up and fixes a bunch of bugs and/or the architecture is revived. ...

I certainly hope someone steps up to take care of FreeBSD/alpha, as it would be sad to see it consigned to the history books. I’ve never used FreeBSD/alpha seriously (my Alphas run NetBSD), but the more choice there is available in the open source arena the better.

This doesn’t have to be the end – perhaps it’s the end of the beginning and sgi will re-emerge a better and more focused company. Either way, I think it’s the end of IRIX – if sgi do survive, I think they’ll focus primarily in Linux-based systems, and abandon MIPS and IRIX to the history books.