On Friday 24 February 2006 12:07, Hal Vaughan wrote: > On Friday 24 February 2006 13:24, Justin Guerin wrote: > > On Thursday 23 February 2006 18:23, Hal Vaughan wrote: [snip] > > > > 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. > > In this case, it's the same kernel image (again, I'm only upgrading > Sarge for security and bug fixes), so menu.lst did not need to be > changed to load a patched version of the same kernel version. > You're right. I wonder if that call is in there because LILO does need to be run in such a situation?
> > 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. > > It didn't just remove an entry. Update-grub completely overwrites the > file so any entries for kernels on other partitions are gone. > > Picture this: you have 5 partitions, each with a different OS or > different Linux distros and different kernel versions on them. One > partition is your production partition, the one that HAS to always > work, so you use Sarge for it because upgrades/updates in Sarge are not > supposed to mess anything up. Do an "aptitude update && aptitude > upgrade" on your Sarge partition and, at least on my recent one, > aptitude finds a updated version of the kernel image you're using, so > it downloads and installs it. Now, since it's Sarge, so you're not > adding anything in an upgrade, and it is only replacing the same kernel > image. That means the same entry in menu.lst will work for the > replacement kernel (same is true if only modules are upgraded). > > Menu.lst is replaced anyway, which wipes out the entries for kernels and > OSes on the other 4 partitions and any custom options for that > particular kernel as well as custom options for any other kernels on > that partition. > Now I understand your problem. If those entries were outside of the ### BEGIN AUTOMAGIC KERNELS LIST ### END DEBIAN AUTOMAGIC KERNELS LIST then update-grub shouldn't have touched them, and you should file a bug. However, if the entries for the other OSes and kernels on other partitions wasn't outside of those, then update-grub assumes it's supposed to manage them. Still, I can see how you have to know something in order to avoid that mistake, and I agree with you: if you have to know something about how the program operates, then there should be some sort of warning. At the very least, it should tell you what it plans to do and give you an opportunity to back out. > Since this happened, I found that it is possible, in menu.lst, to > specify the default kernel options that are used and a few other > features so update-grub will use the config options I need when it > updates menu.lst, so (I think) I am protected on that for now. > > The issue is that one has to FIND the additional options to fix the > situation and prevent a change that keeps your system from booting. > There is nothing, anywhere, to alert a sys admin that this will happen > and must be taken into account. > Yes, I agree. Do you think a dialog box is best? Or is a comment within the menu.lst file sufficient? Whatever you think is the right solution should be put in the bug report. [snip] > > > > 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. > > That's what I've found -- and only kernels on the current partition. It > has little intelligence or ability to find kernels on other partitions > or to even scan the current list of entries and copy them (even copy > them commented out) into the new version. > I believe update-grub should copy verbatim the config of kernels outside the automagic area. If it's not, that's a bug. I know grub doesn't scan other partitions for kernels. I think that would be a wishlist item. It's worth filing, though the developers of grub might think of that as being outside grub's scope. [snip] > > 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. > > kernel-image-2.6.8-2-686, which includes the full version number, which > is, I *think* not the same as 2.6. > Yes, it's a specific, full version number, not a metapackage. > ... > > > 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. > > It wasn't a kernel upgrade. I'm not sure why aptitude actually calls it > an upgrade. It was "aptitude update && aptitude upgrade", which pulls > down the latest packages, which, on Sarge, means only updating bug and > security fixes. So, while it is called an upgrade, it should not have > actually upgraded to a new kernel version. No kernel was removed. > Part of the version string of the kernel was updated, therefore it was considered an upgrade. Even though most of the files were upgraded in place, because the kernel modules' version numbers have to match exactly with the kernel's version numbers, every file has to be replaced, and it's considered an upgrade. Technically, a kernel was removed. > Even if I were upgrading to a new kernel, it seems to me if I am not > removing an earlier version, it should still keep that entry intact. > Yea, it should. However, this is a special case, where both kernels can't exist at the same time, even though they're different versions. I would prefer a completely separate install path for upgrades like this, but I'm not a developer, and there are likely reasons why it works the way it does that I'm not aware of. > Thanks for the comments and for the ideas. I still think this is a bug, > under the category of oversight. I can see the need to re-write the > file, but that is a problem when it can just dump a lot of > configuration settings for kernels on other partitions or special > settings for other kernels. > > Hal Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
