Hiya. I wish I'd caught this before I started drinking. Nevermind.
As others have said: * CF cards are cheap. Do yourself a favour and buy a card at least big enough to take the required sets with some leg room. http://www.openbsd.org/faq/faq4.html#FilesNeeded * Don't use a frankenstein installer. Especially if you are a noob. Especially if they don't explain the "whys" and not only the "hows". Don't paint by the numbers. Personally when I bought my "box" I bought two 256MB CF cards. When I install the latest release I pull one out (that's my last stable install), insert the other one and install over the network - use PXE and have a desktop serving tftpboot. Result? Off the shelf, straight to the media in its intended environment, OpenBSD install. Have a problem? Put the old card back in. Success? Pop the old card in a drawer for next release. http://www.openbsd.org/faq/faq6.html#PXE Simple answer to your problem. CF cards don't wear. I have been doing this for a few years now. RW everything. Standard install over the network (PXE and tftpboot). Plenty of other people share this view. So you're still interested in RO? > 1) To learn more about OpenBSD itself. Solving all of the issues that have > come up so far has been very beneficial and I've enjoyed the process Doing a standard install and attempting to reduce write access on your own steam is a much better pursuit than looking for somebody elses "how" and not "why" guesstimation of making OpenBSD RO. Try reading man hier for a really good start. As an example, you could spend half a day (or longer if you're dopey like me) reading man syslog, man newsyslog, man cron. All my logs are in RAM (either using buffers or mfs mounted file systems). What did I achieve? Well I removed 25% of my disk thrashing (actual result may vary, see your doctor, etcetera) but much more importantly I read these man pages and absorbed the consequences (not inclusive) - cron, crontab, syslogd, syslog.conf, newsyslog.conf, daily, etcetera. I learnt about message levels (an important system wide concept) and a whole lot more. I know exactly where all my logs go and how to read them and how to bump up the level of logging when I need to. Not only have I satisfied my less disk writing aim I've also learnt a useful skill for any install environment. > I had a > few minor issues crop up, but have been able to work my way through them. I think it's better to learn common administration procedures than half understood methods that don't apply to other environments (a desktop say). My experience is that the "paint by the numbers, obtuse pre-installation" setups are poorly documented (specifically for the target audience - noobs). Well intentioned perhaps but off the mark. If you don't have the skillset to run a non generic kernel don't do it. If you can't understand some installation script don't use it. Etcetera. FWIW, I do have /dev in RAM but it's not using 'populate' or some other method. Want to know how? Read man fstab and man makedev and man rc. Learn a whole lot and build a frankenstein that you understand. What's the punch line? This is again out of sphere and not a situation that should crop up on misc@ ... I won't be writing to misc@ asking questions about my RAM mounted /dev. If I can't solve my own problem I'll either be trying to reproduce it on my desktop or changing my mount (because I like to play it safe this will probably mean re-installing release) or reading a whole lot more man pages. You're on your own. Best wishes.
