On 14-10-27 01:14 PM, Steve Williams wrote: > Hi, > > I have an older system on physical hardware that needs upgrading. I've > been procrastinating because it's the type of thing that needs to be > done from start to finish, and it's rather out of date (OpenBSD > 5.2-current) so I know there will be all sorts of surprises. The big one is the time_t flag day, of course... from 5.2 to 5.4 won't be too painful. From 5.4 to 5.5 will be painful unless you're running a pure OpenBSD system with no ports, packages, or self-compiled binaries. Then 5.5 to 5.6 should be pretty normal again.
> I had (what I think is) a great thought today that maybe I could > (somehow) restore a backup from my physical hardware into the > Virtualbox VM and do a "test" upgrade there, figuring things out bit > by bit with no pressure of my system being down. Once I had the > upgrade process figured out, I'd then be better prepared to do it to > my physical system. This works, usually. Be careful to isolate the VM on an disconnected network segment when you first bring it up, lest you have conflicting IP addresses. > I have never done a dump/restore of a complete system before. I do > know that on my physical system, the hard disk is sd0 whereas the VM, > it's wd0 (with an OpenBSD 5.5 install... yes, I know 5.6 is > imminent). Not a big deal to tweak /etc/fstab though. No, it's not a big deal to edit fstab. If you use DUIDs those will AFAIK break as well. > I'm reasonably comfortable with dump/restore, but not to completely > "clone" a system. Before I explain any further, please make sure you've read http://www.openbsd.org/faq/faq14.html#Backup and http://www.openbsd.org/faq/faq10.html#DupFS . It may be much easier to just reinstall at this point; you'll have to go 5.2 -> 5.3 -> 5.4 -> [major upgrade here] -> 5.5 -> 5.6. That's a lot of upgrading, and the 5.4 to 5.5 step requires you to uninstall and reinstall all your packages/ports anyway. However, if you want to proceed: From an OpenBSD bsd.rd (i.e. typically boot from ISO) of comparable version to your *source* system, you'll want to: - fdisk the new (virtual) disk, - disklabel the new (v)disk, - newfs the new root filesystem, - newfs any other on-disk filesystems you need to restore, - restore the entire dump onto the root filesystem, - mount the other filesystems (assuming they're all one level deep), - restore them individually, - installboot the new (v)disk, - reboot, - fix everything, - boot from the *next* version's ISO (From upgrade55.html: /"Note: Upgrades are only supported from one release to the release immediately following it. Do not skip releases. If you got lucky skipping releases in the past, you may not this time.//"/) - run the in-place upgrade - fix everything - boot from the *next* version's ISO - fix everything - lather, rinse, repeat, until you're on 5.6-RELEASE. Note that this typically means either having the network up and running from inside the new machine, or having your entire dump reside on a device somehow accessible to the bsd.rd environment inside the VM. Some people use USB-attached disks for this, some use NFS mountpoints, YMMV. If doing this over the network, you can avoid the need to store an image of your system; use something like (from the target system) "ssh oldsystem dump -0af - / | ( cd /mountpoint ; restore -rf - )" or from the source system "dump -0af - / | ssh newsystem "(cd /mountpoint;restore -rf -)". Another approach is to boot both systems into single-user mode, bring up networking on both, and use dd(1) over the wire to copy an exact bit-wise image of the source disk... this is probably unnecessary and will take much longer than a dump/restore pass, especially if you dump(8) to a fast storage medium of some sort and then you can restore at your leisure as many times as you want. > How can I do a dump of the root filesystem over top of a running > system (in the VM)? Does it have to be in single user mode? Yes, it should be in single-user mode. In fact, you should have booted from another device altogether. And you don't do that in the first place, see above. > Are there any other things that are going to need to be tweaked other > than /etc/fstab? /etc/hostname.* , /etc/mygate > Am I going to need to run installboot or some other such utility to > get it to boot correctly after a restore? Yes. > Any thoughts of this idea in general? It's a fairly safe way to test upgrades. Keep in mind that any bugs w.r.t. VirtualBox or w.r.t. the physical hardware won't show up in the other environment. There are about as many ways to do this are there are system administrators reading this list; I've only outlined some of the more common techniques. You could also restore an entire system using Amanda, Bacula, BackupPC, or even just tar(1). Oh, and note that while you can run dump(8) on a running, multi-user system, the resultant dumpset is not atomically self-consistent. Depending on your workload this could either be a non-issue or it could be a deal-breaker. Running dump(8) from single-user mode should always produce a consistent dump. For more information on that problem, read http://dump.sourceforge.net/isdumpdeprecated.html . While OpenBSD's dump(8) is not the same program, the user-visible behaviour in this respect is fundamentally similar. And OpenBSD's FFS/FFS2 does not have snapshots to take care of this. Hopefully someone will suggest a way to deal with this problem under OpenBSD that I'm not aware of... -- -Adam Thompson [email protected]
