[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upgrade from 2.4 to 2.6: unknown symbols



On 2005-04-22, Paolo Alexis Falcone penned:
> On 4/21/05, Monique Y. Mudama <spam@bounceswoosh.org> wrote:
>> 
>> Not *that* different.  I was able to fix the unknown symbols by
>> making some stuff part of the kernel, instead of building them as
>> modules.  See my followup to my original post for details.
>> 
> I dunno about your configs - but as far as I know I have the same
> items you built in to the kernel as modules.

Quite possibly.  Since the only problems were with nfsd and vfat
support, one of which is started on boot and the other of which I use
pretty frequently, building them into the kernel seems reasonable
enough.  It's not something I'm going to worry about.

>> I don't know about you, but I've been refining my .config files for
>> years, and carting them from machine to machine.  Just giving them
>> up ... it wouldn't be right.
>
> The 2.6 kernel configuration introduces new configs and
> configuration dependencies - it's not just as simple as
> transplanting .config files made for 2.4 directly to 2.6 as there
> would always be hiccups doing that without manipulating the
> dependencies.

Well, I don't know what kinds of things you include under manipulating
dependencies, but like I said, it worked fine for me purely by running
`make menuconfig` and tweaking a few things.  I didn't have to touch
the source or the build scripts.

> I don't recall having been able to directly cart my kernel 2.2
> configs to 2.4, or 2.4 to 2.6 without encountering module warnings
> or even kernel panics. It was much easier to build from a clean
> slate, as from there it's much easier what modules/functionality
> needs and would activate.

In my case, I really do think that doing a `make oldconfig` and then
tweaking was the easiest option.  I don't have any "interesting"
hardware to support, and I keep my kernel pretty minimal (at least
compared to the default debian config), so maybe I just don't have
that many potential points of failure.

-- 
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html



Reply to: