4005 kB + 61.4 MB + 2264 kB does not give 172 MB.
Actions Undo Package Resolver Search Options Views Help
C-T: Menu ?: Help q: Quit u: Update g: Preview/Download/Install/Remove Pkgs
Packages Preview
aptitude 0.8.13 @ cventin Disk: -172 MB
--\ Packages being removed because they are no longer used (3)
ipA linux-headers-6. -4005 kB 6.10.7-1 <none>
ipA linux-headers-6. -61.4 MB 6.10.7-1 <none>
ipA linux-kbuild-6.1 -2264 kB 6.10.7-1 <none>
--- Packages being held back (12)
--- Packages being automatically held in their current state (29)
IIRC, the "Disk" value changed when I hit "_" over the
"Packages being removed because they are no longer used"
section.
Wow! This is much worse than expected! When I typed 'g' to remove the 3 packages, aptitude also removed the linux-image-6.10.7-amd64 kernel package, which was *not* in the list of packages to be removed. Performing actions... (Reading database ... 752963 files and directories currently installed.) Removing linux-headers-6.10.7-amd64 (6.10.7-1) ... Removing linux-headers-6.10.7-common (6.10.7-1) ... Removing linux-image-6.10.7-amd64 (6.10.7-1) ... /etc/kernel/prerm.d/dkms: dkms: removing: nvidia-legacy-390xx 390.157 (6.10.7-amd64) (x86_64) Module nvidia-legacy-390xx-390.157 for kernel 6.10.7-amd64 (x86_64). Before uninstall, this module version was ACTIVE on this kernel. nvidia-legacy-390xx.ko.xz: - Uninstallation - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. nvidia-legacy-390xx-modeset.ko.xz: - Uninstallation - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. nvidia-legacy-390xx-drm.ko.xz: - Uninstallation - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. nvidia-legacy-390xx-uvm.ko.xz: - Uninstallation - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. do_depmod 6.10.7-amd64 /etc/kernel/postrm.d/initramfs-tools: update-initramfs: Deleting /boot/initrd.img-6.10.7-amd64 /etc/kernel/postrm.d/zz-update-grub: Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-6.10.11-amd64 Found initrd image: /boot/initrd.img-6.10.11-amd64 Found linux image: /boot/vmlinuz-6.10.9-amd64 Found initrd image: /boot/initrd.img-6.10.9-amd64 Found linux image: /boot/vmlinuz-6.1.0-25-amd64 Found initrd image: /boot/initrd.img-6.1.0-25-amd64 Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... done Removing linux-kbuild-6.10.7 (6.10.7-1) ...
This issue occurred again for the new Linux kernel upgrade. Here's additional information. The reformatted diff on the /var/lib/aptitude/pkgstates file just after the upgrade:---------------------------------------- Package: linux-headers-6.10.12-amd64 Architecture: amd64 Unseen: yes State: 1 -Dselect-State: 0 +Dselect-State: 1 Remove-Reason: 0 -Auto-New-Install: yes Package: linux-doc-6.10 Architecture: amd64 Unseen: yes State: 1 Dselect-State: 1 Remove-Reason: 0 -Upgrade: yes Package: linux-headers-6.10.12-common Architecture: amd64 Unseen: yes State: 1 -Dselect-State: 0 +Dselect-State: 1 Remove-Reason: 0 -Auto-New-Install: yes Package: linux-headers-6.10.9-common Architecture: amd64 Unseen: yes -State: 1 +State: 3 Dselect-State: 1 -Remove-Reason: 0 +Remove-Reason: 4 Architecture: amd64 Unseen: no State: 1 Dselect-State: 1 Remove-Reason: 0 -Upgrade: yes Package: linux-image-amd64 Architecture: amd64 Unseen: no State: 1 Dselect-State: 1 Remove-Reason: 0 -Upgrade: yes Package: linux-doc Architecture: amd64 Unseen: no State: 1 Dselect-State: 1 Remove-Reason: 0 -Upgrade: yes Package: linux-headers-6.10.9-amd64 Architecture: amd64 Unseen: yes -State: 1 +State: 3 Dselect-State: 1 -Remove-Reason: 0 +Remove-Reason: 4 Package: linux-kbuild-6.10.9 Architecture: amd64 Unseen: yes -State: 1 +State: 3 Dselect-State: 1 -Remove-Reason: 0 +Remove-Reason: 4 Package: linux-image-6.10.12-amd64 Architecture: amd64 Unseen: yes State: 1 -Dselect-State: 0 +Dselect-State: 1 Remove-Reason: 0 -Auto-New-Install: yes Package: linux-libc-dev Architecture: amd64 Unseen: no State: 1 Dselect-State: 1 Remove-Reason: 0 -Upgrade: yes ---------------------------------------- and "apt install -f -s" outputs The following packages were automatically installed and are no longer required: linux-headers-6.10.9-amd64 linux-headers-6.10.9-common linux-image-6.10.9-amd64 linux-kbuild-6.10.9 Use 'apt autoremove' to remove them. but note that aptitude does not say anything about the old kernel image linux-image-6.10.9-amd64 in the /var/lib/aptitude/pkgstates diff above. It still has: Package: linux-image-6.10.9-amd64 Architecture: amd64 Unseen: yes State: 1 Dselect-State: 1 Remove-Reason: 0 In its TUI, aptitude initially says, just after the upgrade: Packages Preview aptitude 0.8.13 @ cventin Disk: -67.6 MB --\ Packages being removed because they are no longer used (3) idA linux-headers-6. -4012 kB 6.10.9-1 6.10.9-1 idA linux-headers-6. -61.4 MB 6.10.9-1 6.10.9-1 idA linux-kbuild-6.1 -2271 kB 6.10.9-1 6.10.9-1 and no other packages are marked as to be removed (not even linux-image-6.10.9-amd64). Just after hitting '_' over "Packages being removed because they are no longer used", I get Packages Preview aptitude 0.8.13 @ cventin Disk: -172 MB --\ Packages being removed because they are no longer used (3) ipA linux-headers-6. -4012 kB 6.10.9-1 6.10.9-1 ipA linux-headers-6. -61.4 MB 6.10.9-1 6.10.9-1 ipA linux-kbuild-6.1 -2271 kB 6.10.9-1 6.10.9-1 In particular, the "Disk:" value has changed. And still no other packages are marked as to be removed, which is contradictory with the change of the "Disk:" value. After hitting 'qg', I get: Packages Preview aptitude 0.8.13 @ cventin Disk: -172 MB --\ Packages being removed because they are no longer used (4) ipA linux-headers-6. -4012 kB 6.10.9-1 6.10.9-1 ipA linux-headers-6. -61.4 MB 6.10.9-1 6.10.9-1 idA linux-image-6.10 -104 MB 6.10.9-1 6.10.9-1 ipA linux-kbuild-6.1 -2271 kB 6.10.9-1 6.10.9-1 Now linux-image-6.10.9-amd64 is marked as to be removed (and has 'd' instead of 'p'). It seems that contrary to apt, aptitude detects too late that linux-image-6.10.9-amd64 should be removed, with 2 consequences when hitting '_' to purge instead of just remove: * aptitude adds linux-image-6.10.9-amd64 to the package to be removed, but the user is not notified, so this is big surprise if the user does not do 'qg' first, and possibly incorrect and too late if the user does not want to remove this kernel image (e.g. because the newer images are broken). * linux-image-6.10.9-amd64 will just be removed, but not purged.
Hi Vincent, Thanks, that helps a bit. […] For me this looks as if linux-image-6.10.12-amd64 is marked as to be installed automatically via dependency. Yes, this tells us that linux-image-6.10.9-amd64 was marked as automatically installed, too. Correct. It wasn't to be uninstalled at point, too, as you wrote: Vincent Lefevre wrote: I think here's the main issue(s): Any interactive package action change makes aptitude reevaluating the state of all related packages, especially in the case of removal or purging all dependencies marked as "automatically installed" to see if they need to be removed, too. In general this reevaluation is needed for the options * "Automatically resolve dependencies of a package when it is selected", * "Automatically fix broken packages before installing or removing", and * Remove unused packages automatically. I suspect the latter setting is involved here. I wonder though, why does aptitude reevaluate these states if a package changes from removal to purging as this only changes if the configs are removed, too, or not. The package will be removed in both cases. Might be something which just hadn't been optimised out. There are known cases where aptitude removes unneeded packages only upon a second evaluation (usually after update/install/remove run) that a package can be removed. (My suspicion here is aptitude's resolver being not perfect around Provides.) But I think that one's not involved here as there seem no Provides involved. What is likely involved here is https://bugs.debian.org/902652 which refers to src/generic/apt/aptcache.cc:2664: std::string matchterm = aptcfg->Find(PACKAGE "::Keep-Unused-Pattern", "~nlinux-image-.*"); i.e. that aptitude has still something like "never autoremove packages starting with 'linux-image-'" hardcoded. But this issue as well as the fact that enough older kernels (but IIRC never the currently running one) have been proposed for automatical removal in aptitude to me, shows that it is only conditionally applied. So there's definitely a bug in here that triggers the removal of additional packages if a package, which is already marked for removal, is later also marked for purging despite it previously didn't consider that additional package. I though don't think that's a grave bug. From my experience it's an annoying but seldom happening one. And it's IMHO the bug which needs to fixed here. What happened in your is that it appeared together with something which is as far as I can see not a bug but a design decision: automatically updated, as this would cost a lot of time after every package action change. You might have noticed how much time building a view can take if a system is under load or quite some sources are listed in /etc/apt/sources.list*. Package action changes only update the status line on top and the color and first column of the packages whose action changed (either by explicitly selecting an action or by dependency resolution). It does not add packages to a view which is limited to a specific set of packages nor does it update their grouping. (Changing the latter would also make the UI unusuable.) That's one way to update the limiting and grouping. Another one is to press "l<Enter>" which would set a new limited view, but you just keep applying the same limit (which is actually not limit implicitly used in the preview, but is actually applied on top of it, but it triggers a rerendering of the current view.) All correct and as expected after pressing "qg" (or "l<Enter>"). Yes. Yes. More or less yes as the view doesn't already show that package that suddenly is involved due to user interaction in the preview. If you change package actions as late as in the preview of what would be done, you should always regenerated that view to see the complete impact, yes. As mentioned, dynamically adding (or removing) packages from a view requires rebuilding that view, which takes quite a time. And it also removes the focus on which package was interactively selected and closes all opened subtrees. That's nothing you want in a UI if you just mark a package for removal or installation. The same counts e.g. if you skim through the recommended and suggested packages and mark one of the as to be installed: It's additional dependencies aren't added to the current preview either. So while there are clearly unlucky implications, the view generation would need to be rewritten and the view concept redesigned to change that behaviour. That IMHO would be a feature request which comes close to a rewrite of the TUI of aptitude. Which is btw. totally correct as you didn't press _ on it. (Unless you have APT::Get::Purge set to true value. If the later was the case, that might be a separate, minor bug in aptitude.) Regards, Axel
Yes, they had been installed as dependencies of linux-image-amd64 (linux-image-6.10.9-amd64 first, and linux-image-6.10.12-amd64 with some upgrade of linux-image-amd64).