18 messages in org.freebsd.freebsd-hackerskernel panic at boot on any 6.x OS| From | Sent On | Attachments |
|---|---|---|
| Joe Auty | Feb 25, 2007 7:55 am | |
| Kip Macy | Feb 25, 2007 7:59 am | |
| Daan Vreeken [PA4DAN] | Feb 25, 2007 11:03 am | |
| Joe Auty | Feb 25, 2007 4:15 pm | |
| Joe Auty | Feb 25, 2007 4:16 pm | |
| Joe Auty | Feb 25, 2007 4:17 pm | |
| Ted Mittelstaedt | Feb 26, 2007 5:35 am | |
| Joe Auty | Feb 26, 2007 6:40 am | |
| Ted Mittelstaedt | Feb 26, 2007 2:13 pm | |
| Mike Meyer | Feb 26, 2007 4:35 pm | |
| Joe Auty | Feb 26, 2007 6:01 pm | |
| Joe Auty | Feb 26, 2007 10:38 pm | |
| Kip Macy | Feb 27, 2007 2:51 am | |
| Peter Jeremy | Feb 27, 2007 4:33 am | |
| Joe Auty | Feb 27, 2007 4:45 am | |
| Joe Auty | Feb 27, 2007 6:28 am | |
| Ted Mittelstaedt | Feb 27, 2007 1:06 pm | |
| Ted Mittelstaedt | Feb 27, 2007 1:07 pm |
| Subject: | kernel panic at boot on any 6.x OS | |
|---|---|---|
| From: | Ted Mittelstaedt (te...@toybox.placo.com) | |
| Date: | Feb 27, 2007 1:07:09 pm | |
| List: | org.freebsd.freebsd-hackers | |
----- Original Message ----- From: "Joe Auty" <jo...@netmusician.org> To: "Ted Mittelstaedt" <te...@toybox.placo.com> Cc: "Daan Vreeken [PA4DAN]" <Dano...@vitsch.net>; "Kip Macy" <kip....@gmail.com>; <free...@freebsd.org>; <free...@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" <jo...@netmusician.org> To: "Ted Mittelstaedt" <te...@toybox.placo.com> Cc: "Daan Vreeken [PA4DAN]" <Dano...@vitsch.net>; "Kip Macy" <kip....@gmail.com>; <free...@freebsd.org>; <free...@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" <jo...@netmusician.org> To: "Daan Vreeken [PA4DAN]" <Dano...@vitsch.net> Cc: "Kip Macy" <kip....@gmail.com>; <freebsd- ques...@freebsd.org>; <free...@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