Slices for non-nanoBSD?
-
I just got fed up with CF cards and went and ordered a couple of intel SSDs.
Can't beat it $50 after mail-in rebate for a 60GB SATA-3 SSD, when you spend $20 for a lousy CF card…This purchase also pretty much negates the need for nanoBSD on my remote pfSense box, because there I mostly wanted to avoid any mechanical parts prone to failure (plane trip needed to service the unit...) Hence a fanless system, etc.
There is however one thing that's very nice about the nanoBSD setup: two boot slices, which increase the chances of system recovery should one somehow get messed up. Is there a way to enable same/similar functionality on the regular build?
-
No, that function only exists for nanobsd right now.
There had been some plans to do that a while back, but they never materialized, there just wasn't a big demand (nor funding) to do it.
-
No, that function only exists for nanobsd right now.
There had been some plans to do that a while back, but they never materialized, there just wasn't a big demand (nor funding) to do it.
What sort of amount of work would it take, given that likely at least a good part from the nanoBSD work could be used?
Given how abundant and cheap storage has become, space isn't really an issue, and in a mission-critical piece of equipment like a gatway-router-firewall-remote-access-VPN-box (and possibly VoIP phone system), quick recovery would seem like a key feature. A few missteps, and it could mean taking a head-less system, taking it somewhere, hooking up screen, keyboard, reinstalling from scratch, restoring config, restoring packages, etc.
All said and done, the entire internet for the location is down for a day. Not even getting into what it would mean to e.g. have to fly on Thanksgiving halfway across the continent to try to fix a network appliance somewhere ;)
With two slices: switch to second slice, and things are up again, then clone one slice to the other. Done.
-
I'm not sure, but it would be pretty complex on the fdisk/format side of things to calculate and split the space, some of the nanobsd code could be re-used for switching slices but that's about it, that's not the hard part really.
The firmware upgrade code would have to be completely redone, since it wouldn't simply be imaging the whole slice (since it can't, NanoBSD upgrade images are disk slices, full upgrades are simply tgz overlays) and some other odd things I'm probably forgetting.
The bulk of the hard work is due to the fundamental differences between the image/install style of the two, and they aren't compatible really. And simply generating a larger NanoBSD image (say, 16GB+) wouldn't really be practical, though the builder does support it.
-
The bulk of the hard work is due to the fundamental differences between the image/install style of the two, and they aren't compatible really. And simply generating a larger NanoBSD image (say, 16GB+) wouldn't really be practical, though the builder does support it.
Well, yes, besides one would lose all the various advantages of the rw file system.
I mean, it's not like we would have to switch back and forth all the time. It would be OK to have a main system, that acts just as what we have now, with some logic to fall back on an alternate slice if things go haywire.
I'm less concerned about the A/B/A/B/A/B thing that nanoBSD does than about having something that can be easily, preferably automatically be booted if the main partition gets screwed up, and allows the system to be fixed remotely.So I don't mind living 99% on partition A, updating partition A, etc. as long as I can easily fall back on a partition B with a fall-back configuration. Key would only be that both partition A and B have the ability to wipe and reinstall the non-active partition, and dump a known-to-work configuration on the other partition.
So I guess what would be needed is that the original installer can make the extra partition(s) needed, and that the regular system gains the ability to download and install on the other partition, a full fresh installation, and then restore some configuration to that other partition, and then switch the boot partition.
Basically, if there were a rescue partition that only needs a password and a valid WAN address set, and if booted from that, one could reinstall the other partition from a web interface, and then restore a backed up configuration to that other partition, then that would cover things. So it's not really needed to have two fully functional installs. On the other hand, it may be more hassle to maintain a rescue system than to just put that ability to install/restore another partition into the regular system, so in that case there would simply be two systems installed, that can each nuke/restore the currently unused partition, and switch the slice booted from.
Heck, since during install one can do custom partitioning, I wouldn't mind if the initial install would be mostly manual work following some how-to write-up, as long as in the end it's possible to easily image a system install on the other partition, and restore a configuration to it without having physical access to the device.
