Fresh install of kinetic-preinstalled-desktop-arm64+raspi has packages to autoremove

[Brian Murray]

Immediately after installing hirsute-preinstalled-desktop-arm64+raspi on a Raspberry Pi I noticed that there were packages available for autoremoval.

bdmurray@bdmurray-desktop:~$ sudo apt autoremove
[sudo] password for bdmurray:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  cryptsetup-bin dctrl-tools dmeventd dmraid dpkg-repack efibootmgr gir1.2-timezonemap-1.0 gir1.2-xkl-1.0 grub-common grub-efi-arm64
  grub-efi-arm64-bin grub-efi-arm64-signed grub2-common kpartx kpartx-boot libdebian-installer4 libdevmapper-event1.02.1
  libdmraid1.0.0.rc16 liblvm2cmd2.03 libtimezonemap-data libtimezonemap1 lvm2 os-prober python3-icu python3-pam rdate
  thin-provisioning-tools
0 upgraded, 0 newly installed, 27 to remove and 0 not upgraded.
After this operation, 45.5 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

It seems to me the installation process should run an autoremove at the end.

bdmurray@bdmurray-desktop:~$ cat /var/log/installer/version
ubiquity 21.04.19

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1925265

[Steve Langasek (vorlon)]

This bug has been open now and listed in the release notes for 3 releases, including the latest LTS, which is far from ideal. Has anyone reproduced it with a current release? If this is a preinstalled image, why is this reported against ubiquity, which is the desktop installer?

I don't have a raspi to test on, but if I mount the jammy image and chroot into it (without booting) I see:

# apt autoremove --purge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
#

[Steve Langasek (vorlon)]

ok, figured this out a bit more. oem-config is installed (because you need a first-boot configurator), which is built from ubiquity source. oem-config-firstboot runs:
                apt-get -y purge ubiquity >>/var/log/oem-config.log 2>&1

But does not do an apt autoremove --purge afterwards. So the code needs changed to do this.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sam Lane (samlane00)]

When creating the Ubuntu Budgie Pi image, we ran into this same issue. The packages are removed through /usr/sbin/oem-config-remove-gtk but leave behind these same packages. If we mount and chroot into the image, and modify oem-config-remove-gtk and change:

    def _on_transaction(trans):
        apt_dialog = AptProgressDialog(trans)
        ...

to:

    def _on_transaction(trans):
        trans.set_remove_obsoleted_depends(remove_obsoleted_depends=True)
        apt_dialog = AptProgressDialog(trans)

this seems to "fix" the issue. After setup, there are no packages to autoremove. I have tested this not only on our Budgie Kinetic Pi image, but also on the Ubuntu Kinetic RasPi Preinstalled Desktop image.

[Julian Andres Klode (juliank)]

That seems correct, fsvo correct. Like if everything else is correctly working, this works correctly. But if something else fails to be marked manually it gets weird obviously. So it's not bug resistant, but not much we can do better without having `apt history undo` right now

I think there's probably a nicer place to put this in, where trans is created.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 23.04.8

---------------
ubiquity (23.04.8) lunar; urgency=medium

  * Whenever removing packages, use apt-get autoremove --purge instead of
    apt-get purge so that no-longer-used dependencies are removed together
    with the package in question, and we do not leave behind any packages
    that will be reported as autoremovable later. LP: #1925265.

 -- Steve Langasek <email address hidden> Fri, 14 Apr 2023 11:35:46 -0700

[Dave Jones (waveform)]

Sorry, still appears to be an issue on the raspi preinstalled desktop images (confirmed that ubiquity 23.04.8 was used in their production in the manifest). This was the state immediately after installation:

dave@miss-piggy:~$ sudo apt autoremove
[sudo] password for dave:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED
  dctrl-tools dmeventd dmraid dpkg-repack efibootmgr gir1.2-nma-1.0
  gir1.2-timezonemap-1.0 gir1.2-xkl-1.0 grub-common grub-efi-arm64
  grub-efi-arm64-bin grub-efi-arm64-signed grub2-common kpartx kpartx-boot
  libdebian-installer4 libdevmapper-event1.02.1 libdmraid1.0.0.rc16
  libdpkg-perl libfile-fcntllock-perl liblvm2cmd2.03 libtimezonemap-data
  libtimezonemap1 lvm2 os-prober python3-gi-cairo python3-icu python3-pam
  rdate thin-provisioning-tools tzdata-legacy
0 to upgrade, 0 to newly install, 31 to remove and 0 not to upgrade.
After this operation, 56.4 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

[Steve Langasek (vorlon)]

The remaining packages marked for removal result from oem-config-remove-gtk, which doesn't simply call apt-get purge - it uses aptdaemon.

And aptdaemon looks to me like it's supposed to remove "obsoleted dependencies" (equivalent of apt-get autoremove) via worker.aptworker.AptWorker.commit_packages -> worker.aptworker.AptWorker._check_obsoleted_dependencies. So I think this is now actually an aptdaemon bug?

[Steve Langasek (vorlon)]

ah - no, there's a property we need to set on the client side to "remove obsoleted depends".