Date: Wed, 07 Feb 2001 10:57:40 -0600 From: Mike Bytnar <mbytnar@auvo.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: FreeBSD <freebsd-stable@FreeBSD.ORG> Subject: Re: 'make installworld' fails over NFS mount Message-ID: <3A817E84.1B3EAECE@auvo.com> References: <3A808528.C51E4FBF@auvo.com> <20010206155841.C26076@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Thank you for the suggestion! I moved the existing /usr/obj and /usr/src on
the client machine, then mounted the build machine's /usr/obj and /usr/src
into the respective client path.
The client install progressed a little further this time. The log shows:
===> lib/libcom_err
[...etc...]
install -c -o root -g wheel -m 444 libcom_err.a /usr/lib
install -c -o root -g wheel -m 444 libcom_err_p.a /usr/lib
install: libcom_err_p.a: No such file or directory
*** Error code 71
Stop in /usr/src/lib/libcom_err.
*** Error code 1
[...etc...]
On the build machine, there is no such library named "libcom_err_p.a" it does
however use "libcom_err_so.2":
install -c -s -o root -g wheel -m 444 libcom_err.so.2 /usr/lib
ln -sf libcom_err.so.2 /usr/lib/libcom_err.so
[...etc...]
Why would the client machine look for libcom_err_p.a instead of the
libcom_err.so.2? Rather, in what file can I toggle the install to look for
the shared object instead?
Also, anyone else notice that the /tmp directory gets cluttered up with
"install.*" directories whenever an installworld fails? Is there a
recommended means to cleanup these directories, or is "rm -rf /tmp/install.*"
sufficient after a failed install?
Thanks,
--Mike
Alfred Perlstein wrote:
[...]
> [snip]
>
> >
> >
> > Is there a workaround for this problem?
>
> Yes.
>
> This bug has been in the tree for quite some time now, basically
> you have to have the nfs mount over the same location as the nfs
> server's build location.
>
> so if on the server you really have:
>
> /usr/src -> /vol/src
> /usr/obj -> /vol/obj
>
> on the client you'll need to have
>
> /usr/src -> /vol/src
> /usr/obj -> /vol/obj
>
> and you'll need to mount the nfs share on /vol/src and /vol/obj on
> the client otherwise it breaks.
>
> Btw, this bug is terribly annoying, it's been around for so long
> that I've given up on tracking down how/where it happened and
> who did it. If anyone can figure out a way to fix this, it'd be
> nice.
>
> --
> -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> "I have the heart of a child; I keep it in a jar on my desk."
[-- Attachment #2 --]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Thank you for the suggestion! I moved the existing /usr/obj and /usr/src
on the client machine, then mounted the build machine's /usr/obj and /usr/src
into the respective client path.</tt><tt></tt>
<p><tt>The client install progressed a little further this time. The log
shows:</tt>
<br><tt> ===> lib/libcom_err</tt>
<br><tt> [...etc...]</tt>
<br><tt> install -c -o root -g wheel -m 444
libcom_err.a /usr/lib</tt>
<br><tt> install -c -o root -g wheel -m 444
libcom_err_p.a /usr/lib</tt>
<br><tt> install: libcom_err_p.a: No such file or directory</tt>
<br><tt> *** Error code 71</tt><tt></tt>
<p><tt> Stop in /usr/src/lib/libcom_err.</tt>
<br><tt> *** Error code 1</tt>
<br><tt> [...etc...]</tt><tt></tt>
<p><tt>On the build machine, there is no such library named "libcom_err_p.a"
it does however use "libcom_err_so.2":</tt>
<br><tt> install -c -s -o root -g wheel -m 444
libcom_err.so.2 /usr/lib</tt>
<br><tt> ln -sf libcom_err.so.2 /usr/lib/libcom_err.so</tt>
<br><tt> [...etc...]</tt><tt></tt>
<p><tt>Why would the client machine look for libcom_err_p.a instead of
the libcom_err.so.2? Rather, in what file can I toggle the install to look
for the shared object instead?</tt><tt></tt>
<p><tt>Also, anyone else notice that the /tmp directory gets cluttered
up with "install.*" directories whenever an installworld fails? Is there
a recommended means to cleanup these directories, or is "rm -rf /tmp/install.*"
sufficient after a failed install?</tt><tt></tt>
<p><tt>Thanks,</tt>
<br><tt>--Mike</tt>
<br><tt></tt> <tt></tt>
<p><tt>Alfred Perlstein wrote:</tt>
<br><tt>[...]</tt>
<blockquote TYPE=CITE><tt>[snip]</tt><tt></tt>
<p><tt>></tt>
<br><tt>></tt>
<br><tt>> Is there a workaround for this problem?</tt><tt></tt>
<p><tt>Yes.</tt><tt></tt>
<p><tt>This bug has been in the tree for quite some time now, basically</tt>
<br><tt>you have to have the nfs mount over the same location as the nfs</tt>
<br><tt>server's build location.</tt><tt></tt>
<p><tt>so if on the server you really have:</tt><tt></tt>
<p><tt>/usr/src -> /vol/src</tt>
<br><tt>/usr/obj -> /vol/obj</tt><tt></tt>
<p><tt>on the client you'll need to have</tt><tt></tt>
<p><tt>/usr/src -> /vol/src</tt>
<br><tt>/usr/obj -> /vol/obj</tt><tt></tt>
<p><tt>and you'll need to mount the nfs share on /vol/src and /vol/obj
on</tt>
<br><tt>the client otherwise it breaks.</tt><tt></tt>
<p><tt>Btw, this bug is terribly annoying, it's been around for so long</tt>
<br><tt>that I've given up on tracking down how/where it happened and</tt>
<br><tt>who did it. If anyone can figure out a way to fix this, it'd
be</tt>
<br><tt>nice.</tt><tt></tt>
<p><tt>--</tt>
<br><tt>-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]</tt>
<br><tt>"I have the heart of a child; I keep it in a jar on my desk."</tt></blockquote>
<tt></tt></html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A817E84.1B3EAECE>