MeKa ("Meeting Karlsruhe") is a yearly event where some fifty crazy folks have a hell of a great time by sleeping just a little bit, firing up their old Amigas and hacking at the OS level. Thank you, dear organizers!
4-5 hours train ride towards Karlsruhe on Friday: re-organizing the OS selection.
My ASUS EeePC 1000H has a 160 GB disk and thusly
plenty of room for way OS installations. Way more than those
classic four MBR primary partition slots. Rather than depending on
extended/secondary partitions and some complex boot loader (of
whatever flavour), I opted for sticking with a simple MBR loader
(the NetBSD one iin my case, but any other would have been fine,
too) and rewriting the four partition slots as I see fit.
Recently, I migrated tafkap.marshlabs.gaertner.de
from Debian-6 in a (too tight) 6 GB partition to a Debian-7 in a
(spacey) 30 GB partition, both bootable during the migration and
for the last weeks. The Debian-7 appears to be stable enough now --
time to chuck it out and give the partition slot back to
robert (FreeBSD-8.4).
I had expected that FreeBSD would be rather happy to return to
its old partition slot because of the "slice" references in
/etc/fstab and that the oh-so-UUIDifeid linux would
easily find itself in a new slot. Not so. I landed in a grub
rescue> prompt, was able to guess at the ls
and set prefix/root commands, but a boot
would not be accepted. Perhaps some missing insmod?
Difficult to say when you are sitting in a train, stuck at that
prompt, and have no external reference at hand. So it was just
easier to single-boot into FreeBSD, ed /etc/fstab, and
be done with it. (Meanwhile passing Mannheim.)
With lots of netbsd expertise near at hand, I updated my two netbsd-6 installations. In both cases, just minor updates on the "stable" branch, with the last update just two months ago. Both systems are built "from source".
The first one system was ngyuen on the EeePC, easy
enough, because always done according to
The NetBSD Guide steps and going through all
build.sh motions. No problem there.
The second system was hackett, a VM running 24/7 in
the GDS data center. This box had a somewhat tricky past: I had
dared to stray from the path pre-scribed by The Guide to
built the system as documented with the system itself, i.e.
mk.conf(5) and /usr/src/BUILDING. This "kind of" had worked but
left certainly me and perhaps the system, too, in a somewhat
confused state. I least hadn't been able anymore to do naive
builds.
There is some unholy overlap where build information comes from in NetBSD src builds:
make or
build.sh runs)During meka-2014, I had the time to have a close look at the
state of affairs on hackett, using nguyen
as a refence system.
It turned out that I could establish nice and plausible
one-on-one relationships between the "$TOOLS" and "$OBJS"
directories on both systems and that I could bring
hackett back to "normal" be mere mvs of
directory hierarchies. And, lo and behold, a standard build would
run again.
Maybe I also found a working strategy for coordinating
build.sh and make runs:
build.shmakes.Time will tell.
BTW: I extended my build from 1hr to 3hrs by (a) stupidly
ommitting the -T ../tools option from
build.sh (entirely my fault) and by forgetting the
"hey, it's just an upgrade" -u option. My fault, too,
I should have known better, but I was also looking
at the wrong Guide section: the "33.1.5. Summary" reminds you of
the option to use -u while the "33.1.1-.4" individual
steps play it safe and don't hint at -u. Drats, both
recipies look so similar and are so easy to confuse.
Thanks to Martin Husemann for willing to serve as potential safety hook.
ral(4)The stock NetBSD ral(4) driver does not support the wireless chipset built into EeePC 900/1000 models (Ralink Technologies RT2700/RT2800 series). For netbsd-5, I had used a patch kit based on OpenBSD's ral(4) driver. This one would not apply to the netbsd-6 sources, and hence: no WLAN anymore. (Lesson learned: submitting a working patch for inclusion into the standard system pays of quickly.)
In preparation for MeKa, I had already done a review on the old
patch kit. Three completely new files and just trivial or small
changes to existing files. Same for both netbsd-5 and -6, the
latter now being freshly updated. "pcidevs" was easily extended and
new header files pcidevs.h and
pcidevs_data.h generated from that. The remaining
patchkit required a bit of manual editing because a trailing line
apparently got lost. (Beats me how, but the line count was off by
one and patch -C would complain.)
A kernel build would complain about a missing header file and a
missing symbol. mlelstv and stargazer knew what had happened to
netbsd's packetfilter in the past (i.e., from netbsd-5 to -6), and
what to do to adapt the sources. Just half an hour later: a new
kernel and a ral0 WLAN interface which wasn't just
present buit even worked.
Installed the bochs x86 emulator package and
dabbled around with it. No real success because I wasn't able to
make the venerable old "ATP - Air Transport Pilot" by SubLogic fly.
I'm able to cd to existing directories but
dir output always stays empty - very strange.
Another four hours train ride with closer looks into the ral(4) driver. It turns out that eight stretches of code depend on
#if NPBFILTER > 0
which is now effectively nulled. A quick check with >
-999 shows that the source needs some further work in order
to compile. Maybe just small tweeks, though. Arriving at home, I
verify that the working ral0 is still capable to be
tcpdump(8)ed (phew!), and that the current OpenBSD ral(4) driver
has been worked on in the last years, too: rt2860.c evolved from
revision 1.17 to 1.72, supporting newer chipsets, too.
Summary: this will take two or three weekends, but it will be time well spent.