From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 26 16:35:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78ACE16A402 for ; Mon, 26 Feb 2007 16:35:24 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 25E6813C481 for ; Mon, 26 Feb 2007 16:35:23 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 37754 invoked by uid 1001); 26 Feb 2007 16:36:45 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 26 Feb 2007 11:36:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17891.3228.173538.908477@bhuda.mired.org> Date: Mon, 26 Feb 2007 11:36:44 -0500 To: "Ted Mittelstaedt" In-Reply-To: <001001c759a6$438d5ed0$3c01a8c0@coolf89ea26645> References: <6B2A41DC-79FA-42A1-B1BC-BB9F0A74B765@netmusician.org> <200702251146.08150.Danovitsch@vitsch.net> <228AFDCF-D9C1-43F1-ACBE-719595B10FEE@netmusician.org> <003b01c75940$fbc095f0$3c01a8c0@coolf89ea26645> <39E24107-964D-414C-95D1-5B1C376291E4@netmusician.org> <001001c759a6$438d5ed0$3c01a8c0@coolf89ea26645> X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Mike Meyer Cc: "Daan Vreeken \[PA4DAN\]" , Kip Macy , Joe Auty , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: kernel panic at boot on any 6.x OS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 16:35:24 -0000 In <001001c759a6$438d5ed0$3c01a8c0@coolf89ea26645>, Ted Mittelstaedt typed: > > For instance, is rebuilding world between point releases (e.g. 5.4 to > > 5.5) an okay idea, compared to across major releases (e.g. 5.5 to 6.2)? For the record, I do a rebuild between point releases - actually, I track -stable on those systems, but do the wipe & reinstall across major releases. > I run a number of FreeBSD servers and what I do is simply keep them patched > with security updates. Every once in a while a security hole will be > discovered in a non-core program and if it's serious enough I'll go into the > port > and do a "make deinstall" followed by downloading and compiling the program > the "old fashioned way" I shoot for a min of 3 years on the OS before even > thinking about updating, and when it's time to update the hardware has > generally reached the old rag stage anyway. This works great for servers, that don't have any real users on them, and is pretty much how I do things. I'll try updating the ports tree and installing from that rather than building the old fashioned way, because that works a surprising percentage of the time. On desktop and development systems, the users tend to get pissed if I let things get that old. So I do upgrade them more often. There are a couple of things you can do to make reinstalling to a clean disk a bit less painfull. 1) Intelligent file system layout. I put all the things that aren't installed from the FreeBSD disks on their own partitions (/home and /local). I can then wipe and reinstall /, /var and /usr without clobbering the non-system data. 2) Mirrored disks. Disks for consumer systems are cheap. Throwing a second one in a system and mirroring the system disk is a cheap way to improve the reliability of the system. When it's time to upgrade, take a drive out of the mirror, and install to that drive. You can reboot to the old system if you need to interrupt the process and run the old system for some reason. With a file system layout as per #1, you can even mount the users files under both versions of the OS. When you're happy with the new system, mirror the new system drive to the old one. Neither of these is an excuse for not backing up your data before you start the process. Given the above, the backups are for disaster recovery, so you don't need full level 0 dumps, just up-to-date incrementals. So if you're running daily backups, this should be easy: drop into single user, and run an incremental since the last daily, which typically takes me a few minutes. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.