Re: kernel panic at boot on any 6.x OS


----- Original Message -----
From: "Joe Auty" <joe@xxxxxxxxxxxxxxx>
To: "Ted Mittelstaedt" <tedm@xxxxxxxxxxxxxxxx>
Cc: "Daan Vreeken [PA4DAN]" <Danovitsch@xxxxxxxxxx>; "Kip Macy"
<kip.macy@xxxxxxxxx>; <freebsd-questions@xxxxxxxxxxx>;
<freebsd-hackers@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
To: "Ted Mittelstaedt" <tedm@xxxxxxxxxxxxxxxx>
Cc: "Daan Vreeken [PA4DAN]" <Danovitsch@xxxxxxxxxx>; "Kip Macy"
<kip.macy@xxxxxxxxx>; <freebsd-questions@xxxxxxxxxxx>;
<freebsd-hackers@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
To: "Daan Vreeken [PA4DAN]" <Danovitsch@xxxxxxxxxx>
Cc: "Kip Macy" <kip.macy@xxxxxxxxx>; <freebsd-
questions@xxxxxxxxxxx>;
<freebsd-hackers@xxxxxxxxxxx>
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

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages