Corrupted OS

[Drew Jenkins]

2Kevin Kinsey <kdk at daleco.biz> 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.