could not mount /dev/mapper/cryptswap1 M for manual S for skip

[David Nemeskey]

I get the message in the bug summary during the boot process. The boot takes quite a long time and also, the Resources tab in the Gnome System Monitor reports the swap is not available.

I am on 12.04, and during installation, I selected the "encrypted home" option. Though it is a fresh install, I left my /home partition intact, and it dates back to ... I don't even know, maybe 10.04? At first I installed Kubuntu, but since then I have changed to Unity and I have uninstalled the Kubuntu desktop.

I am aware of bug #874774, but I felt the need to open a new bug report, since even though the fix has supposedly already been released for that one, I still experience this problem.

[Steve Langasek (vorlon)]

Thanks. Filing a separate bug report is definitely the right thing to do.

Please attach the files /etc/fstab and /etc/crypttab from the affected system.

[NoOp (glgxg)]

I get the message on two systems. However, once booted swap is working for me:

$ free
             total used free shared buffers cached
Mem: 3096960 2840544 256416 0 167080 1669752
-/+ buffers/cache: 1003712 2093248
Swap: 3069948 40 3069908

$ sudo fdisk -l
   Device Boot Start End Blocks Id System
/dev/sdb1 * 63 392275169 196137553+ 83 Linux
/dev/sdb2 392275170 398283479 3004155 5 Extended
/dev/sdb5 392275233 398283479 3004123+ 82 Linux swap / Solaris

Disk /dev/mapper/cryptswap1: 3143 MB, 3143630848 bytes
255 heads, 63 sectors/track, 382 cylinders, total 6139904 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x817842f0

Disk /dev/mapper/cryptswap1 doesn't contain a valid partition table

From my fstab:
# swap was on /dev/sda2 during installation
#UUID=296a385c-7276-4d94-a83f-057bcc3ff4b7 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

From dmesg:
$ dmesg | grep swap
[ 40.590433] Adding 3069948k swap on /dev/mapper/cryptswap1. Priority:-1 extents:1 across:3069948k

[Launchpad Janitor (janitor)]

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

[David Nemeskey (nemeskeyd)]

I would like to inquire about the status of this bug. It was confirmed over a month ago, but nobody has been assigned to it, it hasn't even been triaged.

I have experienced at least one crash because of the lack of swap.

[Steve Langasek (vorlon)]

On Mon, Nov 05, 2012 at 07:08:22PM -0000, David Nemeskey wrote:
> I would like to inquire about the status of this bug. It was confirmed
> over a month ago, but nobody has been assigned to it, it hasn't even
> been triaged.

"confirmed" does not mean a developer is able to reproduce it. We currently
have no explanation for this bug - so it's not triaged.

[David Nemeskey (nemeskeyd)]

Steve: you could always ask for more information. I would gladly help in (most) any way: I could upload log files, install versions of packages that gather debugging data, etc.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

Hello,

On Quantal, I've been trying to get rid of this message on my system when using LUKS (passphrase-protected) encrypted LVM partitions.

Looking at the source code of "mountall.c", it appears the "Continue to wait [...] S to skip or M for recovery" (warning) message is triggered by the (recurrent) "boredom" (hardcoded) 3-second timeout. When using passphrase, there are good chances that mountall will get "bored" (thus the message). Could it be that this 3-seconds timeout is also reached in this (bug) case?

In the end, the partition gets mounted and the boot process continues.

I have found no "logic" in the mountall source code that allows it to detect cryptsetup-ped resources and be a little more "patient".
I was wondering whether a (fstab) "quiet" option may be useful to "silence" those "boredom" messages in mountall. But then, it might not be such a good idea to remove the "M for recovery" option in case something is really wrong with the resource. But further on, the M/S keypress will most likely not reach mountall when plymouth (or the console) is waiting for a passphrase (cf. the crypsetup/askpass script).
Maybe a "bepatient" (fstab) option would be more appropriate. If mountall gets "bored" on a mountpoint which has that option, we would discard the initial "boredom" message and change the "boredom" timeout to something bigger (and then show the "boredom" message only after that longer delay).
PS: I also have found no code matching the documented "--quiet" option of mountall.

What do you think? (I'll send a patch if you deem the proposed option(s) acceptable)

Cédric

[Steve Langasek (vorlon)]

> Could it be that this 3-seconds timeout is also reached in this (bug) case?

I don't believe so. In the cases in question, the swap partition is crypted with a random key, so is not waiting for a passphrase; I know of no reason this should take three seconds to set up - bearing in mind that this must not only take 3 seconds for the crypted filesystem device to be created, it must take 3 seconds /after mountall finishes processing all other filesystems/. I think it's more likely that we have a udev race of some kind here.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

> > Could it be that this 3-seconds timeout is also reached in this (bug) case?

> I don't believe so.

Thanks for your answer. I filed a separate bug addressing the passphrase/boredom issue specifically: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1104156

[Mark Sweeney (qazsedcrvtgbyn)]

I managed to manually fixed this by adding the UUID of the partion to fstab, rather than using the file path.

[Steve Langasek (vorlon)]

On Mon, Jun 17, 2013 at 09:51:42PM -0000, Mark Sweeney wrote:
> I managed to manually fixed this by adding the UUID of the partion to
> fstab, rather than using the file path.

This is not a correct fix, however, as it introduces a race condition since
the UUID will be visible over udev before the path has settled. So you can
get boot failures with this caused by the device appearing, and then moving
to a different name before mountall has a chance to act.

[Mark Sweeney (qazsedcrvtgbyn)]

You should comment out the '/dev/mapper/cryptswap1 none swap sw 0 0' line, which would prevent that issue.

[skorasaurus (skoraw)]

Still experiencing on ubuntu 12.04, 64bit as well.

Attaching my fstab and my /etc/crypttab

[Hendrik Schrieber (hennekn)]

This is still present in 12.04.3. I did a completely fresh installation on two laptops without keeping the previous /home directories and I am experiencing this issue on both of them.

[Kevin Herrera (fenmn)]

Not sure if timing is anything, but I haven't been able to boot after doing one of the updates this last week.

Prior to that I would simply see the prompt to wait for the swap partition to be available, which would eventually just go away and then boot into my desktop. After the most recent update, I cannot boot to desktop anymore, even after creating the swap partition.

The prompt to wait for the swap appears to lock up the system too. If I hit <Escape> earlier in the boot process before the swap wait prompt, it will eventually drop me into TTY1 and I can log in through the shell. Switching to TTY7 and I can see that the boot up is hung.