xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable

Bug #1801629 reported by Chris Rainey on 2018-11-05
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
High
Yuan-Chen Cheng
ubiquity (Ubuntu)
Status tracked in Disco
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned
Disco
Undecided
Unassigned
ubuntu-mate-meta (Ubuntu)
Status tracked in Disco
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned
Disco
Undecided
Unassigned
xubuntu-meta (Ubuntu)
Status tracked in Disco
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned
Disco
Undecided
Unassigned

Bug Description

In a clean install of Xubuntu 18.10, if an unsuspecting user runs 'apt autoremove', it will remove 'cryptsetup' and 'lvm2' making the system non-bootable at next restart if an encrypted(LUKS+LVM) root partition was selected during the ubiquity installer wizard:

$ sudo apt update && sudo apt --auto-remove full-upgrade && cat /run/reboo*
<snip...>
The following packages will be REMOVED:
  cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run dmeventd libdevmapper-event1.02.1 liblvm2app2.2 liblvm2cmd2.02 libreadline5 lvm2
<...snip>

This _will_ make the system non-bootable upon restart if LUKS+LVM are active on the root partition. This would, by extension, make any auto-mounted partitions(home, etc.) unavailable after boot as well!

WORKAROUND:

$ sudo apt install cryptsetup lvm2
<snip...>
cryptsetup is already the newest version (2:2.0.4-2ubuntu2).
cryptsetup set to manually installed.
lvm2 is already the newest version (2.02.176-4.1ubuntu3).
lvm2 set to manually installed.
<...snip>

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: xubuntu-core 2.227
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
Uname: Linux 4.18.0-10-generic x86_64
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun Nov 4 18:20:38 2018
InstallationDate: Installed on 2018-11-04 (0 days ago)
InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2)
SourcePackage: xubuntu-meta
UpgradeStatus: No upgrade log present (probably fresh install)

Chris Rainey (ckrzen) wrote :
summary: - xubuntu-core needs to depend on cryptsetup and lvm2 or autoremove will
- make system non-bootable
+ xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove'
+ will make a LUKS-LVM encrypted system non-bootable
summary: xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove'
- will make a LUKS-LVM encrypted system non-bootable
+ will make a LUKS+LVM encrypted system non-bootable
Chris Rainey (ckrzen) on 2018-11-05
summary: xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove'
- will make a LUKS+LVM encrypted system non-bootable
+ will make a LUKS+LVM encrypted root partition non-bootable
description: updated
flabnat (flabnat) wrote :

same for ubuntu mate 18.10

Launchpad Janitor (janitor) wrote :

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

Changed in xubuntu-meta (Ubuntu):
status: New → Confirmed
Changed in ubuntu-mate-meta (Ubuntu):
status: New → Confirmed
Julian Andres Klode (juliank) wrote :

This can be a regression from the minimize-manual work in livecd-rootfs. I'll do some digging shortly.

Julian Andres Klode (juliank) wrote :

Rerunning the minimize manual script in an xubuntu image with some extra tracking I see the following chain causing it to be marked as automatically installed:

1. xubuntu-desktop Recommends indicator-messages
2. indicator-messages Recommends ubiquity-frontend-gtk (due to indicator-renderer Provides)
3. ubiquity-frontend-gtk Depends on ubiquity
4. ubiquity Depends on cryptsetup, Recommends lvm2

We later on remove ubiquity in cleanup, but don't mark any remaining autoremovable stuff manually installed.

tags: added: id-5c37766807dcd14b43d455cd
Julian Andres Klode (juliank) wrote :

I think we should run

apt-get autoremove -s | sed -nr 's#Remv (.*) \[.*#\1#p' | xargs apt-mark manual

after the install finished otherwise, this way get any packages marked as manually installed that would otherwise be subject to autoremoval.

The alternative here would be to run the minimize-manual script on the "install" chroot, and not the "live" chroot. But that requires further integration with live-build.

Changed in ubuntu-mate-meta (Ubuntu Cosmic):
status: New → Incomplete
status: Incomplete → Invalid
Changed in ubuntu-mate-meta (Ubuntu Disco):
status: Confirmed → Invalid
Changed in xubuntu-meta (Ubuntu Cosmic):
status: New → Invalid
Changed in xubuntu-meta (Ubuntu Disco):
status: Confirmed → Invalid
Changed in ubiquity (Ubuntu Disco):
status: New → Triaged
Changed in ubiquity (Ubuntu Cosmic):
status: New → Triaged
Mario Limonciello (superm1) wrote :

Is this expected to not be an issue in bionic as well? I'm hearing similar reports on people who reinstalled from an OEM image.

Changed in ubiquity (Ubuntu Bionic):
status: New → Triaged
Changed in ubuntu-mate-meta (Ubuntu Bionic):
status: New → Invalid
Changed in xubuntu-meta (Ubuntu Bionic):
status: New → Invalid
Mario Limonciello (superm1) wrote :

FYI I tested both generic bionic image and OEM image. Generic bionic image does not suffer this problem. It's only OEM image generated by Canonical OEM infrastructure that suffers it.

Yuan-Chen Cheng (ycheng-twn) wrote :

In generic bionic image (live cd mode), lvm and cryptsetup set mark as manual.
In oem image, it's not mark manual. Plan to mark so.

Changed in oem-priority:
assignee: nobody → Yuan-Chen Cheng (ycheng-twn)
importance: Undecided → High
status: New → Confirmed
Changed in ubiquity (Ubuntu Bionic):
milestone: none → ubuntu-18.04.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints