My network at home is secured against attacks from outside (and inside as well) by a strict set of ACLs within my Cisco C836 Router, and a SUN Ultra-5 serving as a proxy-host for several protocols. Until recently, this Machine was running a NetBSD 3.0.1 Userland with a self-compiled 3.1RC2 Kernel. It's pkgsrc-installed applications were also just as outdated, and so I decided to upgrade the whole box.
Usually, when computers engaged in securing your networks are to be upgraded, one goes for stability, security and definitely not for the newest OS-Version. In this case though, because of "RC" in NetBSD does not mean "development" (that would be "-current"), and because NetBSD 5.0 has certain features NetBSD 4.0.1 does not have, i.e. wapbl, I decided to really go and try NetBSD 5.0RC3. Following is a report about how the upgrade-process worked out... :)
The Upgrade
Installing NetBSD 5.0RC3
I downloaded the bootable ISO-image from a french mirror-server, because either I was too blind, or the german mirrors currently do not have NetBSD-daily-images. After burning the image onto a CD, making some final backups, and sending a small prayer to /dev/null, the almighty Computer-God, I rebooted the machine. Starting from CD on a SPARC-box is usually as easy as nothing else. After System-Initialization (a.k.a POST on PCs), simply press Stop-A, and at the OK-Prompt enter
OK> boot cdrom
This time, however, the system told me that there was a problem reading the device. I remembered having had problems with the concurrent use of CD-ROM and Harddisk, and opened the Ultra-5. As I remembered, the CD-ROM-Drive was unplugged. I reattached it, and voila, now it worked.
So I ran the installer, partitioned my 8GB Harddisk in a single partition using FFSv2 with the option "log" enabled. This option was introduced by the wapbl-driver donated from Wasabi Systems Inc., and significantly improved by the NetBSD-developers. It provides a journalling filesystem on top of FFSv2, and improves the overall-performance of the filesystem as well. What I was ignorant of at this time of the process was the fact that the sparc64-port of NetBSD does not boot from FFSv2, because it has some issues with the different superblocks of FFSv2. Because I did not notice the culprit to be FFSv2, I tried several things, before finally using FFSv1 for the root-partition ("/"), and splitting up the partitions like this:
Filesystem Size Mounted on
/dev/wd0a 1.0G /
/dev/wd0d 2.4G /var
/dev/wd0g 2.9G /usr
/dev/wd0e 482M /home
mfs:165 62M /tmp
/dev/wd1d 28G /data
All partitions (except /tmp and / ) are using FFv2/wabbl (option log). The drive wd1 was added later after the installation process was finished and the CD-ROM drive was unplugged again. It's partition wd1d is using FFSv2 with wapbl, too, of course. 
I added the log-option to the root-partition using FFSv1, too, just as a test. mount(8) tells me, it is using the option, though I can hardly imagine that. wapbl(4) states about FFSv1 and the log-options this:
WAPBL requires the super block to be in the UFS2 format. Older FFSv1 file systems will need to be updated to the newer super block layout with the -c option to fsck_ffs(8).
Since I definitely did not update the superblocks (remember the booting-issue), and the machine definitely is booting now, I don't trust mount(8)'s output in this regard anymore, and have changed the option for the root-partition from log to softdep.
Note: log and softdep are mutual exclusive and lead in RC3 to a kernel-trap, though the kernel claims to ignore softdep. I have already submitted a problem report regarding this issue (kern/41161).
Configuring and Installing Packages
Now after the installation was completed, I started to download the pkgsrc-current tarball, again from the french-server since the german servers do not seem to mirror them as well. After untarring pkgsrc into /data, I set some CFLAGS, since I like to squeeze out every bit of performance available, as long as it does not break the system. My CFLAGS on the Ultra-5 look like this:
CFLAGS=-mcpu=ultrasparc -mtune=ultrasparc -m64 -mvis -O3 \
-funroll-loops -fomit-frame-pointer
Of course the CXXFLAGS are equal to CFLAGS.
Now I bootstrapped pkgsrc (I know that on NetBSD this is not necessary, but out of a habit, and because the mk.conf is automatically generated and the tools are compiled with the above CFLAGS as well, I do it. It's a matter of taste, and according to some people probably of waste (of time) as well, but I don't mind ). Parallel to the bootstrapping, I configured the DHCP-, NTP- and SSH-server that came with NetBSD-base and launched them, so that those were already up and running again.
After that was done, I started installing the services I required:
- misc/screen
- net/bind9 - name-server
- net/dante - socks-proxy
- www/squid30 - webproxy
- www/adzap - advertisement-zapper for squid
- net/ra-rtsp-proxy - real-audio rtsp-proxy
With screen installed, I left the machine to itself and changed into the more comfortable living-room and my laptop. I ssh'ed to nidhoegg, launched screen, and continued from there with installing the apps in the list above. ntpd and named9 are running chrooted, btw.
I mentioned www/adzap in the list above, a squid-redirector I came to love over the last years while using squid 2.x . Sadly, it is incompatible to squid 3.0, obviously because the way squid talks to its redirectors has changed significantly. May be, if I find the time, I will look into this, and patch it so that is work with squid 3.0, too. Currently, adzap is not in use anymore, because the adzap-processes were dying so fast that browsing was impossible.
But before I could use the squid at all, I had to build my own NetBSD-kernel. Why, you might ask. The answer is simple: because I use diskd as storage-method, and diskd requires the following options set in the kernel, which aren't in GENERIC:
options SYSVMSG # System V-like message queues
options SYSVSEM # System V-like semaphores
options SYSVSHM # System V-like memory sharing
options SHMMAXPGS=8192
options MSGMNB=16384
options MSGSSZ=64
options MSGTQL=512
Ok, since NetBSD 4.99.35 this could be set through sysctl(8) and the kern.ipc.* variables, but I was not aware of that before writing this post. And besides, it was a good test / experiment to cross-compile a SPARC64-Kernel on an x86-System (I used my primergy-monster to compile the kernel). The kernel was build in about half an hour. Here is the report:
===> Summary of results:
build.sh command: ./build.sh -m sparc64 -u -N 2 -U \
-T obj.sparc64/tooldir -D obj.sparc64/destdir \
-R obj.sparc64/releasedir -V OBJMACHINE=1 -j8 \
kernel=NIDHOEGG
build.sh started: Sun Apr 5 18:16:21 CEST 2009
NetBSD version: 5.0_RC3
MACHINE: sparc64
MACHINE_ARCH: sparc64
Build platform: NetBSD 4.0 i386
HOST_SH: /bin/sh
TOOLDIR path: /usr/build/src/obj.sparc64/tooldir
DESTDIR path: /usr/build/src/obj.sparc64/destdir
RELEASEDIR path: /usr/build/src/obj.sparc64/releasedir
makewrapper: /usr/build/src/obj.sparc64/tooldir/
bin/nbmake-sparc64
Updated /usr/build/src/obj.sparc64/tooldir/bin/
nbmake-sparc64
Building kernel without building new tools
Building kernel: NIDHOEGG
Build directory: /usr/build/src/sys/arch/sparc64/
compile/obj.sparc64/NIDHOEGG
Kernels built from NIDHOEGG:
/usr/build/src/sys/arch/sparc64/compile/
obj.sparc64/NIDHOEGG/netbsd
build.sh ended: Sun Apr 5 18:42:30 CEST 2009
===> .
Of course the building of the toolchain is not included in this report, it's solely the kernel. I forgot to log how long that took, but from experiences with earlier NetBSD 5.0 builds (though for x86-platform), I can say that is usually takes about an hour.
The compilation went through without incident, and the kernel booted like a charm.
Squid was started and after the adzap-issue was identified and the adzap-call was removed from squid's configuration, all worked fine.
Conclusion
All in all it was a smooth process. The small problems that came up were quickly solved, some of them were caused by me being tired and inattentive, others because I had to learn that things do not always work as I wished them to (e.g. booting from FFSv2 and squid-3.0/adzap).
Since sunday, nidhoegg is running stable and fast, and yes, while copying files between disks, I do really think that wapbl's performance-improvements are recognizable. I copied several large files, and though I did not have measured the time, it felt way faster than on FFSv1, which was used on nidhoegg while running NetBSD 3.1RC2.
For all interest in the dmesg-output, read nidhoegg's page.
