| Summary: | Discover "Housekeeping" - Wishlist | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | tagwerk19 |
| Component: | PackageKit | Assignee: | Dan Leinir Turthra Jensen <leinir> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | wishlist | CC: | aleixpol, nate, sitter |
| Priority: | NOR | ||
| Version First Reported In: | 5.20.5 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
I have noticed this too. Might be due to the system's own policies, how PackageKit interprets them, or how Discover is calling Packagekit. (In reply to tagwerk19 from comment #0) > The number of initrd files also grows and, from the modification dates, > they may all need to be rebuilt on a kernel update. In that case the > update takes markedly longer (Discover waits at 99%) The rebuild of the initrd* files doesn't happen each time; noticed it when updating linux-firmware The archives cache is a cache see `man apt.conf` The installed kernel topic is tricky though. The apt in ubuntu 22.04 will eventually fix that [1] with a new option that will be on for packagekit by default, the apt in 20.04 doesn't have that feature. Apt currently only has a sledge hammer version [2] which is technically accessible by setting autoremove on remove transactions (which discover does not do). That would, as far as I understand the code, remove all dangling packages with aptcc, albeit only when removing something not when upgrading. So it'd only be somewhat helpful anyway and I'm not quite sure it's entirely safe to use - the kernel use case is fine there are guards in place, but everything else might get nuked. In conclusion I'm leaning towards closing this as an upstream bug and its been fixed upstream already but won't arrive in neon before 2022. Somewhat relatedly I do already have plans to add space monitoring for /boot to prevent the user from running out of space for kernel updates without warning. [1] https://salsa.debian.org/apt-team/apt/-/commit/944baec85a7496c1595242a31f6b1b37530451a5 [2] https://github.com/hughsie/PackageKit/issues/201 Well if there's nothing Discover can do, there's nothing Discover can do. :) We could close this as UPSTREAM or else move it to Neon for you folks to implement some kind of interim workaround I suppose. Your choice. I don't really see an opportunity for a neon specific workaround. The plan I have for /boot space monitoring in plasma would prevent the most pressing issue of suddenly running out of disk space for new kernel updates. For the general fact that the space footprint of the system keeps growing I'm sure we can wait another year after having lived with the situation for 5 years already ^^
In the meantime users can run
> sudo apt-get --purge autoremove
every once in a while to review the list of dangling packages and have them purged from the system.
Closing as upstream bug.
I suppose the 'dividing line' is whether there are available options in pkcon or not. I don't see anything that might wrap an "apt-get clean". I do see a "pkcon --autoremove" option (is it "live"? I've not managed to get it to do anything). With an 'apt autoremove', I see kernels 5.4.0-42 and before cleaned up With an 'apt-get clean' I've seen about 6 GB tidied from /var/cache. For small VM's (my particular use case), that's a good proportion 8-/ (In reply to tagwerk19 from comment #6) > I suppose the 'dividing line' is whether there are available options in > pkcon or not. > > I don't see anything that might wrap an "apt-get clean". > > I do see a "pkcon --autoremove" option (is it "live"? I've not managed to > get it to do anything). With an 'apt autoremove', I see kernels 5.4.0-42 and > before cleaned up --autremove is not a command you'd use in combination with a command. `pkcon --autoremove remove kwrite`. |
SUMMARY: System Updates with Discover seem to leave cached installation files and older kernel versions on disc (/var/cache/apt/archives, /boot, /usr/lib/modules) Maybe it is expected that people know that they need to watch for and clean up "the debris". However some sanity checks within Discover would help to give a heads up about "eaten up" disc space or, maybe, include an option to tidy up old files within Discover. STEPS TO REPRODUCE: Install a Neon system, install filelight (because it is a useful thing to have), wait and regularly install updates for a few months. Keep watch on disc usage with filelight OBSERVED RESULTS The /var/cache/apt/archives folder steadily grows. The number of kernels grow, as can be seen in /boot (as is referred to in Bug 430296) The number of kernel modules directories grow with each kernel update, each of which can take 250 Mbyte. The number of initrd files also grows and, from the modification dates, they may all need to be rebuilt on a kernel update. In that case the update takes markedly longer (Discover waits at 99%) EXPECTED RESULTS Would expect discover to keep the the last three kernels and files and delete the older ones (with an option to keep a "preferred number"). Would expect a warning if the /var/cache/apt/archives folder grows beyond a certain threshold and/or to clean-out old downloads. SOFTWARE/OS VERSIONS Neon Testing Discover : 5.20.5 Plasma : 5.20.5 Frameworks : 5.79.0 Qt : 5.15.2 ADDITIONAL INFORMATION The behaviour seems io be distro specific, Fedora KDE seems to cope. There is also the possibility that the behaviour I'm seeing is the result of something I've done or installed - and it all works perfectly for other people 8-/