Peter Bako [pe...@bakonet.org] wrote: > (http://www.kernel-panic.it/openbsd/embedded/)
Doing this by hand is strange. It's only worth doing if you already understand what you're doing (and you have a specific need) or if you want to spend a bit of time learning. This guide and various others like it were written by the example of flashdist (which I came up with to put OpenBSD on cheap 32MB flashes some 10 years ago.) The whole point of scripting it is to create less work. That way you don't have to follow a bunch of repetitive, time consuming steps (and still get it wrong.) This isn't to say that flashdist does everything right (not by a long shot.) Flashdist wasn't really the end result I wanted, it's too hard to upgrade and too custom to be useful in many applications. In fact, now that you can get a 8GB flash for 1/2 the price that a 32MB flash cost 10 years ago, flashdist looks pretty stupid. You're not going to get help with bizarre r/o operating issues from very many people. The tool either "works" for you, you can fix the problems, or it's broke. In your case, you need /dev to be writeable. flashdist actually does that by mounting /dev as an MFS, but for some reason this "OpenBSD embedded" guide ignores that step completely. (MFS is just a hack, a devfs-type filesystem would be a better solution.) I still like the idea of R/O installs, so I came up with flashrd last year. I'm sure you could buy nice, high end flash that would work fine in R/W installs for two or four years. Why not minimize downtime in simple, practical areas like this? Hell, I continue to kill R/W flash (last year, I killed a brand new SuperTalent server-class SLC SSD after 1 month of use, testing some huge and scary Java NMS app, jffnms or something like that. This app is an extreme example, while monitoring 1500 devices, it kept the SSD maxed out much of the time) flashrd fixes two problems with the old technique - upgrades are now trivial with the full operating system being stored in a vnd image (a modern flash is large enough to hold multiple, discrete copies), and the system is close to "default" - everything works, everything appears where it should and modifications are pretty much just as easy as on a default system. But you have to think about the layout, especially during setup or upgrade. (ramdisk mounting disk on /flash, /flash contains vnd partitions that you can mount to /bin, /usr, etc, runs rw or ro on demand) Again you won't get any help with bizarre upgrade issues here. You have to spend time with it and know how the shit works. Unfortunately flashrd isn't terribly intuitive, the process driven by the scripts is a bit more complicated than flashdist, you have to look over various settings at the top of the main script to understand how to customize your partition layout and such. So while various people claim that flash works just as well, if not better than hard disks for regular usage, I still like to err on the side of less writes. Seriously, how often do you write to a consumer grade CF card with a camera? These sort of tools are really for people rolling out specific appilances, in multiples. VPN/firewall, BGP/OSPF router, phone server, etc... Then you can use the same tool to give your user a new image they can just drop in place (or you can remotely) with almost no effort during the upgrade (just in preparation of the image.) And then flashboot may be a better choice if you are going to customize it down to a very small system. flashrd is nice if you want a full, r/w on demand environment that feels like home.
