On 07/17/17 05:50, Raimo Niskanen wrote: > On Fri, Jul 14, 2017 at 10:46:14PM -0400, Nick Holland wrote: >> On 07/14/17 09:00, Raimo Niskanen wrote: >> > Hi misc@. >> > >> > I wonder how to restore from an /altroot backup? >> > >> > (I missed that pax -r happily writes absolute paths and wrote over >> > /etc from a backup file of another machine) >> > >> > >> > Is it to dd(1) back all but the first 16 blocks - the reverse of what >> > daily(8) does? Is that all that is needed? >> >> don't... >> >> > (I missed to skip the first 16 blocks, and I used the block devices instead >> > of the character devices. The result was a vegetable, and would like to >> > understand which of my mistakes that were fatal.)
probably worth answering why this failed... 1) The first 16 blocks are where the disklabel is hiding on the first partition (usually, 'a'). Blindly copy over a disklabel from the wrong disk, you will blow away your current disklabel. BEST case (both disks have the exact same layout), you just changed the DDUID of your target disk. 2) writing to sd0a/wd0a instead of rsd0a/rwd0a just drops the data in the wrong place. This error probably saved your disklabel, so it's a good error to combine with the first. Didn't help anything, but kept the damage from being worse. >> yeah, that's why. It CAN work, but ... it is the hard way and it's >> error prone. >> >> better way: let's say sd1k is your /altroot... >> >> # mount /dev/sd1k /altroot >> >> now...it's just a normal file system on a normal place. Copy out >> whatever you want. umount it when done, please. >> >> Nick. > > Yes, thank you! That is the safe way. In this case I wanted to get rid > of all files that my pax fumbling had put there, so I wanted to clear the > root filesystem and copy back all from /altroot. But then I also would > have ro run installboot on the restored root filesystem, right? > > Is that the right(tm) way to do it? If you copy files from any backup back to root, yes, you will need to re-run installboot. This has to be done any time /boot could have moved to a new physical spot on the disk. If you really want to blow things completely away, give consideration to doing an "upgrade" (to either what you were running or most recent release, or even -current), then restoring your /etc/ directory, and re-running sysmerge afterwards (if you change versions). Nick.
