Re: About Restore and TMPDIR
jch wrote:[color=blue]
> After i figured out that i should be using release 3.6 to do a restore
> job, i ran into another issue. Restore needs the /tmp directory as
> working storage. When i restore a large system, the /tmp directory in
> RAM fills up instantly. To solve this problem, the restore man page
> says to set environment variable TMPDIR=/some_large_mounted_directory.
> Fine. When i do this, the restore does not recognise the environment
> variable properly, and the restore fails as /tmp fills up. Yet, it
> shows up as set when i ask for it via "set". Is this a known problem?
>[/color]
If the restore process is a subshell, you might have to export that
variable.
--
clvrmnky <mailto:spamtrap@clevermonkey.org>
Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
Re: About Restore and TMPDIR
Clever Monkey wrote:[color=blue]
> jch wrote:[color=green]
>> After i figured out that i should be using release 3.6 to do a restore
>> job, i ran into another issue. Restore needs the /tmp directory as
>> working storage. When i restore a large system, the /tmp directory in
>> RAM fills up instantly. To solve this problem, the restore man page
>> says to set environment variable TMPDIR=/some_large_mounted_directory.
>> Fine. When i do this, the restore does not recognise the environment
>> variable properly, and the restore fails as /tmp fills up. Yet, it
>> shows up as set when i ask for it via "set". Is this a known problem?
>>[/color]
> If the restore process is a subshell, you might have to export that
> variable.[/color]
_____
Of course. I keep forgetting to issue the export command! One should
always do it for good measure after setting an environment variable.
Thanks.
--
Regards / JCH
Re: About Restore and TMPDIR
jch wrote:[color=blue]
> Clever Monkey wrote:[color=green]
>> jch wrote:[color=darkred]
>>> After i figured out that i should be using release 3.6 to do a
>>> restore job, i ran into another issue. Restore needs the /tmp
>>> directory as working storage. When i restore a large system, the
>>> /tmp directory in RAM fills up instantly. To solve this problem, the
>>> restore man page says to set environment variable
>>> TMPDIR=/some_large_mounted_directory. Fine. When i do this, the
>>> restore does not recognise the environment variable properly, and the
>>> restore fails as /tmp fills up. Yet, it shows up as set when i ask
>>> for it via "set". Is this a known problem?
>>>[/color]
>> If the restore process is a subshell, you might have to export that
>> variable.[/color]
>
> Of course. I keep forgetting to issue the export command! One should
> always do it for good measure after setting an environment variable.[/color]
Typically, I'll decided what variables need to be exported to subshells,
and group those together so it is clear what I am doing, withing
cluttering up the subshell environment with garbage.
e.g.:
VAR1=foo
VAR2=bar
LOCALTMP="something local"
BLAH=Arrgh
export VAR1 VAR2 BLAH
--
clvrmnky <mailto:spamtrap@clevermonkey.org>
Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
Re: About Restore and TMPDIR
Clever Monkey wrote:
[color=blue][color=green]
>> Of course. I keep forgetting to issue the export command! One should
>> always do it for good measure after setting an environment variable.[/color]
>
> Typically, I'll decided what variables need to be exported to subshells,
> and group those together so it is clear what I am doing, withing
> cluttering up the subshell environment with garbage.
>
> e.g.:
>
> VAR1=foo
> VAR2=bar
> LOCALTMP="something local"
> BLAH=Arrgh
>
> export VAR1 VAR2 BLAH[/color]
_____
Good idea.
Do you care to comment on the more significant issue below?[color=blue]
> A recent Bare Metal Restore (BMR) of a OBSD 4.0 system failed! Why?
> To get this particular BMR job done i needed three hard disks in the
> machine at the same time . This meant that i needed devices /dev/wd1*
> and /dev/wd2*. Guess what? The OBSD boot/rescue floppy (or CD) after
> release 3.8 or so lost those devices in the /dev directory. You
> either make them manually, or use a copy of release 3.6 which has the
> devices i needed in the /dev directory. Why were devices wd1*, wd2*
> and wd3* dropped in more recent versions?[/color]
--
Regards / JCH
Re: About Restore and TMPDIR
jch wrote:[color=blue]
> Do you care to comment on the more significant issue below?[color=green]
>> A recent Bare Metal Restore (BMR) of a OBSD 4.0 system failed! Why? To
>> get this particular BMR job done i needed three hard disks in the
>> machine at the same time . This meant that i needed devices /dev/wd1*
>> and /dev/wd2*. Guess what? The OBSD boot/rescue floppy (or CD) after
>> release 3.8 or so lost those devices in the /dev directory. You
>> either make them manually, or use a copy of release 3.6 which has the
>> devices i needed in the /dev directory. Why were devices wd1*, wd2*
>> and wd3* dropped in more recent versions?[/color][/color]
Yeah, that is a mystery to me. Obviously, all the wd devices are in
4.0. I don't know about the rescue boot image, though. Which image are
you using? I find it hard to believe that /dev/wd* is missing from
cdrom40.fs, for example.
Assuming the support is in that kernel image, I guess you can just make
them by hand. Is MAKEDEV available on this image?
--
clvrmnky <mailto:spamtrap@clevermonkey.org>
Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
Re: About Restore and TMPDIR
Clever Monkey wrote:[color=blue]
> jch wrote:[color=green]
>> Do you care to comment on the more significant issue below?[color=darkred]
>>> A recent Bare Metal Restore (BMR) of a OBSD 4.0 system failed! Why?
>>> To get this particular BMR job done i needed three hard disks in the
>>> machine at the same time . This meant that i needed devices /dev/wd1*
>>> and /dev/wd2*. Guess what? The OBSD boot/rescue floppy (or CD) after
>>> release 3.8 or so lost those devices in the /dev directory. You
>>> either make them manually, or use a copy of release 3.6 which has the
>>> devices i needed in the /dev directory. Why were devices wd1*, wd2*
>>> and wd3* dropped in more recent versions?[/color][/color]
>
> Yeah, that is a mystery to me. Obviously, all the wd devices are in
> 4.0. I don't know about the rescue boot image, though. Which image are
> you using? I find it hard to believe that /dev/wd* is missing from
> cdrom40.fs, for example.[/color]
_____
No, only /dev/wd0* devices are on the RAM disk. I am using the floppy40
image. I don't know what is on the cdrom40.fs boot image. It actually
does not matter.
[color=blue]
> Assuming the support is in that kernel image, I guess you can just make
> them by hand. Is MAKEDEV available on this image?[/color]
_____
Clever folks those OpenBSD developers! Problem solved. Here is what i
found:
1) OBSD release 4.0 only has wd devices 0*
2) The /dev/MAKEDEV script exists
3) To make the required devices for, say, wd1 you simply do "cd /dev/ ;
sh MAKEDEV wd1". All devices are written to the current directory,
/dev/in this case.
I know that the install script makes devices on the hard disk at
installation time. So, there is a call to the /dev/MAKEDEV script on
the RAM disk somewhere.
When i do bare metal restores, i now know to add a step to create
devices in the /dev directory with /dev/MAKE. Simple enough. This is
probably documented on the OpenBSD web site, but i have not yet bothered
to look it up.
--
Regards / JCH
