Fwd: Re: Unusual Question
markham at ssimicro.com
Mon Jul 10 22:14:48 UTC 2017
In the past, I hijiacked /boot with mfsbsd which loaded into a RAM disk,
making the HDD available for whatever shennanigans I needed. This was
about 5 years ago, so my memory is a bit fuzzy on the details, but I do
remember heavily testing that on the bench before deploying it, as you
only get one shot at something like that :) (same case, remote,
unmanned sites, cost $$$K to get someone on-site)
From my old notes, this is exactly what we did, and since you are
running entirely from RAM disk, you aren't worried about trashing your
kernel or /dev. I used it to re-partition and upgrade the remotes, but
if all you need to do is nuke 'em you should be fine. The build process
requires you to provide the rc.conf from the target machine:
* build mfsbsd image and install to remote (Your target PD).
make tar BASE=/cdrom/8.1-RELEASE
mv mfsbsd-8.1-RELEASE-p8-i386.tar /tmp/target-mfs81.tar
*STOP! At this point it's best to verify your image is configured
properly. If you install a misconfigured image on your target there is
NO way to fix it remotely.* Something simple as forgetting to make
clean can bugger up the whole process since the old configs from a prior
build will remain in the tmp directory.
ssh root at target
scp root at myhost:/tmp/target-mfs81.tar /tmp
mv /boot /boot.old
tar -x -C / -f /tmp/target-mfs81.tar
* cross fingers
* Verify HDD device node by looking at output from "mount" (should be
* login (password is mfsroot)
* Nuke that sucker!
dd if=/dev/zero of=/dev/ad2 bs=1k count=1
gpart create -s gpt /dev/ad2
That might give you a good starting point though.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 230 bytes
Desc: OpenPGP digital signature
More information about the freebsd-questions