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

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

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=00000000 00000000 len=00000000 0009fc00
SMAP type=01 base=00000000 0009fc00 len=00000000 00000400
SMAP type=02 base=00000000 000f0000 len=00000000 00010000
SMAP type=02 base=00000000 fec00000 len=00000000 01400000
SMAP type=01 base=00000000 00100000 len=00000000 1fef0000
SMAP type=03 base=00000000 1fff3000 len=00000000 0000d000
SMAP type=04 base=00000000 1fff0000 len=00000000 00003000
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


# 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 -m 555   rmail /bin
install -o root -g wheel -m 444 rmail.8.gz  /usr/share/man/man8
===> games
===> games/adventure
install -s -o root -g games -m 550   adventure /usr/games/hide
(cd /usr/games; ln -fs dm adventure;  chown -h root:games adventure)
chown: games: illegal group name
*** Error code 1

Stop in /usr/src/games/adventure.
*** Error code 1

Stop in /usr/src/games.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
# grep games /etc/group* /usr/src/etc/group*
grep: Memory exhausted
# swapon -a
swapon: adding /dev/ad0s4b as swap device
# grep games /etc/group* /usr/src/etc/group*
grep: Memory exhausted
# sync
# sync
# 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]

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.

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 the
discipline of systems administration and Microsoft, since they have
nothing in common.

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

Reply via email to