direct dependencies of ubiquity should not be autoremovable

Bug #1801629 reported by Chris Rainey
78
This bug affects 15 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Fix Released
High
Yuan-Chen Cheng
livecd-rootfs (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Invalid
Undecided
Unassigned
Cosmic
Won't Fix
Undecided
Unassigned
Disco
Fix Released
Undecided
Unassigned
Eoan
Fix Released
Undecided
Unassigned
ubiquity (Ubuntu)
Invalid
High
Unassigned
Bionic
Invalid
Undecided
Unassigned
Cosmic
Won't Fix
Low
Unassigned
Disco
Invalid
High
Unassigned
Eoan
Invalid
High
Unassigned
ubuntu-mate-meta (Ubuntu)
Fix Released
Critical
Martin Wimpress 
Bionic
Invalid
Undecided
Unassigned
Cosmic
Invalid
Undecided
Unassigned
Disco
Invalid
Undecided
Unassigned
Eoan
Fix Released
Critical
Martin Wimpress 
xubuntu-meta (Ubuntu)
Invalid
Undecided
Unassigned
Bionic
Invalid
Undecided
Unassigned
Cosmic
Invalid
Undecided
Unassigned
Disco
Invalid
Undecided
Unassigned
Eoan
Invalid
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)

Related branches

Revision history for this message
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)
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
Revision history for this message
flabnat (flabnat) wrote : Re: xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable

same for ubuntu mate 18.10

Revision history for this message
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
Revision history for this message
Julian Andres Klode (juliank) wrote :

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

Revision history for this message
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
Revision history for this message
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
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
Arseny (aruseni-magiku) wrote :

I have this bug on Xubuntu 18.10.

The following packages were automatically installed and are no longer required:
  cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run
Use 'sudo apt autoremove' to remove them.

Changed in oem-priority:
status: Confirmed → Fix Committed
Revision history for this message
Steve Langasek (vorlon) wrote :

According to Julian, this does not (currently?) affect bionic, so marking invalid. If the "manually installed" minimization work is SRUed to bionic, this will need to be dealt with as part of that work but not before.

Changed in ubiquity (Ubuntu Bionic):
milestone: ubuntu-18.04.2 → none
status: Triaged → Invalid
Changed in ubiquity (Ubuntu Cosmic):
importance: Undecided → Low
Changed in ubiquity (Ubuntu Disco):
importance: Undecided → High
Revision history for this message
Michael Baker (mjb32803) wrote :

I have this bug on Ubuntu Mate 18.10. Repeated install of standard installation with LUKS LVM on HP 14-DF0023CL. After each install, apt autoremove deletes cryptsetup and lvm2 making computer fail to boot on next reboot. Attempted same install on Acer One netboot with exact same result.

Changed in ubiquity (Ubuntu Cosmic):
status: Triaged → Won't Fix
Revision history for this message
Julian Andres Klode (juliank) wrote :
Changed in livecd-rootfs (Ubuntu Disco):
status: New → Fix Committed
Changed in livecd-rootfs (Ubuntu Cosmic):
status: New → Invalid
status: Invalid → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in livecd-rootfs (Ubuntu Bionic):
status: New → Confirmed
Revision history for this message
lumbricus (lumbricus) wrote :

I just did run a "apt autoremove" without being careful enough and can't boot anylonger. After rebooting it just prints:

gave up waiting for suspend/resume device.
...
ALERT! /dev/mapper/xxx does not exist. Dropping to a shell!

Is there an easy way to unbreak a broken system like this one?

Revision history for this message
lumbricus (lumbricus) wrote :

I think I've been successful recovering the installation. Please let me know if this makes sense or if there are any mistakes. People running into this, will be happy to find recovery instructions here.

See also: https://askubuntu.com/a/1120949/27088

# find root partition
sudo fdisk -l

# unencrypt partition
# Note: replace /dev/nvme0n1p3 with your disk
# replace "nvme0n1p3_crypt" with the correct name
# check by running this in chroot:
# $ cat /etc/crypttab | cut -f1 -d " "
# nvme0n1p3_crypt
sudo cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt

# mount root partition
sudo vgscan
sudo vgchange -ay
sudo mount /dev/mapper/xubuntu--vg-root /mnt

# prepare chroot environment
sudo mount /dev/nvme0n1p2 /mnt/boot/
sudo mount -o rbind /dev/ /mnt/dev/
sudo mount -t proc proc /mnt/proc/
sudo mount -t sysfs sys /mnt/sys/

# make dns available in chroot
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf

# enter chroot
sudo chroot /mnt /bin/bash

# re-install missing packages
apt install cryptsetup lvm2

# re-generate (this might be done also by apt in the step before, I'm not sure)
update-initramfs -u -k all

# Leave chroot environment
exit
# Write buffers to disk
sudo sync
# Unmount file systems
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/boot

Changed in livecd-rootfs (Ubuntu Bionic):
status: Confirmed → Invalid
summary: - xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove'
- will make a LUKS+LVM encrypted root partition non-bootable
+ direct dependencies of ubiquity should not be autoremovable
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package livecd-rootfs - 2.566

---------------
livecd-rootfs (2.566) disco; urgency=medium

  [ Julian Andres Klode ]
  * Do not mark direct dependencies of ubiquity as auto installed. This caused
    cryptsetup to remain auto on the installed system (LP: #1801629)

  [ Tobias Koch ]
  * When the magic-proxy script could not find a valid InRelease file for the
    configured timestamp, it would fall back to serving the canonical version
    of it. This meant that builds would succeed, even though snap-shotting the
    repository failed.
    .
    This update makes the script return HTTP 404 when an InRelease by-hash
    link for a given combination of mirror, suite and timestamp cannot be
    found.

 -- Julian Andres Klode <email address hidden> Tue, 26 Feb 2019 08:56:02 +0100

Changed in livecd-rootfs (Ubuntu Disco):
status: Fix Committed → Fix Released
Revision history for this message
Oliver (oliver-uvman) wrote :

This seems to have affected me even though I never ran autoclean. Maybe apt autocleans after I've used it to install things enough times? No idea. Was saved by this answer: https://askubuntu.com/a/1120949/69057

Revision history for this message
Julian Andres Klode (juliank) wrote :

Fix is verified, daily images of xubuntu disco as of today do not produce the issue anymore :)

Changed in oem-priority:
status: Fix Committed → Fix Released
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Julian verified this as not reproducing on disco now, with the livecd-rootfs change. Closing the ubiquity task as invalid.

Changed in ubiquity (Ubuntu Disco):
status: Triaged → Invalid
Revision history for this message
Martin Wimpress  (flexiondotorg) wrote :

This issue is still affecting Ubuntu MATE 19.10 beta. See the following for more detail:

  * https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1841672

Changed in ubuntu-mate-meta (Ubuntu Eoan):
assignee: nobody → Martin Wimpress (flexiondotorg)
importance: Undecided → Critical
status: Invalid → In Progress
Changed in ubuntu-mate-meta (Ubuntu Eoan):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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: #11841672, #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
Revision history for this message
Wolverine (nareshtechs) wrote :

This bug has also affected me on Ubuntu

Revision history for this message
Wolverine (nareshtechs) wrote :

Sorry all. Something happened while I was typing in the comment.

The bug has also affected me on Ubuntu 18.04.3 LTS. I finally fixed it as described in comment #17.

Maybe unrelated but FYI. My installation is using UEFI but I need to keep the bios in legacy mode and then select Ubuntu (UEFI) to boot properly. If I set the BIOS to boot using UEFI directly, the fix still fails for me.

Revision history for this message
Arno Teigseth (arnotixe) wrote :

struck Linux mint 20.4 (focal, right?) - "just" lvm2 was removed though, not cryptsetup.

I definitely did not remove lvm2 by hand but usually run autoremove. Maybe I'll actually read the "these packages will be removed" next time o_O

My setup was encrypted root, encrypted raid5 and none of those of course mounted since lvm2 was no longer a thing. Easily fixed by liveUsb boot, unlock+chroot and apt install lvm2

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers