Re: Aptitude/Grub Problem -- Is this a bug?
On Friday 24 February 2006 11:51, Chris Lale wrote:
> 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.
> >
> > 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).
> >
> > 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
>
> A couple of thoughts come to mind. I don't kow if they will help you.
>
> 1. Use
>
> aptitude update && aptitude dist-upgrade
>
> instead of aptitude update && aptitude upgrade. This will deal
> intelligently with dependendies.
My understanding (and what the man page says) that dist-upgrade is more
aggressive. Is that wrong?
> 2. I have always found apt-get totally reliable during upgrade. I
> have had a couple of frights using Synaptic or Aptitude for upgrades.
I was using apt, but I've heard that the "official" and preferred way is
aptitude and that they handle some issues differently, so the point is
to pick one and stick with it. Is this still the case?
>
> I also had a similar experience to yours when I upgraded to Etch and
> then installed a new linux-image (replacement for kernel-image in
> Etch). I could not boot normally, but I could boot from Grub in
> recovery mode (run level 1). After supplying the root password for
> maintenance, I retried
>
> apt-get dist-upgrade
>
> This failed at first, but suggested
>
> apt-get -f install
>
> This did the trick. I have a feeling that one or more of the services
> running via /etc/init.d were somehow affecting apt. If you have a
> number of extra daemons running, you could try stopping them before
> upgrading. I have a notebook that upgraded to Etch from a fresh Sarge
> install with no problem at all.
I could understand that causing some issues, but this was a Sarge
upgrade, ONLY for bug fixes and security issues. Shouldn't that have
been smooth?
I'm still confused as to why /boot/grub/menu.lst is re-written without
any prompting or warning when all other config files that may be
changed cause the user to be prompted for input.
Hal
Reply to: