kernel panic at boot on any 6.x OS

Mike Meyer mwm-keyword-freebsdquestions.8c5a2e at mired.org
Mon Feb 26 16:35:25 UTC 2007


In <001001c759a6$438d5ed0$3c01a8c0 at coolf89ea26645>, Ted Mittelstaedt <tedm at toybox.placo.com> 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.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


More information about the freebsd-questions mailing list