Re: Weirdness trying -STABLE - -CURRENT

2002-08-15 Thread Peter Hessler

On Wed, 14 Aug 2002 21:31:35 -0700 (PDT) Nate Lawson wrote:

:I upgraded a machine from 4.6R to -CURRENT today and had similar
:problems.  Comments below.
:

I upgraded from 4.5R to -CURRENT last night, and had /no/ issues.


:On Wed, 14 Aug 2002, David Wolfskill wrote:
:  To upgrade from 4.x-stable to current
:  -
:  make buildworld
:  make buildkernel KERNCONF=YOUR_KERNEL_HERE
:  cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
:  make installkernel KERNCONF=YOUR_KERNEL_HERE
: 
: No problem up to here.
:
:Same.
: 
Ditto

:  reboot in single user [3]
: 
: OK; here we have a fundamental problem, illustrated by the following
: commands I issued just after the make installkernel:
: 
: freebeast(4.6-S)[3] grep '^kernel' /boot/defaults/loader.conf
: kernel=/kernel
: kernel_options=
: freebeast(4.6-S)[4]
: 
: The clue that I had was reviewing the transcript, and when I did the
: single-user boot, the system identified itself as 4.6-STABLE.
:
:This happened to me too.  Perhaps the instructions should say to unload
:kernel; load /boot/kernel/kernel on reboot or maybe explicitly copy in the
:new /boot/defaults/loader.conf like you do with device.hints?
:

unload kernel; load /boot/kernel/kernel; boot -s brought up 5-CURRENT.

/snip errors that I didn't get and problems I didn't experiance/
fsck -p
mount -u /
mount -a
cd /usr/src
make installworld #Note the lack of option '-k'
mergemaster

Everything went perfect (well, except my hands hurting from pressing 'i'
and [enter] about 7 bajillion times. ;-)

So possibly, the only thing that needs to be added to UPDATING is 
the recommendation to do the unload/load dance?


-- 
Peter Hessler [[EMAIL PROTECTED]]
[http://www.theapt.org]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-14 Thread David Wolfskill

Warning:  this is ~200 lines long.  Sorry.  I think the issue raised
is worth maybe 10% of the bandwidth, but

Date: Tue, 13 Aug 2002 18:33:33 +0200
From: Szilveszter Adam [EMAIL PROTECTED]

Thanks for getting back with the results. This points to the fatc that
the instructions in UPDATING should updated.

OK; folks -- after getting a great deal of encouragement from
Szilveszter Adam, I reviewed the transcripts from what I did a
little more carefully, and I believe that there is at least one
fundamental flaw in the present (as of rev. 1.214) /usr/src/UPDATING
instructions for the To upgrade from 4.x-stable to current section,
such that it cannot work as specified.

Further, I do not have a mechanism that I believe to exhibit
sufficiently predictable behavior as to be usable at this time.  (In
other words, it seems to me that making this transition may well require
something that -- for lack of a better term -- I will call luck.)

I will intersperse editorial comments in among the lines from UPDATING
(which are indented by a tab):

To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE

No problem up to here.

reboot in single user [3]

OK; here we have a fundamental problem, illustrated by the following
commands I issued just after the make installkernel:

freebeast(4.6-S)[3] grep '^kernel' /boot/defaults/loader.conf
kernel=/kernel
kernel_options=
freebeast(4.6-S)[4]

The clue that I had was reviewing the transcript, and when I did the
single-user boot, the system identified itself as 4.6-STABLE.

Now, if it is *intended* to actually boot -STABLE at this time, fine --
but that sure isn't the rationale that I've seen discussed.

In an effort, then, to find an appropriate circumvention, I tried:

freebeast(4.6-S)[4] pushd sys
freebeast(4.6-S)[5] make install
...

and after that:

freebeast(4.6-S)[6] !grep
grep '^kernel' /boot/defaults/loader.conf
kernel=kernel # /boot sub-directory containing kernel and modules
kernel_options=
freebeast(4.6-S)[7] 

and *then* I tried the single-user reboot.

I was mildly gratified to see:

Hit [Enter] to boot immediately, or any other key for command prompt.

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -s
/boot/kernel/acpi.ko text=0x2e27c data=0x1804+0x6e0 syms=[0x4+0x50b0+0x4+0x6913/
SMAP type=01 base=  len= 0009fc00
SMAP type=01 base= 0009fc00 len= 0400
SMAP type=02 base= 000f len= 0001
SMAP type=02 base= fec0 len= 0140
SMAP type=01 base= 0010 len= 1fef
SMAP type=03 base= 1fff3000 len= d000
SMAP type=04 base= 1fff len= 3000
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed Aug 14 19:15:38 PDT 2002
[EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/FREEBEAST

and I (foolishly, in retrospect) thought that I'd have something simple to
suggest that would fix the problem.

First significant hint that the ride was going to be bumpy was:

# mount -u /
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
# mount
/dev/ad0s3a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
# 

This was repeated (quite a bit) with the mount -at ufs, but at least
the file systems got mounted.  (Whew!)  So we see:

# mount
/dev/ad0s3a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
/dev/ad0s3e on /usr (ufs, local, soft-updates)
/dev/ad0s4h on /common (ufs, local)
/dev/ad0s4g on /var (ufs, local)
# cd /usr/src
# date  adjkerntz -i  date
Wed Aug 14 12:39:10 PDT 2002
Wed Aug 14 12:39:10 PDT 2002
# echo The time is 7 hrs. off -- and I'm 7 hrs. west of GMT.
The time is 7 hrs. off -- and I'm 7 hrs. west of GMT.

Continuing with the instructions from UPDATING, we see:

mergemaster -p  [5]
make installworld

OK:

# mergemaster -p
...

Continuing, then:

# make installworld
make: no target to make.
/usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/share/mk  
CPUTYPE=i386 -V CPUTYPE returned non-zero status
mkdir -p /tmp/install.oA6Pxyei
...

and things progressed for a while.  But then:

/usr/share/nls/it_IT.ISO8859-15/tcsh.cat - ../it_IT.ISO8859-1/tcsh.cat
/usr/share/nls/es_ES.ISO8859-15/tcsh.cat - ../es_ES.ISO8859-1/tcsh.cat
=== bin/rmail
install -s -o root -g wheel 

Re: Weirdness trying -STABLE - -CURRENT

2002-08-14 Thread Nate Lawson

I upgraded a machine from 4.6R to -CURRENT today and had similar
problems.  Comments below.

On Wed, 14 Aug 2002, David Wolfskill wrote:
   To upgrade from 4.x-stable to current
   -
   make buildworld
   make buildkernel KERNCONF=YOUR_KERNEL_HERE
   cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
   make installkernel KERNCONF=YOUR_KERNEL_HERE
 
 No problem up to here.

Same.
 
   reboot in single user [3]
 
 OK; here we have a fundamental problem, illustrated by the following
 commands I issued just after the make installkernel:
 
 freebeast(4.6-S)[3] grep '^kernel' /boot/defaults/loader.conf
 kernel=/kernel
 kernel_options=
 freebeast(4.6-S)[4]
 
 The clue that I had was reviewing the transcript, and when I did the
 single-user boot, the system identified itself as 4.6-STABLE.

This happened to me too.  Perhaps the instructions should say to unload
kernel; load /boot/kernel/kernel on reboot or maybe explicitly copy in the
new /boot/defaults/loader.conf like you do with device.hints?

I didn't notice the 4.6 dmesg while booting so I went through the make
installworld using the 4.6 kernel.  It got to chpass and then failed with
a sig 11.  It turned out part of the chpass install uses chflags and I
believe the syscall changed between 4.6R and current.

I rebooted at that point since things couldn't continue in the
installworld and the new kernel's ACPI blew major chunks (endless loop).  
So I booted my stable partition, did another buildkernel/installkernel on
the -current partition and then rebooted.  ACPI paniced but I was able to
boot the new kernel by disabling ACPI (separate message on this).

After booting the -current kernel, mergemaster and installworld worked
just fine.  My system was running fine when I went home tonight.

 # sync
 # which grep
 Out of memory!
 pid 3263 (perl), uid 0: exited on signal 11 (core dumped)
 [1]   3263 Segmentation fault (core dumped) which grep
 # reboot
 
 I was able to perform another single-user reboot, but successive attempts
 to make installworld died with the out of memory symptom.
 
   mergemaster [4]
   [1]
   reboot
 
 I wasn't able to get as far as completing the make installworld -- I tried
 with -k once; that didn't seem to help, either.
 
 
 So -- at some point I think this needs to be figured out.
 
 I'll be happy to poke around and test.

I didn't get any out of memory errors, just repeatable sig 11 when running
chflags.

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-13 Thread Szilveszter Adam

Hello David,

Thanks for getting back with the results. This points to the fatc that
the instructions in UPDATING should updated.

The method is almost what you did, only a tad more efficient:

- make buildworld 
- make buildkernel KERNCONF=you_know_what
- cp GENERIC.hints to device.hints or create your own if you need
  (because you have ISA devices eg)
- make installkernel KERNCONF=you_know_what
- reboot in single user (do the bootblocks if needed)
(At this point you are running on the -CURRENT kernel but with the old
userland: be aware of this because things like ipfw will now stop
working until you are back in sync!)
- mergemaster -p
- make -k installworld (this will install as much of the new userland as
  possible, but will proceed in spite of errors.)
- rm -rf /usr/include/*
- make installworld (this now should go through without problems, you
  are now back in sync, your /usr/include is also repopulated with the
  new headers)
- mergemaster (with the new mergemaster script)
- reboot for the changes to take effect.

Done.

Hope this helps.
-- 
Regards:

Szilveszter ADAM
Szombathely Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-13 Thread Szilveszter Adam

On Tue, Aug 13, 2002 at 01:43:44PM -0600, Kyle Butt wrote:
 Szilveszter Adam wrote:
 (At this point you are running on the -CURRENT kernel but with the old
 userland: be aware of this because things like ipfw will now stop
 working until you are back in sync!)
 
 The trick here is that a new loader isn't installed yet. the old kernel
 lives in /kernel and the new one in /boot/kernel/kernel you have to be
 sure and boot the new one. make -k installworld accomplishes the same
 thing (By installing a new loader)

I was not merely thinking of this. For ipfw to work, the kernel and the
/sbin/ipfw binary have to match, or else adding or otherwise
manipulating rules will likely fail. This will either result in a
wide-open firewall or a tightly closed one, depending on the kernel
config. This happens even when the ipfw support is not loaded from a
module.

-- 
Regards:

Szilveszter ADAM
Szombathely Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-13 Thread Kyle Butt

Szilveszter Adam wrote:

Hello David,

Thanks for getting back with the results. This points to the fatc that
the instructions in UPDATING should updated.

The method is almost what you did, only a tad more efficient:

- make buildworld 
- make buildkernel KERNCONF=you_know_what
- cp GENERIC.hints to device.hints or create your own if you need
  (because you have ISA devices eg)
- make installkernel KERNCONF=you_know_what
- reboot in single user (do the bootblocks if needed)
(At this point you are running on the -CURRENT kernel but with the old
userland: be aware of this because things like ipfw will now stop
working until you are back in sync!)

The trick here is that a new loader isn't installed yet. the old kernel
lives in /kernel and the new one in /boot/kernel/kernel you have to be
sure and boot the new one. make -k installworld accomplishes the same
thing (By installing a new loader)

- mergemaster -p
- make -k installworld (this will install as much of the new userland as
  possible, but will proceed in spite of errors.)
- rm -rf /usr/include/*
- make installworld (this now should go through without problems, you
  are now back in sync, your /usr/include is also repopulated with the
  new headers)
- mergemaster (with the new mergemaster script)
- reboot for the changes to take effect.

Done.

Hope this helps.
  





To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-12 Thread David O'Brien

On Sun, Aug 11, 2002 at 09:41:19PM +0200, Szilveszter Adam wrote:
 This is known problem, straight updates by simply make world do not
 work from -STABLE. Therefore, one has to very carefully follow the
 procedure described in the UPDATING file even though normally not so
 many steps would be needed.

Uh... did you actually READ all that text you snipped out?  David *DID*
follow the correct steps -- please go back and read what he did:

cvs up
make buildworld
make buildkernel
create /boot/device.hints
make install kernel
*** reboot 
make install world.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-12 Thread Szilveszter Adam

On Mon, Aug 12, 2002 at 12:41:19PM -0700, David O'Brien wrote:
 On Sun, Aug 11, 2002 at 09:41:19PM +0200, Szilveszter Adam wrote:
  This is known problem, straight updates by simply make world do not
  work from -STABLE. Therefore, one has to very carefully follow the
  procedure described in the UPDATING file even though normally not so
  many steps would be needed.
 
 Uh... did you actually READ all that text you snipped out?  David *DID*
 follow the correct steps -- please go back and read what he did:

Did you actually read my second message in this thread? It was sent only
a short time after the first one. (and no need to shout I am sitting
close to the monitor  keys) Since David has not yet gotten back to us I
have no more ideas since that second posting.

-- 
Regards:

Szilveszter ADAM
Szombathely Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-12 Thread David Wolfskill

Date: Sun, 11 Aug 2002 21:41:19 +0200
From: Szilveszter Adam [EMAIL PROTECTED]

First off, sorry for the lot of snippage but this mail was really
long...

Yeah, it was; sorry.  That's what I get for trying to be complete.  :-)

I was able to re-do the steps, and evtually get to a point:

freebeast(5.0-C)[1] df
Filesystem  1K-blocks UsedAvail Capacity  Mounted on
/dev/ad0s3a158767636208244644%/
devfs   110   100%/dev
/dev/ad0s3e   1873113   70  101326541%/usr
/dev/ad0s4h  27728233 11141233 1436874244%/common
/dev/ad0s4g   2032839   487508  138270426%/var
procfs  440   100%/proc
freebeast(5.0-C)[2] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Aug 12 
15:34:30 PDT 2002 
[EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/FREEBEAST  i386
freebeast(5.0-C)[3] 

which I consider success.  (Well, assuming I can use the resulting
system to rebuild itself, anyway.)


In this last attempt, I still got shell dying a rather un-graceful
death, probably (still) as a result of a SIGSYS.  The key difference
this time was that after this happened, I hit RESET on the machine, and
when it started to come up, I interrupted the process to boot
single-user mode, and inserted some extra steps (in pseudo-unidiff
format relative to present contents of the relevant section of UPDATING):

To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot in single user [3]
mergemaster -p  [5]
make installworld
+   hit RESET
+   reboot in single user [6]
+   make installworld
mergemaster [4]
[1]
reboot
...
+
+   [6] From the bootblocks, boot -s, and then do
+   fsck -p
+   reboot in single user [3]


I do not claim that this is optimal, or that the result will actually be
solid enough to survive a make buildworld, but it seems to me that the
instructions in UPDATING for the upgrade from 4.x-stable to current
case are not adequate in and of themselves as they presently stand (at
least in soome cases, mine among them), so I offer the above as a
possible modification that might help some folks.

I will save my logs (typescripts, really) of what I did for a few days,
in case anyone would care to review them.  Note that this amounts to
about 10 MB of data, before you ask to get a copy.

Thanks,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
To paraphrase David Hilbert, there can be no conflicts between Microsoft
and the discipline of systems administration, since they have nothing in
common.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-11 Thread Szilveszter Adam

Hello David,

First off, sorry for the lot of snippage but this mail was really
long...

On Sun, Aug 11, 2002 at 11:37:06AM -0700, David Wolfskill wrote:
...
 OK; I brought it back up under today's -STABLE, and looking at the typescript
 file, I see that it ends thusly:
...
 === usr.bin/checknr
 install -s -o root -g wheel -m 555   checknr /usr/bin
 install -o root -g wheel -m 444 checknr.1.gz  /usr/share/man/man1
 === usr.bin/chflags
 install -s -o root -g wheel -m 555   chflags /bin
 install -o root -g wheel -m 444 chflags.1.gz  /usr/share/man/man1
 === usr.bin/chpass
 [ ! -e /usr/bin/chpass ] ||  chflags noschg /usr/bin/chpass || true
 *** Signal 12
...
 So I get the impression that folks who are complaining about the shell
 getting a SIGSYS probably aren't hallucinating (about that, anyway), and
 to the extent that there's a (non-recovered) mistake in the procedure I
 followed, perhaps the effected folks are doing something similar.

This is known problem, straight updates by simply make world do not
work from -STABLE. Therefore, one has to very carefully follow the
procedure described in the UPDATING file even though normally not so
many steps would be needed.

To get of this situatio, the person(s) affected should do a make -k
installworld now and then a make installworld again anf this way get
all the new userland installed.

Also, one should not use the -j when upgrading (as stated in UPDATING)

-- 
Regards:

Szilveszter ADAM
Szombathely Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Weirdness trying -STABLE - -CURRENT

2002-08-11 Thread Szilveszter Adam

It's me again...

On Sun, Aug 11, 2002 at 11:37:06AM -0700, David Wolfskill wrote:
 * reboot (single-user mode)
   Now, at this step, I see something a bit odd:
 
 Console: serial port
 BIOS drive A: is disk0
 BIOS drive C: is disk1
 BIOS 639kB/523200kB available memory
 
 FreeBSD/i386 bootstrap loader, Revision 1.1
 ([EMAIL PROTECTED], Sun Aug 11 09:29:25 PDT 2002)
 Loading /boot/defaults/loader.conf 
 Warning: syntax error on file /boot/device.hints
 machine i386
  ^
 Warning: syntax error on file /boot/loader.conf
  $
  ^
 /boot/kernel/kernel text=0x237e0c data=0x35db4+0x6f72c syms=[0x4+0x36820+0x4+0x421d1]

As for this part: Are you *really* sure that the files were what you
believed them to be? The first appears to me to be a kernel config file
instead of the device.hints. I have no idea about the second, it could
be any file with a $FreeBSD$ tag in it, which was not commented properly
or something.

BTW: I looked over the suggested order of steps in UPDATING just now, you
did things pretty much according to that (with the exception of the -j
for the buildworld but that one cannot be that dramatic, I assume you
did not use the -j for the installworld.

So, I still have no real explanation for your hanging of the machine.
Perhaps someone else. The first failure is memory corruption in any
event but the reason is not known to me. I have not seen it reported
here yet.

-- 
Regards:

Szilveszter ADAM
Szombathely Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message