kernel panic at boot on any 6.x OS

[Ted Mittelstaedt]

----- Original Message ----- 
From: "Joe Auty" <joe at netmusician.org>
To: "Ted Mittelstaedt" <tedm at toybox.placo.com>
Cc: "Daan Vreeken [PA4DAN]" <Danovitsch at vitsch.net>; "Kip Macy"
<kip.macy at gmail.com>; <freebsd-questions at freebsd.org>;
<freebsd-hackers at freebsd.org>
Sent: Monday, February 26, 2007 10:01 AM
Subject: Re: kernel panic at boot on any 6.x OS


>
> On Feb 26, 2007, at 8:01 AM, Ted Mittelstaedt wrote:
>
> >
> > ----- Original Message -----
> > From: "Joe Auty" <joe at netmusician.org>
> > To: "Ted Mittelstaedt" <tedm at toybox.placo.com>
> > Cc: "Daan Vreeken [PA4DAN]" <Danovitsch at vitsch.net>; "Kip Macy"
> > <kip.macy at gmail.com>; <freebsd-questions at freebsd.org>;
> > <freebsd-hackers at freebsd.org>
> > Sent: Sunday, February 25, 2007 10:39 PM
> > Subject: Re: kernel panic at boot on any 6.x OS
> >
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >> On Feb 25, 2007, at 7:56 PM, Ted Mittelstaedt wrote:
> >>
> >>>
> >>> ----- Original Message -----
> >>> From: "Joe Auty" <joe at netmusician.org>
> >>> To: "Daan Vreeken [PA4DAN]" <Danovitsch at vitsch.net>
> >>> Cc: "Kip Macy" <kip.macy at gmail.com>; <freebsd-
> >>> questions at freebsd.org>;
> >>> <freebsd-hackers at freebsd.org>
> >>> Sent: Sunday, February 25, 2007 8:14 AM
> >>> Subject: Re: kernel panic at boot on any 6.x OS
> >>>
> >>>
> >>>>
> >>>> Any idea how this could have happened after disabling everything in
> >>>> my /etc/loader.conf, and simply running a:
> >>>>
> >>>> make buildworld
> >>>> make buildkernel KERNCONF=myconfig
> >>>> make installkernel KERNCONF=myconfig
> >>>>
> >>>
> >>> well your supposed to do this single-user, run mergemaster and a
> >>> few other
> >>> things.
> >>> I also don't see a make installworld.
> >>>
> >>
> >> I usually perform those steps after I've rebooted to ensure that my
> >> system will boot off the new kernel, as per the instructions in the
> >> FreeBSD handbook.
> >>
> >>> Joe, please try booting from a 6.2-release install ISO.  If it
> >>> works without
> >>> panicing,
> >>> then you did something wrong during the upgrade.
> >>>
> >>
> >> Downloading the image now, I'll let you know if I'm able to boot from
> >> it...
> >>
> >>> Since by your own admission your not an expert, you would be well
> >>> advised
> >>> to simply back up your files the old fashioned way, reformat your
> >>> hard disk,
> >>> install from a 6.2 boot ISO, then restore your files.  Leave the
> >>> fancy
> >>> in-place
> >>> updating to someone else.  It's a big PIA and doesen't work half
> >>> the time
> >>> anyway.
> >>>
> >>
> >>
> >> How well does simply upgrading with the CD work (as opposed to wiping
> >> clean)? I've upgraded several times to new releases simply by
> >> rebuilding world, it has never failed me in the past. I don't doubt
> >> what you are saying here, but since I will have to change how I work,
> >> assuming that I can boot off of the 6.2 CD, I'd appreciate any
> >> general upgrade tips that don't involve wiping the disk clean (which
> >> is not really an option).
> >>
> >
> > If wiping the disk really isn't an option then you have one or more
> > of the
> > following
> > problems:
> >
> > 1) Production system with a lack of hardware spares
> >
> > 2) inadequate backup plan and execution.
> >
> > People who state that wiping the disk isn't an option are screaming
> > at the top of their lungs for the hardware gremlins to explain what
> > MTBF is
> > all about.
> >
> > The gremlins will visit you, I guarentee.  And they always pick the
> > very
> > best
> > times for it too.  I just hope (if this is your workplace) that
> > your job
> > survives.
> >
>
> My production system is backed up daily to two different sites,
> that's not an issue. The system I'm thinking of upgrading to 6.2 is
> my test server I run out of my house that stores movie files and
> other non-essential files. Technically, wiping it clean *would* be an
> option if it came down to it, just an inconvenience. Perhaps I should
> invest in another HD to use for instances such as this.
>
>
> >> 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)?
> >>
> >>
> >> I'll do my own homework regarding this too, but I appreciate any
> >> nuggets of wisdom you might have! As far as me being an expert, I
> >> guess I'd categorize me somewhere in between complete newb and
> >> FreeBSD developer =)
> >>
> >
> > The problem is that all of the ports and packages that you put on a
> > server
> > change from release to release.  The developers of openssl, for
> > example,
> > don't give a tinkers damn about how FreeBSD's upgrade process works,
> > when they are making changes in their code.
> >
> > 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.
> >
>
>
> Do you run any non-production machines where you test running newer
> OSes and test software updates and such?
>

We used to but the problem was that the manufacturers change hardware
designs much faster than we replace systems.  So you end up with every
server is running on different hardware.  It may all be from the same
manufacturer,
even have the same brand name and line name on it, but the guts are
different.

I've basically cut back to a single clone system that I use to create
custom-configured
install ISOs from and that is synced to the source tree when I need for it
to be.
But for everything else, we try whatever possible to avoid doing updates on
them
other than security until they have reached their end of service life.  When
I'm
building the replacement server for one we are retiring, that is when I do
all
my testing of updated applications.

Ted