Lots of small files...

In doing some data collection I've found a need to pre-stage collected data before inserting into a database. This is a few hundred bytes per, at a rate of a few per second. Now, a filesystem seems like a logical choice: if the system is up, the filesystem will be up.

Using a straight log file to journal adds some complexity. I want to be loading the data into the database on a fairly quick basis, and then purging the temporary store, however, if the database is down I want to be able to store up a good deal of records before stressing about it. With a log file I'd have to wait for the log file to write out, this means delays from when data is available to when I can use it. Loss on crash becomes more severe the larger the file. Ultimately, we can just skip all the logic on dealing with a log file and do one file per datum. We'll additionally make this filesystem in it's own partition to avoid "cross-contamination" with the rest of the system.

There are a couple of catches:

1. Not all file systems like large numbers of files.
2. Some tweaking needs to be done to "optimize" the layout
3. We really don't want the system managing what we've created

1. & 2. File systems and large numbers of files. This has actually plagued the world since the beginning of time*. News feeds used to create large numbers of small files. Granted, they were slightly larger than what I'm working with, but the theory holds.

Unix-like file systems tend to use "dynamic" structures to hold the data. I say "dynamic" in that it's not a fixed number based on the size of the disk, nor is flexible while the system is running. Short version without going into too much depth is that these structures are called inodes, and you need at least 1 per file, sometimes more if the file takes up a lot of blocks (or fragments).

Which brings us to the second bit of flexibility, those chunks of disk that our file actually takes up. The filesystem keeps track of these by this chunk, too small and we burn up accounting (inodes) too quickly; too large, and we waste disk space.

Now, some versions of the utility that builds filesystems in unix-likes have a couple of cool options. newfs(1), on some versions, has -g and -h options:
-g average file size
-h average number of files per directory
Unfortunately, this seems to be broken on NetBSD 5.0.2. We'll just have to go it the old fashioned way:
-f frag size
-b block size
-n number of inodes

I figure I want to be able to keep a couple million samples around, my files are about 200 bytes each**. Now, the smallest allocations for frag and block size are 512/4096. So, that's what we are stuck with. Pulling a number out of the air I decide to go with about a 2Gig partition. Lets see where that lands us:

RedQueen# newfs -f 512 -b 4096 -n 4194304 /dev/rwd0n
/dev/rwd0n: 2126.2MB (4354560 sectors) block size 4096, fragment size 512
using 296 cylinder groups of 7.18MB, 1839 blks, 14176 inodes.
super-block backups (for fsck_ffs -b #) at:
32, 14744, 29456, 44168, 58880, 73592, 88304, 103016, 117728, 132440, 147152, 161864,

RedQueen# df -i /n/powerlog2
Filesystem 1K-blocks Used Avail %Cap iUsed iAvail %iCap Mounted on
/dev/wd0n 1649195 0 1566735 0% 1 4196093 0% /n/powerlog2

Ok, that looks good for inodes. Now, lets run a little test that drops 100k 200-byte files into the filesystem. This will actually take a while on the test system, initial rate is about 100/s (more on this later).

RedQueen# df -i /n/powerlog2
Filesystem 1K-blocks Used Avail %Cap iUsed iAvail %iCap Mounted on
/dev/wd0n 1649195 51564 1515171 3% 100001 4096093 2% /n/powerlog2

We are now making somewhat efficient use of the diskspace (even though we are abusing the filesystem).

We've turned on softdeps to get some better performance. async is a little risky, and I'd want to do more stress tests on wapbl before committing to that.


3. Normally, unix-like systems like to keep track of what's going on. This works to our disadvantage here.

We're going to take some control of our filesystem. Should the system crash, we don't want to wait for the huge delay in repair. First, lets pull the boot control away from the system.
RedQueen# grep wd0n /etc/fstab
/dev/wd0n /n/powerlog2 ffs rw,noatime,softdep,noauto 0 0

The last 0 is telling fsck to NOT process this file during it's boot run. 'noauto' means the system shouldn't attempt to mount it either. We've now got control of the filesystem during the boot.

The other control we want is from the systems periodic scans. There are 4 scripts that operate on a periodic basis, only 3 of which we need to concern ourselves with. (/etc/monthly doesn't do much.)

/etc/weekly maintains the locate database, which indexes the entire system. You can either turn this off (/etc/rc.conf: rebuild_locatedb=NO) or disable indexing out directories. This is controlled in /etc/locate.conf by adding:
ignorecontents /n/powerlog*

/etc/daily potentially sends two interesting things our way, an fsck (run_fsck) scan, which would be skipped by the '0' above, is disabled by default. A search for core files (find_core) *is* enabled, but doesn't have an exclusion. A quick fix is to add "find_core=NO" to /etc/daily.conf. Eventually, and exclusion path similar to locate, or the security check below should be added to the code.

/etc/security checks on a lot of the system states, but is fairly well behaved. It does have one scan that attempts to peruse the entire system: check_devices. This scans for setuid and device files and reports new/missing. It's on by default, but has a mechanism to exclude. Add
check_devices_ignore_path="/n/powerlog2"
to /etc/security.conf.


This does mean that one will need to manage these directories oneself: checking integrity and mounting. However, this has the advantage as that these processes can run while the rest of the system is live. Depending on ones usage model, one could have a spare partition ready to go to capture data while the old partition is maintained, or, if data retention is not needed, just newfs the partition again. Use will be application dependent.


---

* Jan 1, 1970
** Storing data in symlinks is possible if the target data is short enough:
dinode.h:#define MAXSYMLINKLEN_UFS1 ((NDADDR + NIADDR) * sizeof(int32_t))
dinode.h:#define MAXSYMLINKLEN_UFS2 ((NDADDR + NIADDR) * sizeof(int64_t))
dinode.h:#define NDADDR 12
dinode.h:#define NIADDR 3
So, 60 for UFS1, 120 for UFS2. If you attempt to split the data across multiple filenames the program complexity will grow, and you will incur greater lookup time for add/delete/open.

Fun with IMAP

The iSync package (specifically mbsync) is designed to move mail between stores. However, it does not push the date/time in the APPEND when pushing mail into an IMAP store.

This is a patch that forces that, getting the date/time from the first received line. It probably needs a lot more error checking before becoming production code.

The patch is against isync-1.0.4, and tested on NetBSD 4.99.70 (precursor to NetBSD 5.0). There is a chance that the util lib used is a NetBSDism, in which case the parsedate() function needs to be replaced with strptime() calls and with a lot more error checking.

--- Makefile    2008-11-10 22:09:54.000000000 -0800
+++ /tmp/Makefile       2008-11-10 22:09:06.000000000 -0800
@@ -107,7 +107,7 @@
 INSTALL_PROGRAM = /usr/bin/install -c -s -o root -g wheel -m 555
 INSTALL_SCRIPT = /usr/bin/install -c -o root -g wheel -m 555
 INSTALL_STRIP_PROGRAM = ${SHELL} $(install_sh) -c -s
-LDFLAGS = -L/usr/pkg/lib -lcrypto -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/lib
+LDFLAGS = -L/usr/pkg/lib -lcrypto -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/lib -lutil
 LIBOBJS =
 LIBS =
 LTLIBOBJS =

--- drv_imap.c  2007-09-22 01:44:12.000000000 -0700
+++ /tmp/drv_imap.c     2008-11-10 22:09:14.000000000 -0800
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #if HAVE_LIBSSL
 # include 
 # include 
@@ -1545,6 +1546,40 @@
                            msg->uid, ctx->prefix, gctx->conf->trash ); }

+
+int
+_get_rd (char* msg, char *t_str) {
+    t_str[0] = '\0';
+    char look[] = "Received:";
+    char * start = strstr(msg, look);
+    if (start == NULL) return -1;
+
+    char * end = start + strlen(look) - 1;
+    while (strncmp(++end, " ", 1) == 0) {
+        end = strchr (end, '\n');
+        if (end == NULL) return -1;
+    }
+
+    char * coln = strchr(start, ';');
+    if (coln > end) return -1;
+
+    coln++; // skip the ';' itself
+    while (*coln == ' ' || *coln == '\n') coln++;
+
+    char *bprn = strchr(coln, '(');
+    bprn--;
+
+    if (bprn < end) end = bprn;
+
+    while (*end == ' ' || *end == '\n') end--;
+
+    char * work = strndup(coln, (end - coln + 1));
+    time_t t = parsedate(work, NULL, NULL);
+
+    return strftime(t_str, 32, " \"%d-%b-%G %T %z\"", gmtime(&t));
+}
+
+
 #define TUIDL 8  static int
  static int
@@ -1557,7 +1592,7 @@
        const char *prefix, *box;
        int ret, i, j, d, len, extra, nocr;
        int start, sbreak = 0, ebreak = 0;
-       char flagstr[128], tuid[TUIDL * 2 + 1];
+       char flagstr[129], tuid[TUIDL * 2 + 1];
         memset( &cb, 0, sizeof(cb) );
@@ -1631,10 +1666,14 @@
         d = 0;
        if (data->flags) {
-               d = imap_make_flags( data->flags, flagstr );
-               flagstr[d++] = ' ';
+               flagstr[d] = ' ';
+               char *bufflag = flagstr;
+               d = imap_make_flags( data->flags, ++bufflag );
        }
-       flagstr[d] = 0;
+       flagstr[++d] = 0;
+
+        char t_str[32];
+       _get_rd(data->data, t_str);

        if (!uid) {
                box = gctx->conf->trash;
                prefix = ctx->prefix;
@@ -1650,7 +1689,7 @@
                        imap->caps = imap->rcaps & ~(1 << LITERALPLUS);*/
        }
        cb.ctx = uid;
-       ret = imap_exec_m( ctx, &cb, "APPEND \"%s%s\" %s", prefix, box, flagstr );
+       ret = imap_exec_m( ctx, &cb, "APPEND \"%s%s\"%s%s ", prefix, box, flagstr, t_str);
        imap->caps = imap->rcaps;
        if (ret != DRV_OK)
                return ret;

Buy, Buy, Build, or Build

Sometimes there are just too many choices.

Recently I was looking for USB based temperature sensors. This seems pretty straight forward. And well, it could have been. The problem is that I needed them in a couple of different roles, and was looking at about half a dozen to 10 of them. I needed sensors inside of cases, and again in the top of the attic. At my disposal I've got programming skills, a soldering iron, and my AMEX card.

So, lets see if we can get a quick solution: buy.
Lots of vendors were willing to sell me solutions starting at around $129 that met my requirements. Well, most of my requirements. This would have way blown my budget. If I didn't see a need for more than 3... well, this post wouldn't be happening, and I'd instead be hitting reload on the shipment tracking page.

How expensive can this gear possibly be? Second solution: build.
Sensor, $1.50
USB/Serial, $4.00
Misc discrete components + cable: $5.00 tops
Packaging is limited, and with the discrete components, a circuit board is probably required, so, lets add another $10 for a schmartboard to make our lives easier. (Could have gotten one for $5, but then could have wasted a lot of time trying to fab my own to only save a couple of $ more. The goal was to have something working, not to spend a leisurely Sunday afternoon.)

Ok, this is not sounding too bad. Except that this solution requires that we bit-bang through the serial to the sensor. Doable, but lots of annoying programming. And lots of overhead on the host system. For each sensor.

There has to be a middle ground somewhere. And there is. www.raphnet.net handles a decent chunk of a middle ground, but still not perfect for all situations.

Raphnet has a couple of solutions. They use a Amtel microcontroller to drive the sensor chip and provide USB. It's an open source design, and they provide the firmware loads. Or Amtel's loaded with the firmware. Or an entire board with Amtel, connectors, logic. They even provide a USB to temperature sensor cable.

This is looking pretty good. This gives me the option of being able to buy cables that just plug in, or enough components when I have to build out a board anyway for the in-case sensors. (The project there requires buffer logic, connectors, and a 4-port USB hub chip anyway.) $35 a pop for the cables isn't too bad either.

Still, I poke around. Cheaper/Better?
Another build/buy option are the 1-wire devices. A little more expensive than if I was just buying one, it opens up some more options. The advantage here is that 1-wire is a bus technology. You buy a master, and then start adding sensors. A master can support anywhere from 100 devices to thousands, with up to a a couple thousand feet of cable connecting them.

www.embeddeddatasystems.com has a few products along this line. There are other vendors as well.

What really caught my eye was the ASCII based 1-wire interface. No bit banging, just send text to the serial port, and read text back. As a bonus, this is available as either a fully built external box, serial on one end, 1-wire on the other for $40. If I need to add it as part of a built board, they sell the core component on its own board for under $20. Temperature sensors start at $15 connected to a decent length of cable and neatly wrapped.

End result: some flexibility of solutions for putting sensors inside of cases, and for monitoring a full environment.

Buying the preloaded microcontroller, and other discrete components, for when I have to build a custom board anyway, is an obvious advantage. There is not much incremental cost when building out multiple boards. (Honestly, if it was just a in case one-off, I'd get a retail 4 port usb hub and just get creative with the cabling.)

Hooking up a half a dozen sensors wouldn't be fatal in either direction, but could potentially be cleaner with the 1-wire, especially since I need to make some long cable runs. The particular 1-wire interfaces lose their advantage when trying to make all the sensors appear as if they were system sensors. More traditional interfaces are available for a slight savings.

Having two, close solutions is a win. It means the focus can move on from "will it even work", to what will work best for this situation. It's time for me to order some hardware and start playing around.

mDNS

Getting mDNS nsswitch support is pretty straightforward under NetBSD.

1 Install the net/mDNSResponder-nss package.

2 Add "mdns" to /etc/nsswitch.conf on the host: line.

The package cheats and addes a symlink in /usr/lib pointing to the actual bits in the package base. Note: dig, host, and nslookup all talk DNS directly ignoring what libc sees. You're better off running ping(1).


Now, getting advertisement, another story. I've installed the net/mDNSResponder package. And it comes with no documentation. The package long description points one off to Apple's side and the opensource page for Bonjour.

It contains the following wonderful programs:
/usr/pkg/bin/mDNSClientPosix [listens and shows you whats out there]
/usr/pkg/bin/mDNSIdentify [Looks up a name, and probes system for info (needed ".local" appended)]
/usr/pkg/bin/mDNSNetMonitor [Another reporting tool, can target a host]
/usr/pkg/bin/mDNSProxyResponderPosix [args: IP NAME; registers another host with a mapping, also does services]
/usr/pkg/bin/mDNSResponderPosix
/usr/pkg/include/dns_sd.h
/usr/pkg/lib/libdns_sd.so [how did nsswitch know about this guy?]
/usr/pkg/sbin/dnsextd [implements DNS extensions supporting Dynamic DNS Update Leases and Long Lived Queries]
/usr/pkg/sbin/mdnsd [daemon, only a -debug flag]

End result:
mDNSResponderPosix -b -n `hostname`
works well enough to give my Macs dynamic visibility into the system. I dumped my in /etc/rc.local.

Limiting to certain interfaces would be nice, as would not having to specify the .local all the time, but well, I get that same behavior on my Macs.

DWL-900AP+

I've inherited 2 of these devices. The password was lost, and they were in some weird bridge configuration.

And none of the factory resets appear to work. Even tried multiple times.

Obviously the correct solution is to take them apart.

My searching has led me to the following URLs that showed some promise:
http://www.seattlewireless.net/index.cgi/SamSung4510
http://debugmo.de/ap.html

*sigh*
Almost 2 hours ago this started as trying to figure out if I was missing something wrt to getting a factory reset to work correctly.

Many URLs have lead to dead ends. (Not just no information, but 403s and 404s.)

Now its looking like these boxes are useless as even parts. The wireless card looks to be non-standard (some discussions lead that the pinout is the standard one, but they use a polled io method). They've only got 1M flash, and 8M of ram. (By contract the WL700g has 2/64 respectively.)

I'm considering just leaving these in a pile in case I need to salvage them for discrete components.

I suppose a password grind may now be in order for the unit I can even talk to.

Soekris Netbooting

So, I don't know exactly how I managed to set up the CF card the first time. But somehow I managed to get the NetBSD partition starting at sector 0 according to disklabel.

Jump forward a few months. I'm trying to build out a script to generate images for a CF card, and playing live with a card in the USB CF adapter. And, well, you already see where this is going.

Fortunately, I've only blown away the MBR. The firmware kicks back with no active partition and just stares at me.

I know. I'll netboot. On my ... OS X based Mac. No problem.

Some quick searching turned up mspo's page on netbooting a Soekris with NetBSD on OS X. ( http://www.mspo.com/soekris.html ) This page covered netbooting on NetBSD 3.0. I needed 4.0 on this box, so it shouldn't be much of a problem, right? Heh.

NetBSD 4.0 no longer has a pxeboot_ia32_com0.bin. This is the version of pxeboot_ia32.bin that is configured for serial console. The only documentation talks about using installboot to change parameters. I have no active 4.0 systems. I have no easy way to get any system to be a 4.0 system. And this was supposed to be a quick 1) netboot the netbsd-INSTALL kernel 2) change fdisk.

I just started off with the idea that building a cross toolchain so I could build a cross installboot under OS X was out of the question. Discussion with the developer who removed the _com0 variant was more helpful than the docs. It's possible to use dd(1) to rewrite the right pages in the pxeboot binary itself to adjust boot parameters. No instructions. No documentation.

I did the sensible thing: I used the pxeboot from 3.0.

Obviously this will eventually get deprecated. I've linked it here
http://labs.ono-sendai.com/p/aioDqqskX++stdGiqxIdFQ/

Long term, something better needs to be done with the NetBSD side of things. Time to open some bugs and hope I've got free time someday.

Back to my Soekris however. The fdisk in 4.0 doesn't want to let me play with setting the mbr partition to say that NetBSD starts at sector 0. Disklabel still shows 0 as the start point (there is code in NetBSD to handle the "disklabel part a starts at 0" case). And the a partition mounts fine. I just can't label the disk.

At this point, I'm getting further from my original goal of writing some code. I punt. I untar a bunch of the relevant bits (base, etc, comp, text .tgz's) onto the Mac and netboot a real kernel. A laid down source tree, and I'm golden.

End result:
Yeah, I need to keep a backup dev environment somewhere to deal with this sort of crap. It would have sucked less if I hadn't zorched the environment trying to build tools that would have allowed me to build other environments.

I'll worry about fixing that up after I've got a commitable version of the code I'm working on.

Raq2, hardware initiated netboot

Somehow in my poking around I managed to damage something on one of my Cobalt Raq2 boards. To wit, it now no longer displays the cute copyright, and other boot information on power on. There is also no delay to go into being able to enter a boot command. I suspect that something bad happened to one of the 3 serial eeproms on the board. I guess I'll have to build that clip-on reader/writer sooner than I thought. *sigh*

So, with the lack of being able to direct the system to boot at my whim, I'm forced to rely on the front panel buttons to boot. (Hold down left + right for netboot.)

Therefor, to ammend my previous netboot setup instructions:

add to /etc/fstab:
/net/cobalt/root /nfsroot null rw,noauto

add to /etc/exports:
/nfsroot -maproot=0 -network 192.168.251.0/24

Then,
mkdir /nfsroot
cd /net/cobalt/root
mkdir boot
cp netbsd.gz boot/vmlinux_raq-2800.gz

This should get you going again. Hold down the buttons while powering on. You should see the message "Net booting" on the LCD. You can let go of the buttons then.

This gets more difficult if the box is already racked. My advice is to not break stuff.

Hardware Arrival!

Mouser shipment arrived today. Well, most of it.. the 2U case is still on backorder. Mostly what I expected. Though there were a few things in the "what was I thinking?" category. Mostly stuff like wrong gender of connector, or right angle stuff.

This order was for like 3 different projects: Better case for my soekris, case for scsi drives for my raq2, and the start on parts for my console server project.

I'm going to have to get really good at very fine surface mount soldering really quickly. One of the IC's I got is uber tiny. I'm going to have to see about getting some sort of carrier for it, as I don't want to be having to deal with any of those leads more than once.

Jury is still out on some other components. It's not looking good. I think I'm going to have to suppy +12V to the board anyway. The other option is to double the chipcount.

I couldn't find the rj45 block I was looking at previously. (I can derive the part #, but nobody seems to carry it.) Only 1 out of the 3 8-port blocks I got was double stacked. That one looked really cool until I realized that there were only light guides, not actual LEDs built into the thing. At this point, it will look cool, but I doubt I'll hook it up. There seems to be lots of variance on the pin layout. I may need to go back to the original vendor and see if their different parts can be used with the same board. I'd really like to have one board that fairly flexible on the number of ports.

With luck, i'll have a spaghetti prototype by the end of the month. (Assuming I can figure out remaining parts this weekend.) At least one trip to frys is in order for a better soldering iron and seeing about some prototyping boards.

If I stop running into roadblocks, I should be able to finish some projects...

Project-wise, this weekend sucked.

Turns out that mirrorred drives + growablility on a raq2 is going to require a bunch more work.
1. No root on raid.
2. resize_lfs's stability has been called into question.
3. Still haven't investigated the growing of raid's.

The console server project has encountered a bit of a snag. The recommened dual serial rs232 IC's want +5,+12,-12. Alternate parts want +5,+12. I haven't been able to find a dual that is just +5. Either I add additional voltage to the board, or I significantly increase the chipcount. (Both of which may make space tighter.)

A case is still backordered, and a bunch of the ICs that I want don't seem to be carried by Mouser. I'm up to an absurdly expensive order, but thats quickly mitigated with the fact that there are components for 3 different projects in there. I'm just going to have to sit down and map out a couple of potential solutions. I'm worried that the deciding factors may not become apparent until I start doing board layouts.


Taking out a tree also failed. They didn't have the battery powered Sawzall at the store I went to. The 20 minute internal debate on an alternate brand, plus daylight savings changeback means that the tree is still standing. *sigh*


In lighter news:
> sd0 at scsibus0 target 5 lun 0: disk removable
> scsi floppy!
> on my raq2!

... and I found a power supply that matches the SCSI based PCMCIA slot unit I have.

Bugathon

NetBSD had it's second hackathon(bugathon).

I didn't make it to the first one, and only got a chance to be around for the first day of this last one. I did, however, manage to close all the open PRs for port-cobalt. Now to find some time to test and open some more. I'm sure that had I not been spending Sunday driving 1 down the coast I would have made a dent in the port-shark PRs as well.

http://www.netbsd.org/hackathon/

Thanks to Elad for driving this!

(This has even inspired FreeBSD to start considering the idea!)

Cobalt RAQ2 Netboot config

Netbooting a Cobalt RAQ2 (this should become a tech note)
This covers up through 1.6.2. Later versions may work, but a custom, very stripped down kernel must be used due to hardware limitations.

This setup was done on a Soekris running 3.1_RC2. The Raq2 was connected to the 3rd ethernet (sip2).

Most of this information is scattered amongst half a dozen man pages.

Containing directory where .tgz's were unpacked. Make sure that .../netbsd.gz is the compressed version of .../netbsd. You can do as much setup as you'd like. IP address information will get configured automatically.
/net/cobalt/root

MAC Address of Raq2:
00:10:e0:00:70:88

NFS configuration
/etc/exports:
/net/cobalt/root -maproot=0 -network 192.168.251.0/24

rarp configuration
/etc/ethers
00:10:e0:00:70:88 192.168.251.10

/etc/hosts
192.168.251.10 raq2

DHCPD configuration
ddns-update-style none;
subnet 192.168.251.0 netmask 255.255.255.0 {
}

host raq {
hardware ethernet 00:10:e0:00:70:88; # raq MAC
fixed-address 192.168.251.10; # raq address
filename "/netbsd.gz"; # kernel name in root-path
option root-path "/net/cobalt/root"; # absolute dir on nfs server
server-name="192.168.251.2"; # IP of nfs server
}


Addition to /etc/rc.conf:
ifconfig_sip2="192.168.251.2/24"
nfs_server=YES
rpcbind=YES
mountd=YES
rarpd=YES
rarpd_flags="sip2"
dhcpd=YES
dhcpd_flags="sip2"


Boot command on the raq2, to be entered at the prom prompt (space during hardware inventory drops to prom, gotta be fast!):
bfd /netbsd.gz root=/dev/nfs nfsroot=/net/cobalt/root


TODO: get rid of the "ask" after the kernel autoconfs, before it continues startup.

Soekris CF image creation

Getting NetBSD on a Soekris, the quick way. (This should become a tech-note at some point.)

*Note: this assumes you don't care about wear and tear on the CF card
*Note: it also assumes you've got another NetBSD (unix) host.

Build an image of the proper size. You'll get the size in sectors from dmesg when inserting the card.

In my case, it was 500736 (a "256 Meg" card).
dd if=/dev/zero of=CF bs=512 count=500736
500736+0 records in
500736+0 records out
256376832 bytes transferred in 4.316 secs (59401490 bytes/sec)

Then do it up on a VND:
vnconfig -v -c vnd0 CF
/dev/rvnd0d: 256376832 bytes on CF

Disklabel: remove the extra partition, change the label
disklabel -e -I vnd0

Newfs:
newfs -B le -m 0 -o space /dev/rvnd0a
/dev/rvnd0a: 244.5MB (500736 sectors) block size 8192, fragment size 1024
using 6 cylinder groups of 40.75MB, 5216 blks, 10112 inodes.
super-block backups (for fsck_ffs -b #) at:
32, 83488, 166944, 250400, 333856, 417312,

Install boot:
/usr/sbin/installboot -v -m i386 -o timeout=3,console=com0,speed=19200 -t ffs /dev/rvnd0a /usr/mdec/bootxx_ffsv1
File system: /dev/rvnd0a
File system type: ffs (blocksize 8192, needswap 0)
Primary bootstrap: /usr/mdec/bootxx_ffsv1
Ignoring MBR with invalid magic in sector 0 of `/dev/rvnd0a'
Preserving 51 (0x33) bytes of the BPB
Boot options: timeout 3, flags 0, speed 19200, ioaddr 0, console com0

(the default on the soekris is 19200)

mount /dev/vnd0a /mnt
cp /usr/mdec/boot /mnt
tar -C /mnt -xpzf base.tgz
tar -C /mnt -xpzf etc.tgz
tar -C /mnt -xpzf misc.tgz
tar -C /mnt -xpzf text.tgz

mkdir /mnt/kern /mnt/proc

You might also want to make device entries, its saves several seconds of boot time to not have to run that in an mfs.

fstab:
/dev/wd0a / ffs rw,noatime,nodevmtime 1 1
kernfs /kern kernfs rw
procfs /proc procfs rw,noauto
tmpfs /tmp tmpfs rw

rc.conf:
sshd=YES
hostname=soekris.local
dhclient=YES
dhclient_flags="-q sip0"
savecore=NO
no_swap=YES

Added to gettytab:
Pc.19200|Pc 19200 console:\
:np:sp#19200:ig:ht:

changed in ttys:
console "/usr/libexec/getty Pc.19200" vt100 on secure

Once done configuring, unmount.
umount /mnt
vnconfig -u vnd0

Write it out to the card:
dd if=CF of=/dev/rsd0d


I think I got everything.

mDNS and Zero Conf

Started playing around with multicast DNS on NetBSD to get ZeroConf up and running for local LAN name resolution. This is already happening with my OS X systems. It will just be nice to get the other couple of hosts on this as well.

Supposively there is a Windows version. I'll worry about that after I get the NetBSD stuff up and running.

I'm tackling it with Avahi. Currently it got added to pkgsrc-wip about 3.5 hours before I started to go look for it.


I finally bothered to hook up a ps2 style keyboard to my amd64 system. Maybe I'll be able to capture a traceback on the next panic. (And maybe even a hit as to why the USB keyboard isn't working in ddb.)