Date: Wed, 17 Oct 2001 11:27:35 -0400 From: Bill Moran <wmoran@iowna.com> To: Christopher Schulte <christopher@schulte.org>, "Nuno Teixeira" <nuno.mailinglists@pt-quorum.com>, <freebsd-questions@freebsd.org> Subject: Re: Major upgrade: 4.3R -> 4.4R - Any problem? Message-ID: <01101711273502.00327@proxy.the-i-pa.com> In-Reply-To: <5.1.0.14.0.20011017093645.03ca8e30@pop.schulte.org> References: <5.1.0.14.0.20011017093645.03ca8e30@pop.schulte.org>
next in thread | previous in thread | raw e-mail | index | archive | help
You forgot one very important step, which I've added below On Wednesday 17 October 2001 11:01, Christopher Schulte wrote: > At 11:30 AM 10/17/2001 +0100, Nuno Teixeira wrote: > >In my server I only use releases and I'm using 4.3R for now. I'd like to > >know if any of you have made a major upgrade directly from 4.3R to 4.4R in > >a multiuser enviorment, i.e., do all process (buildworld, buildkernel, > >installkernel, installworld and mergemaster) in multiuser mode and via > > SSH. <SNIP> > Offhand: > > Before you start, make sure kern.securelevel is set to a negative number: > > # sysctl -a | grep -i secu > kern.securelevel: -1 > > You don't want to get half way through the install and have some bits fail > because of file ACLs like schg. > > Now, log all users off. Kill all their processes. Kill off all processes > you possibly can (all services like web/ftp/pop/smtp/dns/etc, inetd, cron, > syslog, and even the listening sshd (your connection will not be lost as > long as you don't kill the process which your session is using)) before > doing the actual installworld and installkernel. Backup, and VERIFY your backup! > Check to make sure your network card will be supported by your new kernel, > with the config unchanged. > > Read /usr/src/UPDATING > > Read /usr/src/UPDATING again. > > Cross your fingers. :p > > I've upgraded boxes remotely like this many times with no problems. You > should have a backup plan in case it fails. Telephone call to the NOC your > box is in, ability to drive to the location if possible, or whatever is > within reason. I recently did an upgrade and botched the order of the upgrade and ended up with a vinum kernel module that wasn't in sync with the vinum userland, or _something_ messed up with vinum ... it simply couldn't mount the volumes. Overall result, a system with only the / partition available - obviously a bad thing. It was my fault, obviously hadn't had enough coffee yet, but luckily I had a backup of everything that I could restore from. Unfortunatley, 48G of data took about 2 hours to restore ... bleah. I guess step one should be "make sure you've had enough coffee before starting" I would also notify users that "the system will be undergoing maintenance during the hours of x:xx to x:xx and some services may be temporarily unavailable." -- Bill Moran Potential Technology technical services (412) 793-4257 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01101711273502.00327>