CryptSetup packages should not be removed by `apt-get autoremove` on system installed with encryption and LVM

Bug #1841672 reported by Norbert on 2019-08-27
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
livecd-rootfs (Ubuntu)
ubiquity (Ubuntu)
ubuntu-mate-meta (Ubuntu)
Martin Wimpress
Martin Wimpress

Bug Description

Steps to reproduce:
1. Install Ubuntu 19.10 MATE with Encryption and LVM
2. Ensure that it boots after install
3. Run `sudo apt autoremove`

Expected results:
* there are no packages to remove

Actual results:
* it tries to remove cryptsetup:

$ sudo apt autoremove
[sudo] password for mate:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run
0 upgraded, 0 newly installed, 4 to remove and 23 not upgraded.
After this operation, 1 178 kB disk space will be freed.
Do you want to continue? [Y/n]

and this will lead on un-bootable encrypted system.
This is very unexpected and dangerous.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: cryptsetup 2:2.2.0-2ubuntu1
ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4
Uname: Linux 5.2.0-10-generic x86_64
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
CurrentDesktop: MATE
Date: Tue Aug 27 23:55:09 2019
InstallationDate: Installed on 2019-08-27 (0 days ago)
InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Alpha amd64 (20190827)
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-5.2.0-10-generic root=/dev/mapper/vgubuntu--mate-root ro quiet splash
crypttab: sda5_crypt UUID=784fac4b-d7a4-4e62-b57e-7ce01e8b0160 none luks,discard

Related branches

Norbert (nrbrtx) wrote :
description: updated
Norbert (nrbrtx) wrote :

This is a screenshot after running `apt-get autoremove` showing messages

    Volume group "vgubuntu-mate" not found.
    Cannot process volume group vgubuntu-mate

so the system is un-bootable and encrypted.

Launchpad Janitor (janitor) wrote :

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

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Changed in ubiquity (Ubuntu):
status: New → Confirmed
Changed in ubuntu-mate-meta (Ubuntu):
status: New → Confirmed
FranksMCB (franksmcb) wrote :

Confirm issue exists on bare metal as well.

Installed on laptop and followed exact commands as above and upon reboot booted into busybox and not able to access filesystem.

Steve Langasek (vorlon) wrote :

Not a bug in cryptsetup itself, the autoremovability sits at a higher layer.

Changed in cryptsetup (Ubuntu):
status: Confirmed → Invalid
tags: added: rls-ee-incoming
Julian Andres Klode (juliank) wrote :

Let's add a livecd-rootfs task, as livecd-rootfs marks it as automatic.

Changed in livecd-rootfs (Ubuntu):
status: New → Triaged
tags: removed: rls-ee-incoming
Norbert (nrbrtx) wrote :

The latest Ubuntu MATE 20190830 ISO is affected.

tags: added: id-5d67fa92e3efdf15acdae69d
FranksMCB (franksmcb) wrote :

CryptSetup issue remains on the 20190917

Norbert (nrbrtx) wrote :

CryptSetup issue remains on the 20190921 ISO

Changed in ubuntu-mate-meta (Ubuntu Eoan):
status: Confirmed → In Progress
assignee: nobody → Martin Wimpress (flexiondotorg)
Changed in ubuntu-mate-meta (Ubuntu Eoan):
status: In Progress → Fix Committed

This bug was fixed in the package ubuntu-mate-meta - 1.253

ubuntu-mate-meta (1.253) eoan; urgency=medium

  * Refreshed dependencies
  * Added cryptsetup to core, desktop (LP: #1841672, #1801629)
  * Added libnotify-bin to core-recommends, desktop-recommends

 -- Martin Wimpress <email address hidden> Wed, 25 Sep 2019 00:47:17 +0100

Changed in ubuntu-mate-meta (Ubuntu Eoan):
status: Fix Committed → Fix Released
Changed in livecd-rootfs (Ubuntu Eoan):
status: Triaged → Invalid

> Let's add a livecd-rootfs task, as livecd-rootfs marks it as automatic.

But that's fine though, it's the installer that should mark the required if they are in fact being used by the particular install configuration the user selects.

That said, it does seem attempts have been made to fix it in livecd-rootfs before. I wrote this but I'm not sure about landing this in the space between now and release unless there are flavours that are still affected.

We should fix this properly (i.e. by having ubiquity itself mark cryptsetup as manual) in the next cycle though.

I downloaded the squashfses for all the flavours and none of them are affected by this bug (either cryptsetup is not marked automatically installed or a metapackage depends on it and will keep it installed) so I don't think this is super critical for release.

Following a hint from Adam, I propose this change which should fix the bug properly (not tested though).

Julian Andres Klode (juliank) wrote :

The correct fix in livecd-rootfs would be to run the minimizing script on the install layer, rather than the live layer which includes ubiquity.

The livecd-rootfs change above is too conservative, it also marks stuff manual that another metapackage depends upon.

The ubiquity change might work, but not sure.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 19.10.16

ubiquity (19.10.16) eoan; urgency=medium

  [ Iain Lane ]
  * Drop zfs-0.8-support.patch. We're goind to do this via the main
    grub-installer package in the archive instead.
  * Handle ZFS option not being implemented on KDE frontend
    (LP: #1847228)
  * Automatic update of included source packages: grub-installer
    1.128ubuntu14. (LP: #1847211)

  [ Michael Hudson-Doyle ]
  * ubiquity/ mark any already-installed packages
    as manually installed. (LP: #1841672)

 -- Iain Lane <email address hidden> Tue, 08 Oct 2019 17:16:13 +0100

Changed in ubiquity (Ubuntu Eoan):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers