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.
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 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.
Hth,
Chris.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
