After upgrade to 18.10 boot fails on waiting for encrypted source device

Bug #1802617 reported by Donald Pellegrino
94
This bug affects 19 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

After upgrading from 18.04.1 LTS to 18.10, all reboots of the system give a boot screen with the error:

"cryptsetup: Waiting for encrypted source device /swapfile..."

After a minute or so, the graphical boot screen with that message is replaced with a console screen reading:

"ALERT! encrypted source device /swapfile does not exist, can't unlock cryptswap1.
Check cryptopts=source= bootarg: cat /proc/cmdline
or missing modules, devices: cat /proc/modules; ls /dev

Dropping to a shell

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) _"

Typing exit at the initramfs prompt gets the boot to continue. The boot continues to a working system and graphical login.

The system was configured in 18.04.1 LTS to have encrypted home directories and no swap file.

It looks like the /etc/fstab got a new swapfile line somewhere during the upgrade process. However, commenting that out and rebooting does not affect this issue.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: ubuntu-release-upgrader-core 1:18.10.11.1
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
CrashDB: ubuntu
CurrentDesktop: GNOME
Date: Fri Nov 9 20:22:09 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-08-12 (454 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubuntu-release-upgrader
Symptom: dist-upgrade
UpgradeStatus: Upgraded to cosmic on 2018-11-09 (0 days ago)
VarLogDistupgradeTermlog:

Revision history for this message
Donald Pellegrino (donald-a-pellegrino) wrote :
Revision history for this message
Donald Pellegrino (donald-a-pellegrino) wrote :
Revision history for this message
Donald Pellegrino (donald-a-pellegrino) wrote :
tags: added: bionic2cosmic
tags: added: third-party-packages
Revision history for this message
Donald Pellegrino (donald-a-pellegrino) wrote :

Candidate Work-around:

For the case of disabling swap, I was able to eliminate the boot-time error with the following actions:

Remove swap line from /etc/fstab
Remove swap line from /etc/crypttab
Remove /swapfile
apt purge cryptsetup
apt autoremove (clean up cryptsetup dependencies)

The updates to /etc/fstab and /etc/crypttab were not enough to eliminate the error message at boot. It seems cryptsetup was still doing something in the boot sequence that caused it to try and create an encrypted swap file. Purging the cryptsetup package was necessary to eliminate the error message. Therefore, this issue may be relevant to both the Ubuntu upgrade process and the cryptsetup package.

Revision history for this message
Brian Murray (brian-murray) wrote :

The messages from aptermlog seem relevant:

update-initramfs: Generating /boot/initrd.img-4.15.0-38-generic
cryptsetup: WARNING: Option 'size' missing in crypttab for plain dm-crypt
    mapping cryptswap1. Please read /usr/share/doc/cryptsetup/README.initramfs and
    add the correct 'size' option to your crypttab(5).
cryptsetup: ERROR: Couldn't resolve device /swapfile
cryptsetup: WARNING: Resume target cryptswap1 uses a key file
update-initramfs: Generating /boot/initrd.img-4.15.0-36-generic
cryptsetup: WARNING: Option 'size' missing in crypttab for plain dm-crypt
    mapping cryptswap1. Please read /usr/share/doc/cryptsetup/README.initramfs and
    add the correct 'size' option to your crypttab(5).
cryptsetup: ERROR: Couldn't resolve device /swapfile
cryptsetup: WARNING: Resume target cryptswap1 uses a key file

affects: ubuntu-release-upgrader (Ubuntu) → cryptsetup (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Revision history for this message
Jakub Frajt (jakubfrajt) wrote :

I am using a clean installation of Ubuntu 18.10. I have the same problem. With a kernel 4.18.0-10.11 it worked for me when I added option size to crypttab. After an update of the kernel to 4.18.0-11.12 the system gives me the same error: "cryptsetup: Waiting for encrypted source device /swapfile..."

Revision history for this message
Hicham Ben (maghrebi-h) wrote :

Used a clean instal for Ubuntu 18.10 without swap file.
After kernel update I get stuck in the "cryptsetup: Waiting for encrypted source device /swapfile..."

Revision history for this message
Que (righteo347) wrote :

Not sure about the proposed workaround, because I don't know what would happen to the encrypted /home when we purge cryptsetup. Instead, I've done the following sequence:

Remove swap line from /etc/fstab
Remove swap line from /etc/crypttab
sudo update-initramfs -u
sudo update-grub

(The answer that I've taken the last 2 commands from: https://askubuntu.com/a/1009647 - might be helpful for someone).

Revision history for this message
AJ (moon.meister) wrote :

For those looking to solve this problem please note: removing the swap line from /etc/fstab and /etc/crypttab will fix the problem, but it'll also disable swap.

Instead of removing the lines as #9 suggests, simply comment them out. Once you've successfully rebooted, un-comment the lines, update initramfs and grub, and reboot a second time.

This fixed the problem for me. I also added size=256 to my crypttab hoping it permanently fixes this problem.

Revision history for this message
Joseph Borg (joeborg) wrote :

I've also hit this issue. I go round it by loading up a 18.04 Live USB in live mode. I then mounted my HDD onto the live OS (I only encrypted my home folder, so wasn't an issue). I then cded into the mount directory and ran `chroot ./`. Then added `size=256` to the end of the /swapfile line in /etc/crypttab and ran update-initramfs -u (hence the chroot).

Revision history for this message
Joseph Borg (joeborg) wrote :

FYI to anyone who's going from 19.04 to 19.10, you need to remove the `size=256` part in /etc/crypttab or this issue comes back :)

Revision history for this message
Joseph Borg (joeborg) wrote :

^ ignore that, it will further break cryptsetup. the fix was that same as comment #11, except using a 19.10 recovery instead. This will get you back into your system, but it will re-break every time the kernel is updated.

Revision history for this message
Joseph Borg (joeborg) wrote :

update-initramfs: Generating /boot/initrd.img-5.3.0-18-generic
cryptsetup: ERROR: Couldn't resolve device /swapfile
cryptsetup: WARNING: Resume target cryptswap1 uses a key file

Revision history for this message
Joseph Borg (joeborg) wrote :

Sorry for the spam, this is how to fix this (note it will mean your swapfile isn't encrypted anymore and I'm not sure how much of a security risk that poses).

After you've run `do-release-upgrade -d`:

1) sudo swapoff -a
2) sudo cryptsetup remove cryptswap1
3) Edit `/etc/fstab`, remove the line mentioning cryptswap1
4) Edit `/etc/crypttab `, remove the line mentioning cryptswap1
5) sudo update-initramfs -u
6) sudo update-grub
7) Reboot

tags: added: disco eoan
removed: wayland-session
Revision history for this message
littlelion (the-littlelion) wrote :

I've changed following tags:
removed 'wayland-session' - no connection to a display server, because the boot procedure fails, before any display manager is loaded (x or wayland) - FYI I always used X.

added 'disco' and 'eoan' - actually I'm affected of this bug too since a fresh install of 18.10. After upgrading to 19.04 and later on to 19.10 the bug is still present.

It's just a pity to repair the cryptswap each times after an update touched the initramfs. For error messages see comment #14

Revision history for this message
Neven Luetic (8-neven) wrote :

First, besides the active swapfile, that caused the trouble, I found an additional uncommented line in my fstab, referencing /dev/mapper/yoga--vg-swap_1. Whether this was used before or is just a relict I cannot tell.

So I went with /dev/mapper/cryptswap1, which was active; also checked that the device really exists in /dev/mapper.

To not lose encrypted swap, I followed the advice from #10:
* uncommented swap in /etc/fstab and /etc/crypttab
* rebooted
* restored the uncommented lines
* update-initramfs -c
* update-grub

After this I could reboot without issues.

Revision history for this message
Michael De Marco (micydem) wrote :

I got the same issue after upgrading from 18.04 to 20.04. I followed the steps from #11 and then reversed them to fix the issue and re-enable swap encryption

1) sudo swapoff -a
2) sudo cryptsetup remove cryptswap1
3) edit `/etc/fstab`, comment the line mentioning cryptswap1
4) edit `/etc/crypttab `, comment the line mentioning cryptswap1
5) sudo update-initramfs -u
6) sudo update-grub
7) reboot
8) edit `/etc/fstab`, uncomment the line mentioning cryptswap1
9) edit `/etc/crypttab `, uncomment the line mentioning cryptswap1
10) sudo update-initramfs -u
11) sudo update-grub

checking the status of the swap

$ sudo cryptsetup status /dev/mapper/cryptswap1
/dev/mapper/cryptswap1 is active and is in use.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.