Issues with source update 9.1 to 9.2-RELEASE

M

mrmagoo

Maybe it's me, it's happened before, is anyone having problems doing a source upgrade to 9.2? Wouldn't go in 9.1-p4 so I downgraded the source to 9.1 updated to p7 and still breaks in the same place. Happens in xorg, happens on console, always in the same place.

I've deleted /usr/obj, gotten used to it with 9.1 some files are set immutable, and have to manually wipe the flags to delete them, but that is another issue. But perhaps I did something I can't figure out how to fix to the system that is causing that too.

Code: 
make buildworld
foo...
bar...
...
===> bin/cat (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/bin/cat created for /usr/src/bin/cat
rm -f .depend
mkdep -f .depend -a    -I/usr/obj/usr/src/tmp/legacy/usr/include -std=gnu99   /usr/src/bin/cat/cat.c
echo cat: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend
cc -O2 -fno-strict-aliasing -pipe -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/bin/cat/cat.c
cc -O2 -fno-strict-aliasing -pipe -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include  -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cat cat.o -legacy
install -C -s -o root -g wheel -m 555   cat /usr/obj/usr/src/tmp/legacy/bin/cat
===> usr.bin/lorder (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/lorder created for /usr/src/usr.bin/lorder
install -C -o root  -g wheel -m 555  /usr/src/usr.bin/lorder/lorder.sh  /usr/obj/usr/src/tmp/legacy/usr/bin/lorder
===> usr.bin/makewhatis (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/makewhatis created for /usr/src/usr.bin/makewhatis
rm -f .depend
mkdep -f .depend -a    -I/usr/obj/usr/src/tmp/legacy/usr/include -std=gnu99   /usr/src/usr.bin/makewhatis/makewhatis.c
echo makewhatis: /usr/lib/libc.a /usr/lib/libz.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend
cc -O2 -fno-strict-aliasing -pipe -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/makewhatis/makewhatis.c
cc -O2 -fno-strict-aliasing -pipe -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include  -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o makewhatis makewhatis.o -lz -legacy
install -C -s -o root -g wheel -m 555   makewhatis /usr/obj/usr/src/tmp/legacy/usr/bin/makewhatis
install -C -o root  -g wheel -m 555  /usr/src/usr.bin/makewhatis/makewhatis.local.sh  /usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
/usr/obj/usr/src/tmp/legacy/usr/libexec/catman.local -> /usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
install: illegal option -- l
usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 file2
       install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 ... fileN directory
       install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** [_installlinks] Error code 64

Stop in /usr/src/usr.bin/makewhatis.
*** [bootstrap-tools] Error code 1

Stop in /usr/src.
*** [_bootstrap-tools] Error code 1

Stop in /usr/src.
*** [buildworld] Error code 1

Stop in /usr/src.
Fails

current system 9.1-RELEASE-p7 #0 r256009:

Code: 
svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-east.freebsd.org/base/releng/9.2
Relative URL: ^/releng/9.2
Repository Root: https://svn0.us-east.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 256032
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 255896
Last Changed Date: 2013-09-26 14:10:19 -0400 (Thu, 26 Sep 2013)
 
An upgrade to 9.2-Release should include world. Some things are sure to have changed.

@mrmagoo, the error looks like an old version of install(1) is being used. Why that is happening is hard to guess. Please show exactly what you did to downgrade, and then what commands you used to start the build. Also, what is in /etc/make.conf?
 
Last edited by a moderator:
Yesterday, I used those commands I posted and didn't do any "build world", it is running just fine. But one thing I had to redo is add
Code: 
nvidia_load="YES"
to /boot/defaults/loader.conf
Code: 
24.2.3. Major and Minor Version Upgrades

Upgrades from one minor version of FreeBSD to another, like from FreeBSD 9.0 to FreeBSD 9.1,
are called minor version upgrades. Generally, installed applications will continue to work
without problems after minor version upgrades.
 
youngunix said:
There is no need to rebuild world if you are upgrading from 9.1-RELEASE to 9.2-RELEASE. Or am I miss understanding what you're trying to do?

Anyway, follow these steps if you want to upgrade to 9.2-RELEASE.
Reference: Chapter 24. Updating and Upgrading FreeBSD
Click to expand...

You can't update source without buildworld, that is step one. I think it's in that link you posted to the handbook, or at least it used to be in that section; now it is geared towards binary updates.

I am not doing a binary update, I don't want to do a binary update. I want to do a source update like I've been doing since release 5.4. A broken release has happened before, I just don't know how to rule it out on my system, versus errata shortly coming.

I'd like help to resolve, and potentially solve the issue with make clean working but leaving immutable files behind in /usr/obj.

as far as updating ports, i ever really had, but a long running system 386 system had lots of old libraries on it, and I could see where that could pose weird problems. since switching to amd64 i always do delete-old target, or whatever it is, I always check the makefile. I've thought about it this time, as I want to switch to pkgng, and my portconf.conf file needs to be updated for the new format, with ports changing and not always adding a note to updating.
 
youngunix said:
Yesterday, I used those commands I posted and didn't do any "build world", it is running just fine.
Click to expand...
Not a smart thing to do. For starters you're now missing out on several things amongst which auditdistd, extra options in hastctl, a changed install but worse yet: some new features in mergemaster. From /usr/src/UPDATING:

Code: 
20130430:
        The mergemaster command now uses the default MAKEOBJDIRPREFIX
        rather than creating it's own in the temporary directory in
        order allow access to bootstrapped versions of tools such as
        install and mtree.  When upgrading from version of FreeBSD where
        the install command does not support -l, you will need to
        install a new mergemaster command if mergemaster -p is required.
        This can be accomplished with the command (cd src/usr.sbin/mergemaster
        && make install).
Bottom line; mergemaster changed. And if the developers count on this change to be present when you're doing a future update you may run into huge problems.

Code: 
root@smtp2:/usr/sbin # grep -m2 FreeBSD mergemaster && ./mergemaster -h | grep version
# dougb@FreeBSD.org
# $FreeBSD: release/9.1.0/usr.sbin/mergemaster/mergemaster.sh 228169 2011-12-01 05:51:17Z dougb $
mergemaster version [FILE]228169[/FILE]

Against:

Code: 
root@backup:/usr/sbin #grep -m2 FreeBSD mergemaster && ./mergemaster -h | grep version
# $FreeBSD: releng/9.2/usr.sbin/mergemaster/mergemaster.sh 250583 2013-05-13 01:20:31Z eadler $
  VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4`
mergemaster version [FILE]250583[/FILE]

Not updating the world is a very bad idea in this case. It may run, the question however is for how long. Sorry if I'm a little overly dramatic, but with these changes I honestly think you're playing with fire.
 
youngunix said:
But one thing I had to redo is add
Code: 
nvidia_load="YES"
to /boot/defaults/loader.conf
Click to expand...
Never, ever, modify /boot/defaults/loader.conf! Put that line in /boot/loader.conf where it belongs.
 
wblock@ said:
That chapter of the Handbook has instructions for both source and binary upgrade. The source upgrade is shown here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html. My shorter version is here: Building FreeBSD World And Kernel: The Short Form.

For a full world or kernel build, make clean is a waste of time. Just delete /usr/obj.
Click to expand...

Clean should eradicate the build, but not sure if this is symptomatic of a bigger misconfiguration on my system, or status quo. never had this issue on previous releases outside of 9, least not with 386, just switched to amd64 from 8 system updated and finally deployed when 9.0 launched.

Knowing /usr/obj should be deleted and knowing how to clear the immutable flags to do that to make the build continue is not very noobie friendly. But an off topic digression.

I followed the attached process to no avail. It presumes errors are not going to happen, which is usually the case.

I'm not going to discount something being tweaked on this end, but I don't know where to look. I have a another checkout of 9.2, which seems to match revision from SVN, so looking into the Makefiles, but it's not something I am adept at.
 
You must log in or register to reply here.
Back
Top