Re: Aptitude/Grub Problem -- Is this a bug?
On Thursday 23 February 2006 18:23, Hal Vaughan wrote:
> I posted earlier this week about some problems I had after doing:
>
> aptitude update && aptitude upgrade
>
> on a Sarge system. It required rebooting and was immediately unbootable
> -- ON SARGE!!! This is the very stuff I am using stable to avoid!
>
> I lost a day tracking it down and finally found that when a kernel image
> is updated, update-grub is run. Normally when apt/dpkg or whatever part
> of apt actually upgrades a program and needs to update a config file, it
> gives you a choice of updating or sticking with the old file, or, at the
> very least, gives you a prompt and warns you of the change. However,
> when a kernel image is updated, it does not do ANY of these things. It
> doesn't warn you to back up the /boot/grub/menu.lst file, it doesn't back
> it up itself, and it does not, in any way, let you know it is doing this.
>
You aren't given a choice of keeping your old grub config file, because
without an update, you can't boot the new kernel. Well, OK, you can, if
you manually create the entry at the grub prompt, but you know what I mean.
You aren't warned about update-grub removing an entry for a kernel, because
this is only done when you remove a kernel. If you've removed a kernel,
but don't remove its grub entry, then you've got an entry that you can't
use to boot. You don't want that.
> I know some users know every detail of their systems, but I can't do
> that. I have a business to run and I started using Debian Stable because
> it is supposed to not mess with things when it upgrades. I could not
> find anything warning me of this. It turns out there is documentation in
> updategrub's man file that I have since used to make sure the options
> I've put in the list of boot kernels is kept, but through testing, I've
> seen updategrub will wipe out all entries for other kernels not the
> current root partition (and this happens whenever apt upgrades the kernel
> image).
>
I'm not sure of your exact situation, but my experience with update-grub is
that it only creates or keeps entries for kernels it thinks are installed.
I don't know whether or not update-grub depends on apt's database, or if it
just searches for kernels, but the source would surely tell you.
> Considering that the intent of stable is to make it so reliable one can
> upgrade and count on the system continuing to work well, I cannot see how
> this lack of warning (and not making a backup) as anything other than a
> serious bug. It could be easily fixed by prompting the user with a
> warning menu.lst is about to be overwritten, so there's time to back it
> up. Even better the standard prompt for whether or not to overwrite a
> config file would be nice, since it would let the user decide to update
> menu.lst or not (or maybe back it up).
>
> Is this not a bug? Was I just supposed to somehow know that out of all
> the packages out there, this was a specific behavior in upgrading the
> kernel? It makes me wonder how many other exceptions are out there that
> I don't know about that could crash my system next time I upgrade.
>
> Do others feel a prompt would be appropriate in this case? I'd like to
> hear feedback before I submit it as a bug, since there may be some good
> reasons for doing this, however, I cannot imagine a single good reason
> for overwriting a file this important without at least telling the
> user/admin that it is happening.
>
> Hal
What kernel package updated? If your kernel is installed because of a
package like linux-image-2.6-686, then I might understand what happened
here. That is a dependency package. When you install that package with
aptitude, it pulls in the relevant kernel as a dependency, and marks it as
being automatically installed to satisfy dependencies. When that package
updates, and points to a new kernel package, then aptitude removes the old
kernel, since it was only installed to satisfy a dependency, and installs
the new package. In this case, your working kernel will be removed (along
with it's grub entry), and the new kernel will be put in its place. If
something fails in this operation, you would get an unbootable system (if
that was your only kernel).
The solution is to mark the kernel your using as manually installed, so that
it is not removed when it is no longer needed by any other package.
In my experience, aptitude doesn't remove kernels that are old unless I
specifically request it, but that's because I manually select which kernel
I want, and I don't use the metapackage. I always end up with grub entries
for each kernel that's installed, with the newest being the default, but
the older ones still available.
Now, if you're not using a metapackage for your kernel, but specifically
requested a specific version, and aptitude deleted it without warning,
there's some sort of bug. Note, however, that apt-get doesn't keep track
of manually and automatically installed packages. So if you used apt-get
to install a package, aptitude won't know if it was manually selected or
just installed as a dependency. I believe aptitude is supposed to default
unknown packages to manually selected, but there may be a config option to
change this (or I could be wrong).
So what kernel were you using, via what package, and what kernel did you
upgrade to, via what package, and did aptitude warn you it was removing the
older kernel? You don't mention this, but I'd be surprised if it did and
you missed it.
Justin
Reply to: