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 
> call?).  

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, 
> though.

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 
have, right?

> 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 
following?
make clean;make cleanworld
make buildkernel KERNCONF=LOCAL 
make installkernel KERNCONF=LOCAL 
make installworld

...and I don't need this either, since I'm not doing mergmaster at all, right?

mergemaster
TIA,
Drew

 
---------------------------------
Don't be flakey. Get Yahoo! Mail for Mobile and 
always stay connected to friends.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to