Bug#396331: upgrade-reports: sarge to etch removes kernels
Package: upgrade-reports Severity: important Upgrade went well, except for one rather big problem. If I do a straight aptitude -f dist-upgrade, it removes kernel-image-* (IE, kernel-image-2.6.8-3-686; I didn't try a 2.4 installation-upgrade). Now, I understand why older kernels must be removed for etch (udev, etc), but this is probably a problem for the average user. For the release notes, I would recommend the following procedure: 1. Edit sources.list 2. apt-get update 3. aptitude -f install linux-image-2.6-[arch] 4. dpkg --purge hotplug 5. reboot 6. aptitude -f dist-upgrade Installing the new kernel first means the old kernels will be removed, udev will be installed, only a few necessary packages are upgraded (libc6, etc), and a new, hopefully working kernel is installed in its place. The user can then reboot and verify the new kernel works before completely upgrading to etch. Of course, if the new kernel DOESN'T work, the user doesn't have anything to fall back on, but at least he knows early on. Ryan Finnie -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
Ryan Finnie wrote: Package: upgrade-reports Severity: important Upgrade went well, except for one rather big problem. If I do a straight aptitude -f dist-upgrade, it removes kernel-image-* (IE, kernel-image-2.6.8-3-686; I didn't try a 2.4 installation-upgrade). Now, I understand why older kernels must be removed for etch (udev, etc), but this is probably a problem for the average user. For the release notes, I would recommend the following procedure: 1. Edit sources.list 2. apt-get update 3. aptitude -f install linux-image-2.6-[arch] 4. dpkg --purge hotplug 5. reboot 6. aptitude -f dist-upgrade Installing the new kernel first means the old kernels will be removed, udev will be installed, only a few necessary packages are upgraded (libc6, etc), and a new, hopefully working kernel is installed in its place. The user can then reboot and verify the new kernel works before completely upgrading to etch. Of course, if the new kernel DOESN'T work, the user doesn't have anything to fall back on, but at least he knows early on. This problem (automatic removal of old kernel packages) is apparently fixed in the version of aptitude in Sid, 0.4.4-1. If this version was allowed to pass into Etch (currently aptitude in Etch is only one version behind Sid, at 0.4.3-1), then the release notes would only have to say something to the effect of Install the aptitude from Etch *before* dist-upgrading. (The Sarge release notes contained a similar instruction, BTW.) CC'ed to debian-release and aptitude maintainer for their consideration. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
On Tue, Oct 31, 2006 at 08:57:25AM -0800, Kevin B. McCarty wrote: Upgrade went well, except for one rather big problem. If I do a straight aptitude -f dist-upgrade, it removes kernel-image-* (IE, kernel-image-2.6.8-3-686; I didn't try a 2.4 installation-upgrade). Now, I understand why older kernels must be removed for etch (udev, etc), but this is probably a problem for the average user. For the release notes, I would recommend the following procedure: 1. Edit sources.list 2. apt-get update 3. aptitude -f install linux-image-2.6-[arch] 4. dpkg --purge hotplug 5. reboot 6. aptitude -f dist-upgrade Installing the new kernel first means the old kernels will be removed, udev will be installed, only a few necessary packages are upgraded (libc6, etc), and a new, hopefully working kernel is installed in its place. The user can then reboot and verify the new kernel works before completely upgrading to etch. Of course, if the new kernel DOESN'T work, the user doesn't have anything to fall back on, but at least he knows early on. This problem (automatic removal of old kernel packages) is apparently fixed in the version of aptitude in Sid, 0.4.4-1. If this version was allowed to pass into Etch (currently aptitude in Etch is only one version behind Sid, at 0.4.3-1), then the release notes would only have to say something to the effect of Install the aptitude from Etch *before* dist-upgrading. (The Sarge release notes contained a similar instruction, BTW.) Wow, what? First of all, how is there anything buggy in the current aptitude removal to justify fixing? If the old kernel-image package is marked in aptitude as auto-installed, aptitude is *supposed* to remove it, this is a feature not a bug! (It's a feature which has non-obvious consequences to many users, but I don't believe there's any sane way to fix it.) Second, the bug submitter is correct, old 2.6 kernels are not usable in etch because they're incompatible with current udev. So I don't see why we should go out of our way to keep them around anyway. I'm happy to consider requests from the maintainer for a freeze exception for aptitude (if nothing else the new version seems to include a number of l10n/i18n improvements), but the rationale you've given here sounds to me like a regression, not a bugfix... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
Steve Langasek wrote: On Tue, Oct 31, 2006 at 08:57:25AM -0800, Kevin B. McCarty wrote: This problem (automatic removal of old kernel packages) is apparently fixed in the version of aptitude in Sid, 0.4.4-1. If this version was allowed to pass into Etch (currently aptitude in Etch is only one version behind Sid, at 0.4.3-1), then the release notes would only have to say something to the effect of Install the aptitude from Etch *before* dist-upgrading. (The Sarge release notes contained a similar instruction, BTW.) Wow, what? First of all, how is there anything buggy in the current aptitude removal to justify fixing? If the old kernel-image package is marked in aptitude as auto-installed, aptitude is *supposed* to remove it, this is a feature not a bug! (It's a feature which has non-obvious consequences to many users, but I don't believe there's any sane way to fix it.) Sorry, maybe I didn't make myself understood well, or else I didn't understand the bug report. If I read correctly, the submitter is complaining that his dist-upgrade wanted to remove the package containing the **currently running** kernel. Wouldn't that be a problem?? -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
On Tue, Oct 31, 2006 at 03:04:49PM -0800, Kevin B. McCarty wrote: Sorry, maybe I didn't make myself understood well, or else I didn't understand the bug report. If I read correctly, the submitter is complaining that his dist-upgrade wanted to remove the package containing the **currently running** kernel. That's correct. Wouldn't that be a problem?? Yes, but how do you think the new aptitude is going to fix it? Why *should* aptitude try to fix it? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
Steve Langasek wrote: On Tue, Oct 31, 2006 at 03:04:49PM -0800, Kevin B. McCarty wrote: Sorry, maybe I didn't make myself understood well, or else I didn't understand the bug report. If I read correctly, the submitter is complaining that his dist-upgrade wanted to remove the package containing the **currently running** kernel. That's correct. Wouldn't that be a problem?? Yes, but how do you think the new aptitude is going to fix it? By always considering linux-image-* to be manually installed, apparently: aptitude (0.4.4-1) unstable; urgency=low [snip] - Change the default settings to leave unused Linux kernel images on the system. (Closes: #386307) (Sorry, it wasn't clear to me whether that was a rhetorical question or not.) Hmm, I looked at #386307 and apparently the kernel-image-* packages themselves have a method to prevent removal of a running kernel. It's not nearly as nice as a fix in aptitude would be, though; it just amounts to a scary question in the kernel prerm script, Remove the running kernel image?. (This question is not even debconf'ized in the Sarge kernels.) If one answers no (the default), the removal fails. (For further confusion later, in the Etch kernel packages, the corresponding Debconf question has the sense of the yes/no answer reversed ...) If aptitude is trying to do a lot of other things in the same run, as is typical in a dist-upgrade, the kernel package prerm failure may leave many other packages temporarily unconfigured, and the user will probably have to re-run the operation after marking the old kernel-image package as not to be removed. Why *should* aptitude try to fix it? IMO, the benefits of users not having to see the scary kernel removal message, answer the right thing to it, and then have to re-run aptitude after explicitly marking the old kernel package to remain installed, outweigh the annoyance of having old kernel packages remain installed on their systems. If you disagree, though, I doubt I can say anything to change your mind. Then I guess the release notes should be adjusted to suggest the best order of operations. However the release note change suggested by the original submitter of this bug doesn't seem to help the situation any. Tested on my sarge system: benjo[1]:/home/kmccarty# vim /etc/apt/sources.list [add line for etch] benjo[2]:/home/kmccarty# apt-get update [...] benjo[3]:/home/kmccarty# aptitude -f install linux-image-2.6-k7 [...] The following packages will be REMOVED: [...] initrd-tools kernel-image-2.6.8-3-k7 lapack-dev lesstif2-dev ^^^ [...] Do you want to continue? [Y/n/?] n Abort. benjo[4]:/home/kmccarty# uname -a Linux benjo 2.6.8-3-k7 #1 Thu Sep 7 05:09:40 UTC 2006 i686 GNU/Linux ^^ So that's not going to work so well. (There's also an issue with libfam0/libfam0c102 that I'll report as a separate bug to upgrade-reports.) best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
On 10/31/06, Ryan Finnie [EMAIL PROTECTED] wrote: The etch libc6 Conflicts: initrd-tools ( 0.1.84.1), however the etch initrd-tools *IS* 0.1.84.1. So yeah, there is a problem (supposedly fixed in sid) with conflict resolution. As it turns out, you can continue to use 2.6.8 on an etch machine, as long as you keep hotplug and don't install udev. Excuse me, it seems this only happens when you do aptitude -f install aptitude (as the release notes suggest) (actually, it'll happen when you install anything that depends on libc6). aptitude -f dist-upgrade alone, using sarge's aptitude, tries to remove all kernels. So, should the release notes not encourage people to install an updated aptitude before dist-upgrading? As a workaround, I did find that if you aptitude -f install initrd-tools, it just updates initrd-tools and no other packages. So: 1. aptitude -f install initrd-tools 2. aptitude -f install aptitude 3. aptitude -f dist-upgrade This procedure allows you to upgrade aptitude before the main dist-upgrade, but it when done in this order, does not delete your kernels. Ryan Finnie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
On 10/31/06, Ryan Finnie [EMAIL PROTECTED] wrote: On 10/31/06, Ryan Finnie [EMAIL PROTECTED] wrote: The etch libc6 Conflicts: initrd-tools ( 0.1.84.1), however the etch initrd-tools *IS* 0.1.84.1. So yeah, there is a problem (supposedly fixed in sid) with conflict resolution. As it turns out, you can continue to use 2.6.8 on an etch machine, as long as you keep hotplug and don't install udev. Excuse me, it seems this only happens when you do aptitude -f install aptitude (as the release notes suggest) (actually, it'll happen when you install anything that depends on libc6). aptitude -f dist-upgrade alone, using sarge's aptitude, tries to remove all kernels. Gah. Sorry, that was supposed to be: aptitude -f dist-upgrade alone, using sarge's aptitude, DOESN'T try to remove all kernels. So, my original bug report was wrong. A straight aptitude dist-upgrade doesn't remove kernels. However, trying to update aptitude itself does. So the release notes should probably either drop the part about recommending updating aptitude itself first, or it should mention the initrd-tools/aptitude/dist-upgrade dance I said in my last email. Ryan Finnie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396331: upgrade-reports: sarge to etch removes kernels
On Wednesday 01 November 2006 02:54, Ryan Finnie wrote: So, should the release notes not encourage people to install an updated aptitude before dist-upgrading? As a workaround, I did find that if you aptitude -f install initrd-tools, it just updates initrd-tools and no other packages. So: 1. aptitude -f install initrd-tools 2. aptitude -f install aptitude 3. aptitude -f dist-upgrade This procedure allows you to upgrade aptitude before the main dist-upgrade, but it when done in this order, does not delete your kernels. I'm not sure that we really need to update aptitude before anything else for Etch. For Sarge an upgrade of aptitude before upgrading the rest of the system _was_ needed because Woody's aptitude had some problems in dependency resolution. I'm not aware of any issues in Sarge's aptitude that would require us to do the same for Etch. IIRC the instructions to upgrade aptitude first have already been removed from the draft release notes for Etch. As far as keeping the old kernel is concerned, I'd suggest documenting in the release notes how to make sure it is not removed (i.e. manually marking it not automatically installed) rather than upgrading aptitude for that (provided the RMs OK the new feature to keep old kernel images). As for the usefulness of that feature, I'm mildly in favor of it as it will also protect users from having their box unbootable by kernel security upgrades after the release. The value of this is only limited though: - it is only needed if the security update is broken - the old kernel is only actually saved if there was an ABI change and thus a change in the package name; you could possibly argue that the chance of breakage is slightly higher of upgrades involving ABI changes However, some mechanism in the kernel packages themselves that saves the old kernel image and initrd in _all_ cases seems like a more structural solution. (Maybe leaving a package management issue with regard to which package owns the old kernel/initrd.) Cheers, FJP pgpucrrY4EiFl.pgp Description: PGP signature
