Home
NetBSD quotas - quickstart, 2009-05-26 00:00:00 #
I found a few issues with quotas-

tags: NetBSD



NetBSD device drivers - easier than you might think, 2009-05-24 00:00:00 #
Okay, so this is basically a post about procrastination as I avoid working on . One thing that struck me was how accessible this part of the internal working of NetBSD were. I mean, seriously, if I can get a working device then anyone can. NetBSD Documentation: Writing a pseudo device tells you everything you need to get started (well, ) And studying other drivers shows that they mostly all look the same, use the same few conventions, and can offer a lot of hints on getting something functional fast. A device-writing section in would be a very welcome addition and would give some nice background to the networking pseudo device chapter. I guess it's time to get some reading in about and friends but if you have an idea for adding a little this-or-that to NetBSD, I'll bet you can get a functional pseudo device in one day or less. p.s. Should I be doing this whole thing with ?

tags: c,programming



NetBSD CVS Digest comeback, 2009-05-16 00:00:00 #
Check it out.

tags: NetBSD



NetBSD seed_tmpfs - a tool for easier-embedded systems, 2009-05-09 00:00:00 #
This whole article has proven mostly worthless thanks the following two entries in fstab: /dev/wd0b /var/log2 mfs rw,-s10m 0 0 /var/log2 /var/log union rw - - That creates a 10M /var/log2 and then union mounts it onto /var/log, which will auto-magically seed the filesystem as it is used. Install into /sbin/ So I like to run my soekris and one of the biggest weaknesses of the methods I describe in there is seeding your memory file systems with the correct files so daemons requiring those files will function properly. Basically, if /var/log/messages doesn't exist, syslog isn't going to create it for you! So, I've written the which will populate a tmpfs with all the data currently on the disk before mounting it. I basically works by first mounting the tmpfs to a hidden location, copying everything from the seeddir, and then doing a null mount on-top of the destdir. So the command: mount -t seed_tmpfs -o -s10M /var/log /var/log will create a (hidden to df) mount of a 10M tmpfs, copy everything from /var/log to it, and then null mount that on-top of it. Using it in /etc/fstab is a two step process (mostly for safety) /var/log /var/log2 seed_tmpfs noauto,rw,-s10M - - And then in /etc/rc.conf: critital_local_filesystems="/ /var/log2" This is a workaround for a little bug where mount -a will always try to remount the filesystem, and putting the parent and target into critical_local_filesystems will explicitly mount them. The other bug is that umount can't trigger to umount both systems that I know of so a manual umount requires two commands.

tags: NetBSD



netbooting NetBSD - flexibility options, 2009-05-03 00:00:00 #
So after re-installing NetBSD on my soekris I got to thinking about jumpstart for netbsd and about the whole pxe boot in general. After doing a little reading of the pretty excellent man page (I mean, NetBSD really does have some great documentation) I wanted to give some of the more flexible options a try. I didn't have to look much further than the bottom of the pxeboot man page, but I thought I would give a summary post about the booting process, and about how you can completely avoid using NFS for netboot if you want to. (let's hope the automated installer has a no-nfs option!) The gist of what happens is is that NetBSD overloads the "filename" option in dhcpd.conf, depending on the request. 1) The first request, from the pxe bios is: option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000" - pxeboot file - by default netbsd will look in next-server/root-path ( ) for 'netbsd' and boot it, but you have more options at your disposal: 2) pxeboot then does a new request as: option vendor-class-identifier, 0, 17) = "NetBSD:i386:libsa" looking for "boot.cfg" 3) pxeboot will then do request for 'netbsd' or whatever you tell it to do in boot.cfg! The neat thing about #2 and #3 is that you can say "tftp:boot.cfg" OR "nfs:boot.cfg" and decide how you want to serve that file. So if you want to say boot the netbsd kernel over tftp and turn off a troublesome piece of hardware, you can make your boot.cfg look like this: menu=tftp boot userconf mode:boot netbsd -c Or point to different kernels: menu=tftp boot installer:boot netbsd-INSTALL And then you just override the values in dhcpd.conf: } else if filename = "netbsd" { filename "tftp:netbsd-SOMETHINGELSE"; So I'm definitely interested to see how the above-mentioned summer of code project decides to use these options, if he decides to use MULTIBOOT to pass an arbitrary list of options into the boot sequence (my-ctrl-file=tftp:macaddress.xml) or who knows what. Abandon CDROM booting! :) (my dhcpd.conf is mostly from the pxeboot man page and I'm testing by connecting my eee to my powerbook with a normal patch cable because modern interfaces will automagically act like crossovers)

tags: NetBSD



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25