New Kernel Install problem...

[AndreL]

Anyone has an idea why, when I try to install a kernel package from etch, it wants to remove all my other kernels so I have nothing to fall back to?

[Red_FoX]

mayabe theirs a problem with the previous kernel's? idk..im not good at linux

[Lavene]

Anyone has an idea why, when I try to install a kernel package from etch, it wants to remove all my other kernels so I have nothing to fall back to?

That sounds weird. What kernel package are you trying to install? Are you running Etch? Can you post the output?

Tina

[danieldk]

Does it try to install a newer udev or some other package as a dependency of the new kernel? New udev versions don't work well with other kernels, so a new or some other package may conflict with older kernels. Maybe you could paste the the output of the "apt-get install" operation up till the point it asks for confirmation.

[AndreL]

The problem seems deeper: Anything I try to install from etch wants to remove all the kernels, even OoO... I must have messed up something in the last re-installation. I might have to redo this.

[jjmac]

Howdy,

The problem seems deeper: Anything I try to install from etch wants to remove all the kernels, even OoO... I must have messed up something in the last re-installation. I might have to redo this.

It sounds like a cascading dependency thing going through a number of packages. A pain in the butt i know, but thats to be expected in a tight versioned system like deb. And i wouldn't have it any other way. Except for times when this crops up, that is :).

When a similar thing has happened to me, involving a package that wants to either update around 20 or so other packages and remove 6 or so ... it has been a cascading 'dependency' conflict. It will likely all hinge on possibly one package that is going to be removed, but all the others depend on it, so , off they go too. For removal or upgrade :)

You could try ...

# putting those other packages on "hold"
# backing up the boot directory
# making 'dpkg-repack' backups of those packages
# making 'equivs' for those packages

The first is very straight forward ...

The second, i'm thinking of just let it uninstall the kernels, copy the new one over to the back up, then deleting /boot and renaming the back up to /boot. A bit raw i know. Probably best to have 'equivs' for the particular packages concerned. They can be easily edited to provide a 'meta' reference in the manager for them.

The third, self explanetary, allows for an easy reinstall, and edit.

The fourth, my favourite, is a gem. Allows for a pure 'meta' package reference for dpkg. It's the only one i bother with for kernels, as i like to use the later kerns rather than debs backports.

Just compile the kernel directly and copy over the image manually, along with the system.map. Both bzImage and that map file suffixed with the version string found in the kernels Makefile. Such as "bzImage-2.6.18-ck11 System.map-2.6.16-ck11". Just make sure you have the 'version' option in 'General Setup' enabled in your config. Thinking of one of the graphical config styles there. And the map file will find it's kernel. The rest is just boot loader config references.

dpkg -s equivs

I find 'equivs' is just such a handy tool for getting dpkg to work my way. You will find its' description in the ...

APT HOWTO
Chapter 4 - Very useful helpers
/usr/share/doc/Debian/apt-howto/ch-helpers.en.html

==========================================
Before hand though, i would suggest the following:
==========================================

Do a dummy install using the --dry-run switch, or using a front end like 'dselect'. Just to get the output of what it wants to remove/upgrade. Then abort that process. With the packages so listed, bring them up one at a time and take down their depends and conflicts etc.

You will likely find a key dependency or package that is causing the cascade. It may be the slightest little thing. A single increment in a incremental version number.

Edit the bugger :)

ar x <repacked-package-name-and-path>

That will extract your control.tar.gz and data.tar.gz

tar -zxf control.tar.gz

Best done in a subdir, that will have your 'control' file. Edit it to suite you !, make a note in the description field so you know later what you have been doing.

tar -zcf control.tar.gz <file> <file> <etc>

to recreate the 'control.tar.gz file in that sub directory. Copy it back up to the working directory

ar vu package.deb control.tar.gz

to update the .deb file


That is a bit raw and will likely need some experimenting with, but it's basically my suggestion :). Haven't done stuff like that for a while, so i hope all the switches are around the right way. With the 'ar' command that is.

Stuff like this can be both fun and informative, depending on how it's approached ...

Good Luck


jm

http://counter.li.org
#313537