Crash while upgrading kernel & stable releases

Markus Kolb ubuntu-ml at
Mon Jun 20 09:59:28 CDT 2005

Vincent Untz wrote on Mon, Jun 20, 2005 at 16:09:30 +0200:
> On Mon, June 20, 2005 15:21, Markus Kolb said:
> > Vincent Untz wrote on Mon, Jun 20, 2005 at 11:12:49 +0200:
> >> Hi,
> >>
> >> I updated one of my Hoary computer yesterday and, unfortunately, it
> >> crashed during the upgrade. What was really unfortunate, is that there
> >> was a kernel upgrade. And what was even more unfortunate is that the
> >> kernel version number was the same as the previous one. So it deleted
> >> the old one...
> >>
> >> As you can guess, the result was that the computer was unbootable (and
> >> still is ;-)). I know the upgrade contains only security fixes, but I
> >> believe the version number should have been incremented, if only to
> >> prevent problems like this one. Wouldn't it make sense to adopt this
> >> policy?
> >
> > The package version has to be incremented or it won't be upgraded.
> I was not talking about the package version, but the kernel version :-)
> > The problem exists in any Linux distribution and is based on the package
> > name which doesn't change and so all files of the old package will be
> > deleted before the files of the newer package will be installed.
> That's the problem, indeed. The problem is: why is the new package named
> linux-image-2.6.10-5-686, while it could be linux-image-2.6.10-6-686 or
> linux-image-2.6.10-5-686-fix1 or...?

That would enable the possibility to install the upgraded kernel
together with the older one.
But package management would not detect that there is an updated kernel
package available because package name is different to the older one.
For package manager it would be a total different package with no
relation to the old installed package.

A solution would be so far to use a metapackage which depends on the
up-to-date kernel package and kernel package depends back to the
metapackage. So installing a kernel package would install the
metapackage which is responsible for updates.
If there is an updated kernel package with new package name the
metapackage must be updated to depend on this new kernel package.
The metapackage should also suggest any older kernel package for
installation or the old kernel package will be marked for deinstallation
on upgrades.

When running the updated kernel the older kernel packages can be
deinstalled by user if he/she wants.

I think that would do it. 

> > RPM based distributions have a more detailed version number scheme on
> > the kernel files in a package which is in Debian and Ubuntu only the
> > main version.
> > But because of dpkg package management there won't be any change if the
> > version numbers would be more detailed.
> > I think dpkg has not an interface for removing a package only in
> > database without deinstalling it's files like RPM has.
> And I don't think we want this. Do we?
> > So at the moment you have to manage a backup copy of your kernel files
> > yourself.
> > And/or you do a double check of the kernel updates before you reboot.
> Unfortunately, this is not acceptable for the users who don't want to
> learn how this works. This is why I think a kernel upgrade in a stable
> release should leave the previous kernel, at least until the new one
> is completely installed. I can fix the problem, but my mother/sister/etc.
> can not.

Yes, that's right.
I create a wish bug report against kernel package.

More information about the ubuntu-devel mailing list