Source upgrade from 5.5 to 6.X not safe?

Robert Watson rwatson at
Sun Nov 4 12:06:20 PST 2007

On Fri, 2 Nov 2007, [LoN]Kamikaze wrote:

>> Well, in this case after running 'make installkernel' and rebooting, the 
>> system did not come back up because it got kernel fatals on reboot (fatal 
>> trap 12: page fault while in kernel mode).  It appears that my filesystems 
>> got marked dirty in the reboot loop that ensued, and I had to manually fsck 
>> them.  I figured after that it might boot, but alas problems remained, so 
>> after grabbing a disc1 image of 6.2 on CDROM I moved kernel.old back and 
>> kernel to kernel.bad.
>> Now, sometimes I work fast and loose with the rules of upgrading, but I was 
>> surprised that I managed to royally screw up things.  Any pointers would be 
>> appreciated before I shave off a few years of my life again.
> I think you might have no choice but to omit the reboots, because the world 
> contains lots of stuff that has to do with the kernel (like mounting).
> So just go into single user mode and do the usual stuff:
> # make installkernel
> # mergemaster -p
> # make installworld
> # mergemaster
> # shutdown -r now
> and pray to your deity of choice.
> If the reason for your problem is something else however you're stuck with a 
> system that can not run with your old kernel. So better backup before you 
> try.

In general, new kernels can reliably run old user spaces, but not new user 
spaces on old kernels.  This is because new user spaces often grow 
dependencies on new system calls, etc, that have appeared in the kernel, and a 
system call being missing can lead to rather extreme unhappiness if, say, it's 
in libc :-).

When I upgrade a remote systems, I'll actually almost always run a few days 
with the new kernel and the old user space to make sure everything has settled 
nicely before doing the user space upgrade, which is harder to revert. 
Reverting to an old kernel is easy, and leaving the door open is likewise easy 
-- as long as you don't installworld.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-stable mailing list