2Kevin Kinsey <[EMAIL PROTECTED]> wrote:> > synch your source to 6.2
> > How? And is this necessary since it's already at 6.2?
> The command below, "cvsup -g -L 2 supfile". Assuming, of > course, that
> the supfile is valid. Is it necessary? Depends; if you're convinced
> that something is wrong with your current installation, then you might
> not need to, because you can rebuild exactly the system that you
> *should* have (for example, perhaps you fat-fingered a chmod or rm
Yes. The system was working fine. The problem is with an extra HD I have that I
told the server farm to check out thoroughly before installing it in the new
server because I knew it had a problem. They said they did....and didn't. So
that's what corrupted the system again...exactly the same way it did before,
too. But yes, the system was working fine before I had data files on the HD in
question linked to s/w on the SCSI hard drives.
> OTOH, if you are attempting to get "up to date" on security
> fixes, etc., then you should read up on "the Cutting Edge" so that you
> understand the CVS tags, and use cvsup as shown below.
Well, it never hurts to get up to date on security, does it? Where do I find
this cutting edge?
> Be *certain* you
> have the CVS tag you really want in the supfile before you press enter,
Will that be outlined in the cutting edge, or elsewhere?
> Now, if you think that the system is corrupt because your source tree is
> corrupt, then you would also want to sync your source tree. Of course,
> why would it be corrupt? If a committer made an error, you'd probably
> see some discussion of it on this list of the stable@ list.
The HD zapped two data files--MySQL and a Zope instance Data.fs--and that's
what caused the problem both times. I doubt this would have hurt the source
tree. Your thoughts?
> OK, that's fine. This next stuff is a tad strange, any reason you can't
> just "shutdown -r now"? The point is to attempt to boot with the new
> kernel, and going to single-user at this point doesn't do that.
I need to avoid single user mode, as you probably recognize, since the machine
is on the other side of the planet. The below worked when I upgraded once from
5.5 to 6.1.
> > sh /etc/rc.shutdown # kills all your services
> > pkill sendmail
> > pkill syslogd
> > mergemaster -p
> As noted above, this ("mergemaster -p") is actually meant to be done
> "pre-buildworld" ... see mergemaster(8).
In other words, it's not necessary since I'm just rebuilding what I already
> Thinking a tad more clearly, I suppose you mean, since the process of
> upgrading (buildworld, installworld, whatever) is attached to my
> terminal (which is an SSH session), what happens if I'm disconnected -
> will my upgrade continue?
No, what I mean is if my connection gets dropped.
> The answer is that it will not continue unless you've planned for that
> possibility. Are you familiar with job control, e.g.:
> $ make buildworld &
Ah! Good idea! So just use the old "&" symbol.
How do I know when it's finished? Putting jobs in the background, one can't see
their progress, that is, I don't know how to monitor it if it's not flashing
before my face ;) And that's the only place I have to put a job in the
background? Reviewing my notes again, that wouldn't be necessary for any of the
make clean;make cleanworld
make buildkernel KERNCONF=LOCAL
make installkernel KERNCONF=LOCAL
...and I don't need this either, since I'm not doing mergmaster at all, right?
Don't be flakey. Get Yahoo! Mail for Mobile and
always stay connected to friends.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"