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

Re: Etch status..?



Hi Cga,

I've put my comments inline to make things clearer (I hope).

On Sun, Nov 26, 2006 at 02:39:38PM -0500, cga2000 wrote:
> On Fri, Nov 24, 2006 at 12:10:25AM EST, Douglas Tutty wrote:
> > On Thu, Nov 23, 2006 at 10:15:01PM -0500, cga2000 wrote:
> > > So it looks like I'm stuck with a 2.4 kernel for the lifetime of this
> > > laptop.
> As you implied I took it one step at a time, making sure I still had
> connectivity after each one of them:
> 
> 1. Did a minimal Sarge install
> 2. Installed the 2.6.8 kernel alongside the "native" 2.4.27
> 3. Upgraded to testing/etch via a dist-upgrade
> 4. Installed the etch 2.6.17 kernel alongside his two brothers 
> 
> Everything went well until I tried to boot the 2.6.17 kernel.

Do I read this right?:  You're OK running Etch with kernel 2.6.8 and the
problem is booting to 2.6.17?

Also, please confirm that you are using aptitude.  When having troubles
you can (I always do anyway) use the interactive UI.  Aptitude is the
smartest package manager and is the Debian recommended one.

> 
> Null pointer or something and dies with a kernel oops.
> 
Hopefully some who know about kernel oops can answer that one.  I'm
assuming its a module problem related to hotplug fighting with udev.

> Can a 2.6.17 kernel and the older 2.4.27 & 2.6.8 share the same
> partitions -- /etc/init.d startup scripts & config files, eg. ??
> 

Yes.  The init.d scripts themselves are kernel-independant.

> Only thing that looked a bit suspicious along the way is that when I did
> an apt-get install of this more recent kernel .. when apt does his
> "setup" bit right at the end.. well .. there was this very visible
> message like with 2-3 lines of asterisks before and after the message ..
> asking me to remove/purge the hotplug package .. or rather the hotplug
> stuff in /etc/init.d ... IIRC.
> 

The problem is that Etch's kernels need to use udev which is
incompatible with hotplug.  

> So I did a dpkg -l hotplug and it turned out to be in "rc" status -- "r"
> as in "removed" but "c" as in "configuration files are still in there"
> (and scripts probably) .. that is how I read it.
> 
> Now for one one thing I have no clue how I should go about removing that
> stuff .. do I do a "dpkg -L hotplug" and delete/rename the files .. 
> 
> And another thing ... isn't that likely to break the boot process for
> the older kernels..?
> 

Does your existing set __need__ to use hotplug?  I could never get it to
work and since I didn't have anything I was hotplugging anyway, I didn't
use it.  I figured out which kernel modules were needed (read the
kernel-xx doc package) and used modconf to get things set up correctly.
Etch with udev does this all on the fly, but without udev it doesn't
fly.

I had similar problems when I was going from 2.2.* to 2.4; I wanted to
take time to get 2.4 working right but then I'd have to get some real
work done and needed a functioning system and want to boot 2.2

The problem as noted in the Etch release notes is that the module names
and sometimes parameters change when going from one kernel major to
another.  This means, for example, that /etc/modules could be invalid
for one of them.

Assuming that you're now running Etch, to remove hotplug, since you know
the name of the one package, use dpkg directly: dpkg -P hotplug
and see what that gives.  

> Not sure I understand this separation of "kernel upgrade" vs.
> distribution upgrade would work ..
> 

Kernel versions are brought forward into new releases for just this
reason.  You can run an up-to-date release with an older kernel.  I
think that they continue to get security updates for about two years
which means that you have two years to work on this.  

> 
> Do they get written anywhere where I could retrieve them after the fact?

Kernel messages should go to /var/log/syslog among others.  If you find
that they are __only__ showing up on the screen (console), you could use
a console= kernel command line and send console messages to the serial
port as well as the screen and capture that with another computer.

> 
> Funnily enough, while it's nice to have vim 7.0 and some other more
> contemporary stuff in user space .. 2.6.8 doesn't do me any good at all

My 486 is faster on 2.6 than it was on 2.2 or 2.4.  I think its a
smarter scheduler or something.

> 
> .. I need 2.6.13+ ..
> 
> In any case it's pretty clear now that this had nothing to do with my
> hardware not being supported .. wouldn't be one bit surprised if other
> PC card NICs were affected in the same manner .. all of them possibly .. 
> 
> Among the many things I tried was playing with a number of live CD's and
> I found that the morphix-based ELive with a 2.6.11 kernel recognized and
> configured my NIC correctly and obtained a DHCP lease w/o a problem.
> 

They probably do not have hotplug and do use udev.
 

To summarize:

Confirm that you are now running Etch with a 2.4 kernel and all is well,
that its booting the 2.6 that is the problem.

If you can put the modules you need (as determined for now by hotplug)
in /etc/modules then you can try removing hotplug with dpkg -P hotplug.

Once hotplug is out of the way, you can install udev.

Once udev is installed you can try booting the 2.6 kernel.

Note that the module names in /etc/modules from the 2.4 kernel will at
least cause some error messages when the 2.6 kernel tries to load them.
At worst I suppose they could cause a kernel oops.

If those modules are not required for actually getting a command line under
2.4, you could mv modules modules.2.4 the reboot to 2.6
and cp modules.2.4 modules then reboot 2.4
	I know this isn't a long term solution but its at least a
	work-around while you troubleshoot.  This is what I did when I
	went 2.2 to 2.4.

I hate kernel upgrades.


Another suggestion:

If you make an installation media (CD, usb stick), what happens when you
boot this?  Is all your hardware recognized?

There may be features of the Etch installer that you would like to take
advantage of which __may__ suggest that you want to reinstall Etch when
it is stable.  For example, I will see if the installer will run on my
486 so I can use raid1 on my old IDE drives and put LVM over that, just
like I do on my new box.

Hang in there.

Doug.



Reply to: