Re: Aptitude/Grub Problem -- Is this a bug?
Hal Vaughan wrote: It didn't just remove an entry. Update-grub completely overwrites the file so any entries for kernels on other partitions are gone. ### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default options below If you put a custom kernel entry in between these lines without reading the above, then you made a mistake and update-grub was well within its rights to delete it. If you put it anywhere else in the file and update-grub removed it, then the debian bug tracking system is at http://bugs.debian.org/ for your bug report. -- see shy jo signature.asc Description: Digital signature
Re: Aptitude/Grub Problem -- Is this a bug?
On Friday 24 February 2006 17:06, Joey Hess wrote: Hal Vaughan wrote: It didn't just remove an entry. Update-grub completely overwrites the file so any entries for kernels on other partitions are gone. ### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default options below If you put a custom kernel entry in between these lines without reading the above, then you made a mistake and update-grub was well within its rights to delete it. Yes, that's come up in this thread. I don't know if my copy of menu.lst is non-standard at this point, but when I loaded it in vi and edited the kernels I needed to, that was nowhere near what I was working on. Since it's come up since, I checked and it was at least a screen, if not two, above the section I was working on. I'd *like* to go through and read every comment in every config file I edit, but after a while, if you are actually using your computer as a tool, instead of as something to spend forever setting it up, there is a practical limit to just how much you can hunt and peruse through each file to find info. I'm running a business, which, until recently, took 16 hours a day, including writing the software and keeping it running. I read as much as I can on things like this, but, as in all things, if you're actually *doing* something and not just using the computer to play Mr. Admin, there's a point where you have to work with the docs you've read on the howto to fix what you're dealing with. The other point is that I did not see anything, anywhere, saying, If the kernel is updated, even if the kernel version number stays the same, update-grub will be run and your auto-magic kernels will be overwritten. In other words, the default is to run update grub, which can overwrite, but it isn't stated anywhere and aptitude or whatever program aptitude runs to update the kernel image does not warn the user. If you put it anywhere else in the file and update-grub removed it, then the debian bug tracking system is at http://bugs.debian.org/ for your bug report. I've filed it. My sense is the responder is more in a hurry to close it so he doesn't have to actually work on it than in looking at the problem. I'm corresponding with him and I'll see what happens. My position is that as aptitude is upgrading the system, before it runs update-grub, it should notify the user it's about to be overwritten. Why not? Every other time it overwrites a config file, it does that. Hal P.S. Sorry if I sound a bit snotty -- I know now there is that comment in menu.lst, but even if I had read it (and may have) at first, it still didn't say anything about kernel updates and that forcing update-grub to be run. I'm just overall irritated that every config file on my system warrants a prompt whether or not I want it overwritten, except the one file needed to boot it in the first place. It's not you -- right now I'm just pissed off at a maintainer who would rather say, It's not my job, then to examine the issue and solve it. I am hoping he understands my responses and sees what I mean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude/Grub Problem -- Is this a bug?
On Fri, 24 Feb 2006 17:19:19 -0500 Hal Vaughan [EMAIL PROTECTED] wrote: [snip] Okay. That's easy and makes sense. But there is still a problem, but may be more with grub. I went through the man pages of grub and did a lot of research to figure out how to make the changes I needed. Not once did I see this documented. So there is basically a default behavior to overwrite the file, but any documentation on how to prevent changes from being overwritten is obscure. This one incident has really led me to question the overall stability of Stable and wonder when another muck-up like this will happen because all the documentation warning about such a default behavior is obscure. update-grub is run on *every* kernel install/removal/upgrade and it has to. If you customize your menu.lst the file itself contains the indications on how to do this in order to keep the changes across updates. It has ways of specifying kernel options for all version or just for one subversion, which alternates to include for each kernel ... I do agree this can not be considered proper documented, but then again, update-grub is Debian specific and any grub docs don't know anything about it. I can't think of a better way to document this. If you file a bug I think it should be against whatever package contains update-grub. It probably should have a BIG warning that it is changing menu.lst, or at least make a back-up of the old file. The later would be trivial to implement. Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude/Grub Problem -- Is this a bug?
On Saturday 25 February 2006 06:26, Andrei Popescu wrote: On Fri, 24 Feb 2006 17:19:19 -0500 Hal Vaughan [EMAIL PROTECTED] wrote: [snip] Okay. That's easy and makes sense. But there is still a problem, but may be more with grub. I went through the man pages of grub and did a lot of research to figure out how to make the changes I needed. Not once did I see this documented. So there is basically a default behavior to overwrite the file, but any documentation on how to prevent changes from being overwritten is obscure. This one incident has really led me to question the overall stability of Stable and wonder when another muck-up like this will happen because all the documentation warning about such a default behavior is obscure. update-grub is run on *every* kernel install/removal/upgrade and it has to. If you customize your menu.lst the file itself contains the indications on how to do this in order to keep the changes across updates. It has ways of specifying kernel options for all version or just for one subversion, which alternates to include for each kernel ... Thank you. That is quite helpful. I just installed a new system last night, and tested this by putting extra arguments in menu.lst, THEN doing aptitude update aptitude upgrade. The result was an overwritten menu.lst, automatically. So my experience confirms what you've said. This is an automatic part of a kernel update. I do agree this can not be considered proper documented, but then again, update-grub is Debian specific and any grub docs don't know anything about it. I can't think of a better way to document this. That is my opinion. So maybe it's not aptitude's problem. And your point that it is NOT properly documented is my issue. Yes, there are comments in menu.lst about the automagic kernel list, and yes, there are comments in update-grub's man page. However, if you're making one change to the kernel options, there is often no reason to read those. For example, I needed to add ide-reverse to the kernel options. I had found that from a lot of hard research. The post I found it in did NOT include any comments about this problem. The author may not have used Debian, or may not have been aware of this problem, and may eventually have been nailed by it, just as I was. I had no reason, in that careful research to read the man page for update-grub and, even more, was totally unaware of its existence. There was no obvious place telling me about it. If you file a bug I think it should be against whatever package contains update-grub. It probably should have a BIG warning that it is changing menu.lst, or at least make a back-up of the old file. The later would be trivial to implement. That is my thinking ,exactly. It should be rather trival to include some print or printf statements and wait for the user to press enter, or to even go so far as to let them pick choices of continue, abort, or backup the original. Update-grub is a Bash script, so it would not be easy to do this, but it would be really nice if it could read the kernel options in the automagic kernels and if there are some options that are used for every kernel, include them in the rebuild. The problem is that the default behavior can bring down a system and there is no warning of it anywhere beforehand. Thanks for the extra insight. Hal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude/Grub Problem -- Is this a bug?
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]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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,
Re: Aptitude/Grub Problem -- Is this a bug?
On Friday 24 February 2006 11:51, Chris Lale wrote: Hal Vaughan wrote: [snip] 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? upgrade will only install newer versions of packages. If package foo changes its dependencies from bar to barc2a (for a C++ ABI transition, for example), then upgrade will not attempt to upgrade package foo. Dist-upgrade is allowed to install new packages and remove old (hopefully only obsolete) ones. So dist-upgrade will upgrade foo, install barc2a, and remove bar. 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? Aptitude and apt-get do indeed handle dependencies differently. Well, they have a different set of logic to try to resolve dependencies. Sometimes that leads to different results, sometimes that leads to more pain doing a specific circular upgrade with one versus the other. People's experiences and impressions vary wildly. Hope that helps, Justin
Re: Aptitude/Grub Problem -- Is this a bug?
On Friday 24 February 2006 13:24, Justin Guerin wrote: 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. 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 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. 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. 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. 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 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. It seems to just search for kernels on the current boot or system partition. 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
Re: Aptitude/Grub Problem -- Is this a bug?
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
Re: Aptitude/Grub Problem -- Is this a bug?
On Friday 24 February 2006 16:56, Justin Guerin wrote: 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? I just filed a bug report on it (#354243). The guy seemed pretty anxious to close it and just dismissed it as a non-aptitude thing, saying I had set a kernel config file to do it, which I had not. I think he was more interested in closing the bug then in dealing with the issue. If anyone wants to include more on the bug report, please feel free. 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. Okay. That's easy and makes sense. But there is still a problem, but may be more with grub. I went through the man pages of grub and did a lot of research to figure out how to make the changes I needed. Not once did I see this documented. So there is basically a default behavior to overwrite the file, but any documentation on how to prevent changes from being overwritten is obscure. This one incident has really led me to question the overall stability of Stable and wonder when another muck-up like this will happen because all the documentation warning about such a default behavior is obscure. 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. Bingo! Thanks for saying what I was trying to say. It's like putting a button your VCR to rewind the tape, and not including in the directions, Oh, yeah, by the way, this fast auto-rewind will blank the tape as it rewinds, and making the button look okay on the VCR, with no warnings, and somehow expecting everyone to have read that one paragraph in the docs or to expect unreasonable and unlikely behavior from that button. 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. I included that
Aptitude/Grub Problem -- Is this a bug?
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
