Re: Etch status..?
On Mon, Nov 27, 2006 at 05:13:56PM -0500, cga2000 wrote:
> On Sun, Nov 26, 2006 at 05:36:39PM EST, Douglas Tutty wrote:
> > > 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?
>
> Yes,
>
> I now have three kernels installed on this etch system.
>
> 1. The original 2.4.27 that came with sarge
> 2. The 2.6.8 kernel that I installed before upgrading to etch
> 3. The 2.6.17 kernel that was installed from the linux-image deb.
>
> Both the 2.4.27 and 2.7.8 kernel boot without any problem.
>
> Both configure my pcmcia NIC and acquire an IP address from my ISP.
>
> The 2.6.17 kernel on the other hand dies almost immediately.
>
> > 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.
>
> I haven't yet quite figured out how to use the ncurses full-screen
> version of aptiude.
>
> I normally use apt-get or command-line aptitude.
Part of your difficulty could be using two different (apt-get and
aptitude) package managers. They each have different logic on
dependancies (aptitude is the new standard) and keep their information
in different places so they can't "compare notes".
You should figure out the aptitude full-screen. It really is quite
easy. Tell aptitude (via the options menu) to automatically fix
dependancies but not install recommends.
> Since I did an "aptitude install linux-image.2.6.17.3.." there would
> appear to be a bug here.. I'm still confused about the installer asking
> me to manually remove the hotplug package. If it must be done .. why
> doesn't _he_ (she?) do it..???
Its probably a pre/post script from the kernel package asking you to
remove hotplug, not aptitude itself. If prior to this you had set up
aptitude with what packages __you__ wanted installed vs what packages
were only there to satisfy dependancies (using M and m), then it would
have removed hotplug.
> > The problem is that Etch's kernels need to use udev which is
> > incompatible with hotplug.
>
> So apt is not doing his job.
Since aptitude didn't install hotplug it doesn't think that it was
automatically installed. It will only remove something automatically if
it was installed automatically. The problem may be that the new kernel
doesn't have hotplug as a 'conflict' or something.
> > > And another thing ... isn't that likely to break the boot process for
> > > the older kernels..?
Not if the required modules are loaded at boot time anyway.
> > >
> >
> > Does your existing set __need__ to use hotplug?
>
> I have no clue
>
Try this:
lsmod
You may even want to lsmod | lpr to have a hard copy.
This gives you a list of all modules currently loaded in a table:
Module Size Used By
Module is the name of the module
Size doen't matter :)
Used is important here
By is also.
Make a list of all module names where used is 0. These are candidates
for inclusion in /etc/modules.
For example, I have
ne 7492 0
8390 9856 1 ne
I have ne in my /etc/modules. Its for my NIC. When the ne module is
loaded, it depends on 8390 so it gets automatically loaded. I don't
need 8390 in my /etc/modules.
Some of the 'used 0' modules are automatically loaded by the kernel
anyway, e.g. ide_disk.
The modules that you need to load are for hardware that the kernel
doesn't need to know about to boot, e.g. NICs, mice, parports, lp, etc.
So with nothing in /etc/modules your computer should still boot (but
have a rescue boot [floppy, install CD, whatever] available for your
friend Justin Case.
Then dpkg -P hotplug to get rid of it.
Double check that the init.d scripts for hotplug are gone.
Reboot into the same kernel that works.
Use modconf to get the modules you need back. Modconf will put the
right lines in /etc/modules and /etc/modprobe.d
Use lsmod and compare with what it was before. When you're happy that
all your hardware works, then reboot and verify that all the modules you
need get loaded.
> Sounds to me like if you need to boot a wide array of kernels for
> testing purposes it would be nice to have separate /etc's for each of them.
The only things in /etc/ that are kernel specific are /etc/modules,
/etc/modprobe.d, and modules.conf (generated by update-modules from
modules and modprobe.d).
> > to remove hotplug, since you know
> > the name of the one package, use dpkg directly: dpkg -P hotplug
> > and see what that gives.
>
> It's marked "rc" in "dpkg -l hotplug"
dpkg -l justs lists the info about hotplug. You don't really care, you
want it out of there. -P purges hotplug (removes it and its config
files).
You should also make sure that you're not also using devfs which has
been replaced by udev.
>
> > > 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.
>
> That's okay ..
>
> I've already spent one year on this upgrade ..
>
Wow. No wonder I don't normally run testing. I only went with Etch for
the new hardware box that wasn't invented when Sarge was released.
> > > Do they get written anywhere where I could retrieve them after the fact?
> >
> > Kernel messages should go to /var/log/syslog among others.
>
> I'd have to boot it again to be 100% sure but I'm quite confident the
> oops occurs way before klogd/sylogd take off.
>
> > 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.
>
> Don't have one right now. I'll check if I can use the Prnt Scren key
> to at least get a hcopy.
>
Look at the Remote Serial Console HOWTO, chapter 5. You'll see that you
can have multiple consoles (one for each console technology). You can
use console=lp0 console=tty0 to send console messages both to your
screen and the lp0 port. Hook up a paralell printer (real one, not a
winprinter) and you should capture all your messages. The order of
console arguments is important: output goes to all, console input only
comes from the last one.
> I _am_ running etch and the 2.6.8 kernel works fine.
>
> The problem I am having is with the 2.6.17 kernel.
>
> > 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.
>
> I'll try that .. A bit annoying if it screws up my other kernels .. I
> have already begun customizing this install and would hate to start
> over.
Hopefully, having the output from lsomd should minimizs the impact on
other kernels. However, if you have 2.6.8 working, why worry about
earlier kernels?
>
> > Once hotplug is out of the way, you can install udev.
>
> I think you're wrong. udev is already installed and if I boot a kernel
> that's too old to support it I get some bootup messages to that effect.
Another reason to not use pre 2.6.8 kernels now that it works.
>
> > 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.
>
> ... hence my previous comment that there should be a
>
> /boot/etc/linux.release.version.minor
>
> directory for each kernerl.
>
Its not worth it. Normally kernel transition is just that, a day of
transition during which you can put up with (and potentially use) the
error messages.
> > 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.
>
> Like .. use a rescue disc to set up your system before you boot a
> different kernel..??
>
> Hey .. why not .. :-)
Yah. Better still: I have a 171 MB IDE drive which has a fully
uptodate (as of the last time the drive was in a box) text-based system
that can be used for system recovery. It includes mc, lynx, wget,
pppconfig, lpr, man, pinfo, the HOWTOs, debian-reference, etc. Its
great for such times as yours. And a 171 MB drive isn't much use for
anything else.
>
> > I hate kernel upgrades.
>
> No .. I think they're fun .. The problem is that seeing is believing ..
> and until I am able to boot a new kernel .. I am pretty much incapable
> of really learning anything about it.. Bit of a catch22 where I'm
> concerned.
If prior to intalling a kernel you have the kernel-docs package
installed, you can see all the kernal parameters and all the parameters
for all the modules.
>
> > Another suggestion:
> >
> > If you make an installation media (CD, usb stick), what happens when
> > you boot this? Is all your hardware recognized?
>
> I'd have to learn to do that. And right now apart from holidays I never
> have more than a couple hours at a stretch to work on this.
> >
> > 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.
> Looks like I'm pretty close to a solution now ..
Looks that way.
>
> Thanks much for help and encouragement.
>
> Thanks
You're welcome.
Doug.
Reply to: