Contributed by deanna on from the user-blog dept.
Using the dump(8) command on a running OpenBSD system, it is possible to dump a filesystem image to a remote machine via an NFS mount or by using SSH... This involves issuing:
# export RSH=/usr/bin/ssh
before the actual dump(8) command. However, when one needs to perform the restore after having booted from an i386 bsd.rd image, he/she will quickly realize that the ssh binary is not available in the ramdisk image, nor is the nfs_mount binary, which automatically precludes one from the possibility of performing a network restore via NFS.
In light of this, how can a network restore be performed if the only possiblity of running restore(8) is to first boot from an i386 bsd.rd image? Well, if the dumpfile(s) is/are available on an accessible server running an FTP or HTTP server the ftp(1) program can be used to retrieve these files from the server and feed them to restore(8).
Although ftp(1) will, by default, download a file to the current directory giving it the same name it had on the FTP or HTTP server, by using the -o option an alternate file/location can be specified, including stdout. So, by issuing:
# ftp -o - http://<SITE>/<path>/<to>/<file>
the downloaded file will be sent to stdout.
In complementary fashion, the restore(8) command can also read a dumpfile from stdin using this syntax:
# restore -rvf -
Therefore, by piping ftp(8)'s output to the restore(8) program it's possible to perform a restore from a dumpfile stored on a remote server.
Using this syntax:
# ftp -o - http://<SITE>/<path>/<to>/<dumpfile> | restore -rvf -
or this syntax:
# ftp -o - ftp://<username>:<password>@<SITE>/<path>/<to>/<dumpfile> | restore -rvf -
you can restore from a dumpfile located on a remote HTTP or FTP server.
NOTE: The version of ftp(1) included on the bsd.rd ramdisk does not support HTTPS.
One very important to take into account when restoring via a bsd.rd image is that because restore(8) uses temporary files located in the temporary directory, and considering that the ramdisk offers a rather limited-size temporary files directory, it will usually be necessary to specify an alternate location (i.e. on an accessible hard disk) to store temporary files when trying to restore large filesystems (such as /usr). This is discussed in more details in this post.
CREDIT: After I asked the question on the @misc list that spawned this mini-article, Michal Soltys was the one that suggested using ftp(1)'s -o option to pipe the output to restore(8), and Henning Brauer pointed out the lack of https support in the ramdisk's version of ftp.
(Comments are closed)
By Venture37 (149.9.0.56) venture37 (AT) hotmail (DOT) com on www.geeklan.co.uk
Comments
By Anonymous Coward (69.70.207.240) on
Wow, great site! Wish I knew about this before, I'll spread the word too.
Comments
By Daniel Ouellet (66.63.10.94) daniel@presscom.net on
I can add it when/if I get the permission form the author.
> Wow, great site! Wish I knew about this before, I'll spread the word too.
Well, could be much better really, but it's a start. Only as good as the users what's to make it. (:>
For them by them.
Daniel
By jirib (89.24.4.71) on
maybe one could be so nice and update the howto to help openbsd users to make their own ramdisk to do full automatic tasks :)
Comments
By Anonymous Coward (24.46.21.229) on
>
> maybe one could be so nice and update the howto to help openbsd users to make their own ramdisk to do full automatic tasks :)
http://www.onlamp.com/pub/a/bsd/2005/07/14/openbsd_live.html
is pretty good. Used it to make a JumpStart-ish environment for my local setup here; I'll be creating more for the other OpenBSD machines here too (sparc 64/32, macppc...). THere are many others on the net as well.
By Anonymous Coward (69.70.207.240) on
>
> maybe one could be so nice and update the howto to help openbsd users to make their own ramdisk to do full automatic tasks :)
I started working on a shell script a while back (while I was learning shell scripting), with documentation, but it's been sitting at 95% complete for a while now... My intention was also to make a version 2, 100% fully automated install with an automated custom kernel config, based on user prompts/input or menu based but I haven't had the time to keep working on it and keep studying...
It's main intention was to help automate the install of OpenBSD -STABLE (any version) using release(8) on a WRAP device (similar and to be compatible to Soekris installations), but capable of working on IDE Flash, USB Flash, Compaq Flash, SD, etc... as well.
The install works using PXE + TFTP + FTP and of course, some basic DHCP magic... It started as an idea and I'm sure a lot of people could improve on the ideas I started, just not sure who or where I could post it if others would like to improve on it more or may have use for it?
Oh, yeah, and of course it runs entierly in an MFS with the main Filesystems as Read-Only and sync's to flash using rsync... It's also similar, but different, to flashdist, OpenSoekris, CompactBSD, etc.
If anyone might be interested in this, let me know and I'll try to clean it up this weekend some time.
Comments
By Anonymous Coward (69.70.207.240) on
> >
> > maybe one could be so nice and update the howto to help openbsd users to make their own ramdisk to do full automatic tasks :)
>
> I started working on a shell script a while back (while I was learning shell scripting), with documentation, but it's been sitting at 95% complete for a while now... My intention was also to make a version 2, 100% fully automated install with an automated custom kernel config, based on user prompts/input or menu based but I haven't had the time to keep working on it and keep studying...
>
> It's main intention was to help automate the install of OpenBSD -STABLE (any version) using release(8) on a WRAP device (similar and to be compatible to Soekris installations), but capable of working on IDE Flash, USB Flash, Compaq Flash, SD, etc... as well.
>
> The install works using PXE + TFTP + FTP and of course, some basic DHCP magic... It started as an idea and I'm sure a lot of people could improve on the ideas I started, just not sure who or where I could post it if others would like to improve on it more or may have use for it?
>
> Oh, yeah, and of course it runs entierly in an MFS with the main Filesystems as Read-Only and sync's to flash using rsync... It's also similar, but different, to flashdist, OpenSoekris, CompactBSD, etc.
>
> If anyone might be interested in this, let me know and I'll try to clean it up this weekend some time.
Ooops, forgot to mention, it does do a 'full' install rather then a cut down version, which was what I needed at the time.
By Anonymous Coward (213.196.227.110) on
http://www.mirbsd.org/current/i386/bsd.rd contains ssh (and sshd!)
and is largely OpenBSD compatible, except you can't install it from
that image. It isn't hard, just required some tweaking and more RAM.
Speaking of RAM, we just mount_mfs on /tmp during boot... thus
avoiding the issue with temporary files. This was necessary even
for pax/tar/cpio.
Comments
By Anonymous Coward (143.166.226.42) on
> and is largely OpenBSD compatible, except you can't install it from
> that image. It isn't hard, just required some tweaking and more RAM.
And who cares about mirbsd again? Dude can't you just leave and create your own lists?
By Julien (81.57.235.161) on
# disklabel -F <file> wd0
# something like this (on linux)
sfdisk -d dsk > file
cat file | sfdisk dsk
thanks
Comments
By Anonymous Coward (82.154.117.137) on
> # disklabel -F <file> wd0
>
> # something like this (on linux)
> sfdisk -d dsk > file
> cat file | sfdisk dsk
>
> thanks
>
You may try to use dd
dd if=/dev/wd0 of=wd0.raw bs=512 count=1
dd if=wd0.raw of=/dev/wd0 bs=512 count=1
Comments
By sthen (85.158.44.148) on
>
> dd if=/dev/wd0 of=wd0.raw bs=512 count=1
> dd if=wd0.raw of=/dev/wd0 bs=512 count=1
that's the MBR and DOS-style partition table, not the (BSD) partition table. or, at least, it would be if you used the correct device file (you want the c partition, /dev/wd0 does not exist).
Comments
By Anonymous Coward (82.154.117.14) on
> >
> > dd if=/dev/wd0 of=wd0.raw bs=512 count=1
> > dd if=wd0.raw of=/dev/wd0 bs=512 count=1
>
> that's the MBR and DOS-style partition table, not the (BSD) partition table. or, at least, it would be if you used the correct device file (you want the c partition, /dev/wd0 does not exist).
The bsd partition table can be restored from/to file with disklabel. And you're right, it should be wd0c.
By sthen (85.158.44.148) on
yes - see the manual page.
Comments
By Anonymous Coward (81.57.235.161) on
>
> yes - see the manual page.
be more precise, else it is useless.
$ man disklabel|grep silent
$ man disklabel|grep auto
$
Comments
By sthen (85.158.44.146) on
> >
> > yes - see the manual page.
>
> be more precise, else it is useless.
it isn't useless, if you know something is certainly there, it may give you the incentive to spend the extra minute or two reading through the options...
> $ man disklabel|grep silent
> $ man disklabel|grep auto
try "restore".