View Single Post
  #4   (View Single Post)  
Old 12th May 2012
comet--berkeley comet--berkeley is offline
Real Name: Richard
Package Pilot
 
Join Date: Apr 2009
Location: California
Posts: 163
Default

Thank you ocicat and jggimi for the responses.

Quote:
Originally Posted by ocicat View Post
/usr/src/sys
  • Is the time in the new kernel set correctly?
  • Was DESTDIR set before issuing make distrib-dirs?
The instructions in Section 5.3.5 of the
FAQ must be followed exactly. Unlike building the kernel, userland [I]must[/I
] be built as root.
I believe that the time was set correctly. What would "time in the new kernel" set incorrectly look like?

The DESTDIR is a possible issue. Before building 5.1-stable, I successfully built 5.0-stable and left two exports in the root .profile from building the 5.0-stable distribution:

export DESTDIR=/usr/dest
export RELEASEDIR=/usr/rel

I had to remove these before the 5.1 "make build" would allow the world to be built but they were probably in place during the "make distrib-dirs"

cd /usr/src/etc && env DESTDIR=/ make distrib-dirs

Doesn't the env DESTDIR override the previous export DESTDIR?

I did not really have any problems with the "make build" except the observer.sh script.

The observer.sh shell script would not execute without an explicit "sh" in front of it. After the "make build" failed I looked at the execute permissions on the script and they appeared to be 755.

The build ran for over two hours making everything ok up to the point where the Gnu gdb debugger was built and the observer.sh script was part of the gdb build.

Quote:
Originally Posted by jggimi View Post
The rules for -stable patch commits prohibit library or tool chain changes of any kind. Therefore, there is an extremely high likelihood that a -stable build failure is due to an operational error of some kind. Hardware problems (cpu heat stress, RAM errors) are another possibility, but is not applicable in the case described in this thread.

Ocicat described several common problems -- another is sometimes the wrong source tree. You can check to ensure your /usr/src tree is indeed -stable. Review any .../CVS/Tag file in /usr/src to be sure the cvs(1) working directory is using source tagged with OPENBSD_5_1, the tag for 5.1-stable.

---
Edited to add: I'm not stating that "incorrect source code tree" is your problem, merely pointing out that in the general case this is something to double check if and when a build problem arises.
I checked the source tree and did not see anything wrong. I downloaded the source from an ftp site and checked the file sizes from another ftp site.

Is there a checksum somewhere for the src.tar.gz, and sys.tar.gz files?

In the recent past I successfully built 5.0-stable using the patch method.

For 5.1-stable I tried both the patch method and the CVS method and both failed with the observer.sh script.

The usual cause of this kind of problem is a lack of execute permissions on the file.

But why only the observer.sh script? And why did the build work fine for two hours before it got to the Gnu gdb part and the observer.sh script?

And why did not any other scripts fail? I changed the execution of observer.sh to "sh -e observer.sh" and the whole build worked fine.
Reply With Quote