If you need assistance, you may find it here. If you run into a strange problem that you can't figure out, feel free to email me as there may be a bug in flashrd that needs to be fixed.
root on rd0a swap on rd0b dump on rd0b fsck: /dev/wd0a: unknown special file or file system. fsck: /dev/wd0a: unknown special file or file system. bootstrap: fsck wd0a failed, attempting boot anyways mount_ffs: /dev/wd0a on /flash: Device not configured bootstrap: fatal error mounting wd0a to /flash Enter pathname of shell or RETURN for sh:
You didn't run cfgflashrd against your image (or disk.) The default image assumes your root device shows up as an older style ATA disk, wd0. That's true if you are using compact flash, bochs, or qemu. If you are using AHCI, USB key, or something else, your disk is probably sd0. You have to specify this using cfgflashrd -rdroot szez.blah.blahblahblah.
Say your USB key is sd1. Try 'fdisk sd1' and you will see:
Disk: sd1 geometry: 974/255/63 [15663104 Sectors]cylinders is displayed (974), heads is also known as "tracks/cylinder" (255) and sectors is also "sectors/track" (63)
A USB key is a nice target for flashrd. It is cheap, easily removable and replacable without unracking and disassembling the entire machine. SLC usb keys are also cheap and recommended. Of course, flashrd images are easily upgradeable, as long as you have enough free space on the flash, so you should never need to remove the flash.
If you want to save things like dhcpd.leases on shutdown, you can simply set tardirs=var in /etc/rc.shutdown. If you want to do it manually (such as after you add or remove ports) then do: "tar cf /flash/var.tar -C /var ."
Sure, just fire up the 'flashimg' under qemu. The i386 version usually works with the i386 qemu emulator. The amd64 version works, but at the time of writing this entry, the amd64 qemu emulator isn't so good. Bochs is another option. These tools are best for prototyping a real system.
flashrd has several advantages over non-ramdisk read-only schemes like flashdist and other variations of it. It also has advantages over other ramdisk based systems.
flashrd boots from a ramdisk kernel with some basic utilities to mount a vnd image with all of your persistent partitions, and then untars the rest of the system on mfs. All partitions are defined in /etc/fstab, but are mounted by /stand/rc before the real /etc/rc is run. (The real /etc/rc is actually inside the vnd image, so this has to happen first! The partitions are remounted with the options in /etc/fstab by the real /etc/rc so you only have to change fstab to change how partitions are mounted.)
The layout can be changed (including the size of any partition) by editing variables at the top of the 'flashrd' script.
tardirs are directories that are mounted on pre-sized ramdisks, thus they are not saved upon reboot (unless defined in etc/rc.shutdown tardirs variable). They must be defined in flashrd, etc/rc.conf.local and optionally in etc/rc.shutdown (if you want them saved on each shutdown) (by default, /var is the only member of tardirs)
mfsdirs are pre-sized ramdisks, with no content loaded to them. They must be defined in flashrd. (by default, /tmp)
vnddirs are saved to the openbsd.vnd image and mounted read-only. They must be defined in the same order in flashrd, cfgflashrd, stand/rc, bin/ro and bin/rw (by default, /root, /etc, /bin, and /usr are vnddirs)
Some future version of the script will allow you to define subdirectories of a vnddir as a separate paritition in vnddirs (such as /usr/src mounted on top of /usr.) For today, /usr can only be a single partition.
On the flash boot image (which is mounted as /flash when booted under flashrd) you have three image files that define the whole system (well, whole system except the boot blocks and bootstrap script):
bsd
openbsd.vnd
var.tar
(Well, at least accoring to the default layout that defines 'var' as handled as 'tardirs'. If you moved var to 'vnddirs' then you would only have a flashrd ramdisk kernel and openbsd.vnd file.)
To upgrade, just upload the new image files to /flash/new, move the old files into /flash/old, move the /flash/new files to /flash, and then reboot:
cd /flash
mv bsd openbsd.vnd var.tar /flash/old
cd /flash/new
mv bsd openbsd.vnd var.tar /flash
reboot
If fsck -y or mount fails to mount any partition within /flash/openbsd.vnd (your default image), the bootstrap script will try to run with the /flash/old/openbsd.vnd image instead. Read /stand/rc to see exactly what happens. (It is fairly simplistic today, and could be improved upon for specific uses or general case.)
You can obtain new image files by building or downloading a new flashrd image, mounting the vnd file, and copying them out of the mounted partition.
gzip -d flashimg.i386-20120909.gz
vnconfig svnd0 flashimg.i386-20120909
mount /dev/svnd0a /mnt
cd /mnt
cp bsd openbsd.vnd var.tar /tmp
cd /tmp
umount /mnt
vnconfig -u svnd0
You could also try running mkkern and mkdist directly to obtain the raw FLASHRD bsd kernel, openbsd.vnd, and var.tar files, if you want to figure out how they work. It should be fairly easy to figure out, they will operate as stand-alone scripts, although primarily for my own purpose of debugging.
Stop using bash. Executing flashrd from bash seems to be problematic. OpenBSD's ksh has the features that most people use bash for anyways, such as command line history recall / editing and ksh's programmability (which gets attributed to bash by new comers.) Try it out, you'll find that installing bash is superfluous (and, at least in this case, harmful.)
I've had several compact flash ATA disks (mounted in read-write mode) get scrambled for no apparent reason (under multiple operating systems!) The issues that did not appear to be wear related (no bad sectors on read), and these systems did not often write to flash. Read-only mounts avoid some corruption that could otherwise happen. (It's also a basic preventitive measure to avoid dirty filesystems that fsck -p can't fix) The objective of flashrd is to create a system that runs reliably for many years, with a minimal chance of failure.
Copy your preferred time description file to /etc/localtime. Either look in /usr/share/zoneinfo for the right file or just copy /etc/localtime over from a box that already has the right timezone.
Just like a normal system, except you have to go to rw mode before installing, and we suggest going back to ro mode after. (Actually run the commands 'rw' and 'ro' to do this)