could not mount /dev/mapper/cryptswap1

> i believe the problem is that the following line of:
> #UUID=eb23dadc-8e08-4769-8fc5-0b1216b67e5b none swap sw 0 0

> is not supposed to be commented out,

Why do you think this? What are the contents of your /etc/crypttab? What is the output of 'swapon -s'?

Failing to mount /dev/mapper/cryptswap1 could be a bug in cryptsetup, or it could just mean that your /etc/crypttab isn't set up to actually create this device at boot time.

I would not expect uncommenting the other swap reference in /etc/fstab to have any effect on whether the system waits for /dev/mapper/cryptswap1. It does, however, probably mean that you are now using an unencrypted swap partition, which the installer disabled because this makes encrypted home directories less secure.

I've got the same exact problem, using an encrypted home partition. This didn't happen at all when not using encryption.

Output of 'swapon -s':

Filename Type Size Used Priority
/dev/mapper/cryptswap1 partition 3938300 0 -1

Content of /etc/crypttab:

# <target name> <source device> <key file> <options>
cryptswap1 /dev/sdb1 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
(END)

As near as I can tell, I have no swap partition, because this doesn't seem to be mounting at boot. I will uncomment that line in /etc/fstab pending finding a fix for this.

This is one of those irritating bugs that will effect a new userto Ubuntu's usability of the system. Great job on the overall appearance of this past release, but bugs like this just suck.

So as mentioned earlier, this is only happening when encryption is turned on in the install, i also believe that uncommenting that line only masks the issue, as the message does not appear when you boot up. If more data needs to be collected i will gladly re-install with encryption turned on, and gather whatever you need.
just let me know,
Thanks

@Steve
so i figured i would give it a shot and re-install it, its not something random at all, at least for me. Here is the information you were looking for:

Output of "swapon -s":

Filename Type Size Used Priority
/dev/mapper/cryptswap1 partition 4183036 0 -1

Contents of /etc/crypttab:

# <target name> <source device> <key file> <options>
cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
(END)

I also got this during a fresh install of a netbook (1001ha eeepc) with home directory encryption.

swapon -s says:

Filename Type Size Used Priority

/dev/mapper/cryptswap1 partition 1952764 0 -1

contents of crypttab

# <target name> <source device> <key file> <options>
cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Dave

bugs 798086, 783889 seems to be other instances of this on Natty,

This seems to be reported rather consistently, and is not a case of a misconfigured crypttab: all users reporting this issue show a crypttab that correctly sets up their crypted swap, *and* swapon -s shows that the swap is enabled successfully after boot. But for some reason mountall thinks it hasn't been activated, which means the boot stalls. We should definitely get this fixed.

This also affected my custom encrypted configuration. I see the prompt twice, once for each encrypted volume. I can use the (M)anual option to drop to the busybox shell, manually unlock the volumes with cryptsetup, then exit the shell, after which mountall carries on successfully.

After remaining on Lucid until now I installed Oneiric into empty LVs, one for "/" and another encrypted for "/var". In addition I added the encrypted "/home".

/etc/crypttab has:

Oneiric_var /dev/mapper/Ubuntu-Oneiric_var_encrypted /media/USB/somefile.key luks
home /dev/mapper/Ubuntu-home /media/USB/somefile.key luks

and lvm2 and cryptsetup are installed into the new volumes and have updated the initrd.img.

/etc/fstab has:

proc /proc proc nodev,noexec,nosuid 0 0
/dev/mapper/Ubuntu-Oneiric / ext4 errors=remount-ro 0 1
/dev/mapper/Oneiric_var /var ext4 defaults 0 2
/dev/mapper/Ubuntu-swap none swap sw 0 0
# /boot was on /dev/sda3 during installation
UUID=af296c2f-a6f5-4cdb-b74c-66310f169677 /boot ext3 defaults 0 2
/dev/mapper/Ubuntu-usr_local /usr/local ext3 defaults 0 2
/dev/mapper/home /home ext3 defaults 0 2

The failure is caused by the upstart and cryptsetup scripts trying to match the DEVNAME against /etc/crypttab entries that are in DEVLINKS format. E.g:

DEVNAME=/dev/dm-14
DEVLINKS=/dev/mapper/Ubuntut-Oneiric_var_encrypted /dev/Ubuntu/Oneiric_var_encrypted /dev/block/253:14

Upstart's "/etc/init/cryptdisks-udev.conf" passes the environment variable DEVNAME to crypttab_start_one_disk() in "/lib/cryptsetup/cryptdisks.functions".

Unless "/etc/crypttab" has an entry for "/dev/dm-14" the match will fail. It would be unwise to use /dev/dm-14" in 'crypttab' since the disk-mapper is dynamically allocated and could change.

I've fixed it with a few additional lines that tries to match against any of the DEVLINKS. I'll attach a patch and a debdiff here later once I've fixed some other bugs on that system.

The attached patch can be applied using:

sudo patch -p2 /lib/cryptsetup/cryptdisks.functions 0001-LP874774-Use-DEVLINKS-to-match-crypttab-entries.patch

The attachment "Match crypttab with DEVLINKS" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

On Fri, Nov 11, 2011 at 04:27:16PM -0000, TJ wrote:
> The attached patch can be applied using:

> sudo patch -p2 /lib/cryptsetup/cryptdisks.functions 0001-LP874774-Use-
> DEVLINKS-to-match-crypttab-entries.patch

diff --git a/debian/cryptdisks.functions b/debian/cryptdisks.functions
index 494697f..f0cfedb 100644
--- a/debian/cryptdisks.functions
+++ b/debian/cryptdisks.functions
@@ -641,6 +641,13 @@ crypttab_start_one_disk () {
    src="/dev/disk/by-uuid/${src#UUID=}"
   elif [ "xLABEL=$ID_FS_LABEL_ENC" = "x$src" ]; then
    src="/dev/disk/by-label/${src#LABEL=}"
+ elif [ -n "$DEVLINKS" ]; then
+ for link in $DEVLINKS; do
+ if [ "x$link" != "x$src" ]; then
+ continue
+ fi
+ break
+ done
   elif [ "x$1" != "x$src" ]; then
    continue
   fi

This doesn't have the desired effect when src does not match any of the
devlinks. Note that there is both an inner and an outer loop here, and the
break and continue will only act on the inner loop - so with this patch, for
any ID_FS_USAGE=crypto device at all that has devlinks,
crypttab_start_one_disk() will try to start every device in /etc/crypttab.

Good insight on the cause of the bug, though; I didn't even think of the
fact that the real device name not being /dev/mapper/$name would cause this
problem. Would you be willing to fix up this patch for the above-mentioned
bug? I'm happy to sponsor the fix into the archive.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Hi Steve. Well spotted! I was at the end of a long session when I developed the patch.

I'll rework it and test again.

For those that are interested I tested this under my own control in the following way:

1. Boot the PC to the GRUB menu
2. Edit the boot entry's "linux" line, remove any extraneous parameters such as "recovery", "quiet splash" and replace with "init=/bin/bash"
3. Press F10 to boot with the customised command-line
4. Linux will run a bash terminal instead of the usual upstart init process and therefore upstart will not run, allowing you to control and monitor the process.
5. Create several spare terminals to help you explore using:

 getty -8 -n -l /bin/bash 38500 tty2 &
 getty -8 -n -l /bin/bash 38500 tty3 &
 getty -8 -n -l /bin/bash 38500 tty4 &

You can switch between the terminals using Alt+F1/F2/F3/F4

6. Make the root file-system read/write
mount -o remount <ROOTDEV> / (you will need to replace <ROOTDEV> to match the mount-point of the system's root device )
7. Edit the upstart script using nano:
 /usr/bin/nano /etc/init/cryptdisks.udev.conf

insert the following lines at the very beginning of the "script" block, then save the file (Ctrl+X):

 exec > /tmp/crypt_$(basename $DEVNAME).log 2>&1
 set -x

This will cause the script to create a log file in/tmp/ for each DEVNAME that it is called for.

8. Create a temporary file-system for /tmp/:
 mount -t tmpfs -o size=20m tmpfs /tmp

9. At one of the terminals start the "init" process:
 exec init

10. Switch to another terminal (Alt+F2/F3/F4) and check the /tmp/ directory shows some log files with names like "crypt_dm-14.log
 ls -lstra /tmp/

11. Examine the contents of each log file to identify the device you are debugging using the system pager "less", e.g:
 less /tmp/crypt_dm-14.log

Steve, this is a reworked patch. It makes use of the DASH/BASH 'break N' multi-level break to break from the outer loop.

I've tested it with DASH and BASH and it works with both.

               elif [ -n "$DEVLINKS" ]; then
                        for link in $DEVLINKS; do
                                if [ "x$link" != "x$src" ]; then
                                        continue
                                fi
                                break 2
                        done

I'm still having trouble with this as I'm reading it :) Maybe my brain is just not in shell mode today, but I believe what we need to have happen here is:

 - if $src matches one of the links in $DEVLINKS, we have a match and should mount this device.
 - if $src matches none of the links in $DEVLINKS, and also doesn't match $1, skip this line and look for another match in crypttab.

The current patch appears to have the following wrong properties:
 - if $DEVLINKS is set but the crypttab line matches the device name instead of one of the links, it will not be processed correctly (because we never get a chance to compare $1 and $src)
 - if $src matches none of the links in $DEVLINKS, we'll hit the 'continue' each time through the for loop, so the break will never be hit and we'll (incorrectly) try to process the line
 - if $src *does* match one of the links in $DEVLINKS, we will hit the 'break 2' and *not* process *any* more lines in crypttab.

So I think your patch usually works, but only as a side effect. I'll take a crack at the patch here.

TJ, I've also just noticed that this patch does *not* address the original bug here. Your patch addresses the case where a source device is handled through devmapper (such as an LVM volume), but that is *not* the case in the original report; when the installer sets up crypted swap, the source device is a physical partition, which should already work fine.

This is still worth fixing anyway; please give the attached patch a try.

Steve: as to being unrelated. I matched this bug report to the symptom that mountall stalled and couldn't continue. It was later when I debugged the issue step-by-step to discover the cause that the difference became apparent.

Your patch looks good - although you could drop the use of $found to track detection and use "break 2" which would avoid those extra 4 lines of code.

As to the original cryptswap report, I'll duplicate that configuration here and step through the init scripts to discover the causes (if I can reproduce the failure).

I was unable to reproduce the mountall-swap issue on an already installed system. I'll try again later with a virgin spare notebook.

I'm unable to recreate the mountall-swap issue installing 32-bit Ubuntu 11.10. Options were "Use entire disk, encrypted home". I didn't see an option to choose encrypted swap but after installation there were two encrypted swaps:

/dev/mapper/cryptswap1 = /dev/zram0
/dev/mapper/cryptswap2 = /dev/sda5

with only the latter operational after a completed start-up.

I wonder if this a parallel start-up issue on SMP? The test notebook is UP.

On Wed, Dec 21, 2011 at 10:49:15AM -0000, TJ wrote:
> Your patch looks good - although you could drop the use of $found to
> track detection and use "break 2" which would avoid those extra 4 lines
> of code.

Not at all; 'break 2' has the effect that no other lines from /etc/crypttab
will be processed, which is definitely not what we want.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I've been doing some local testing on the DEVLINKS patches to optimise the iterations. I developed a user script to test the function in a simulated environment. The script and log from my complex LVM/crypt system are contained in the attached archive.

Please see the README in the archive for more details. Here's a summary:

I created the script to compare algorithms to eliminate unnecessary iterations of the "while read ..."
and "for link in $DEVLINKS" loops. These were brought to my attention by Steve Langasek's comments
in Launchpad bug #874774.

The attached log-file demostrates how the current function (with bug-fix modifications by SL)
does several unnecessary iterations of entries in crypttab, and of paths in $DEVLINKS.

Specfically, search for the lines following ">>253:14 = dm-14" in test_crypt.log to compare how the
two versions of the function perform the matching and the unnecessary iterations in the original function
on my complex LVM/crypted system.

This is the current patch as used on my system.

Thanks guys for all your work on Ubuntu!
Is this expected to be fixed in Oneiric, or only in Precise?

Sorry, I accidentally changed the status

Can somebody still simulate this in Precise?
I tried with several setups, and all seem to work fine.

Hello!

I can still simulate this in Precise. I just updated and i think i still experience this bug.
During boot up, i receive the message: "could not mount /dev/mapper/cryptswap1 M for manual S for skip"

Here is some info:

# cat /etc/crypttab
# <target name> <source device> <key file> <options>
cryptswap1 /dev/sda3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,hash=ripemd160,size=256
(EOF)

I just added "hash=ripemd160,size=256", because in output of apt-get i notice, that hash and size should be specified for cryptsetup to work properly

# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda4 during installation
UUID=2916dc57-771e-497d-a759-d6cd80343a09 / ext4 errors=remount-ro 0 1
# /storage was on /dev/sda2 during installation
UUID=4AB49887B49876E3 /storage ntfs defaults,umask=007,gid=46 0 0
# /windows was on /dev/sda1 during installation
UUID=36B0C3A1B0C36649 /windows ntfs defaults,umask=007,gid=46 0 0
# swap was on /dev/sda3 during installation
#UUID=e6f22fea-379b-44f7-a64c-c41b4ca601bc none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0
(EOF)

# cryptsetup status cryptswap1
/dev/mapper/cryptswap1 is active and is in use.
  type: PLAIN
  cipher: aes-cbc-essiv:sha256
  keysize: 256 bits
  device: /dev/sda3
  offset: 0 sectors
  size: 6297480 sectors
  mode: read/write

It seems that swap is encrypted and in use... I think.

I will provide any further usefull information on this bug on request.

Hi!
Thanks for the additional information.

Could you check if the swap is mounted when startup is done (free -m).

I'll try to debug & simulate the issue :)

Here it is:

# free -m
             total used free shared buffers cached
Mem: 2004 1886 117 0 78 905
-/+ buffers/cache: 902 1101
Swap: 3074 51 3023

Oh, just after SECOND reboot issue got away... But now i have

modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.38-11-generic/kernel/drivers/crypto/padlock-sha.ko): No such device

during bootup)) Anyway, swap seems to work fine and encrypted, as all outputs of 'cryptsetup status cryptswap1' and 'free -m' are the same. I found my bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/779912

Hello,

I can still simulate this in Precise.

Info:

cat /etc/crypttab
# <target name> <source device> <key file> <options>
cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda1 during installation
UUID=bb0ce7e2-2c02-4e90-9fc7-c61ad3f7fe22 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
#UUID=03876e10-2abe-4871-bee1-44f1bf8b339a none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

swapon -s
Filename Type Size Used Priority
/dev/mapper/cryptswap1 partition 1046524 968 -1

free -m
             total used free shared buffers cached
Mem: 1001 836 164 0 99 319
-/+ buffers/cache: 418 583
Swap: 1021 0 1021

I updated my Xubuntu Precise beta 1 and cannot boot up. It freezes as everybody explained here, i can log in to recovery mode and see in terminal my encrypted home and my files, but that is so far i can get. I tried to insert a pendrive to backup somethings but /dev/sde as dmesg says, is not in fstab file, so i cannot mount it. Another thing i did is to connect the pc to ethernet and select enable network and did "sudo apt-get install -f, sudo apt-get update", and "upgrade" too, but system won't boot big time. This update broke my system i hope a fix will restore it as soon as possible. My screenshot is attached

Regards,

I figured out to boot enabling the network in recovery mode and updated my system but no fix still. I tried editing fstab "sudo nano /etc/fstab" and uncommented the swap line but system wont boot either, this time the message is not shown. This is a big f**** nasty bug btw.

Is there anyway to get that patch and apply it in my machine in through recovery mode? maybe sudo apt-get with some repo or something? thanks... i don't think i can mount a pendrive and copy stuff... when y try to mount it it says the device is not in fstab...

Regards,

I tried to apply the patches here posted but it gives hunk errors... in line 641 for the patch in #14, line 631 in #22 and some other line in #16...

i always restored the original and even did "sudo apt-get install cryptsetup --reinstall" to re install de pachage that i hope overwrites the original script. Also updated the system...

But my system wont boot up, pleas need help making it boot asap.
btw did i mention that my home is encrypted?

Regards.

I updated my system with apt-get update in recovery mode in the option "enable network" but the PC cannot actually boot by itself in to the desktop. Aftewr pressing Ctrl+C right before it hangs, the last text line starts with "mountall ..... something"

I tried to apply patch described in comment #10 but at first it returned Hunk errors at line @641 and it did not apply the patch. Then I added the --ignore-whitespace parameter and it applied the patch at line #598... this was the output:

Hunk #1 secceeded at 598 with fuzz 2 (offset -43 lines)

But the machine won't boot. I only have 2 partitions. and my home encrypted, /dev/sda1 for / and /dev/sda2 for swap.

I'll replace the .orig script and wait until someone came up with some other idea.

P.S: Was the patch at #10 the correct one to apply?

I tried to apply the first short patch dated 5 dec and it did patched with the --ignore-whitespace, but the machine did not booted. Then i tried to apply the patch dated Dec 22 it could not patch even with the ignore spaces parameter. Then i applied patches dated Dec 20 first and Dec 22 after that and both applied with -43 lines offset i believe. The machine wont boot either and freezes in plymouth splash, but the message shown in my photo is not shown anymore. After pressing Ctrl+C during plymouth y see this error message:

mountall: plymouth command failed

Will i get any change to restore my system? or should i start considering to do formatting and reinstallation without encryption? Please someone help me with this

Regards,

I can also reproduce this bug on a fresh install of precise. mountall is missing the notification that /dev/mapper/cryptswap1 is available, so waits for it; the system seems to only boot all the way for me because the lo interface happens to come up after this and triggers mountall to rescan (/etc/init/mountall-net.conf).

Since the standard crypted swap being offered here is not luks, there is no filesystem metadata on the partition, so /etc/init/cryptdisks-udev.conf will not match this device.

In /var/log/upstart/cryptdisks-enable.log, I see this:

 * cryptswap1 (starting)..
The node /dev/mapper/cryptswap1_unformatted should have been renamed to /dev/mapper/cryptswap1 by udev but old node is still present. Falling back to direct old node removal.
   ...done.

That looks like a smoking gun.

I've tested expanding the race window for this by adding a sleep to the blkid command, and as long as the udevadm settle is there, I can no longer reproduce this issue: mountall sees the swap partition as soon as it becomes available. So I'm reasonably certain the linked branch fixes this.

This bug was fixed in the package cryptsetup - 2:1.4.1-2ubuntu4

---------------
cryptsetup (2:1.4.1-2ubuntu4) precise; urgency=low

  * Our swap creation can trigger udev change events, which means udev may be
    holding the device open at the time we try to call 'dmsetup rename' and
    cause the /subsequent/ events to be missed because of dmsetup creating
    device nodes by hand. So call 'udevadm settle' before 'dmsetup rename',
    to ensure blkid is out of the way first. This should ensure swap
    partitions are found by mountall in a non-racy manner. LP: #874774.
 -- Steve Langasek <email address hidden> Fri, 13 Apr 2012 20:23:21 -0700

Is this really fix released?
I have the same problem in Recovery Mode. When I Press "Network" and then want that the program mounts my partitions it hangs. I press than Ctrl + C. Then I can see that friendly-recovery is hanging with the problem: "could not mount /dev/mapper/cryptswap1 M for manual S for skip" Then the program is killed and the computer starts normally. But what is when i start the recovery Mode because i can't start the PC normally. I can not rescue my data because friendly-recovery hangs on mounting my swap partitions!

Is this the same bug? Or is this a new bug in friendly recovery? Can somebody reproduce this hang in friendly-recovery?

On Sat, Apr 14, 2012 at 10:45:33AM -0000, Benedikt wrote:
> Is this really fix released?

To the best of my knowledge!

> I have the same problem in Recovery Mode.

There is nothing in this bug report which is specific to recovery mode.
You're probably encountering a different bug.

You also don't mention if you're running 12.04 or an earlier release. The
bug in cryptsetup has only been fixed for 12.04.

> When I Press "Network" and then want that the program mounts my partitions
> it hangs. I press than Ctrl + C. Then I can see that friendly-recovery
> is hanging with the problem: "could not mount /dev/mapper/cryptswap1 M for
> manual S for skip" Then the program is killed and the computer starts
> normally.

It appears that friendly-recovery calls 'udevadm trigger' manually instead
of starting the 'udevtrigger' job. As a result, the cryptdisks-enable job,
which is the catch-all that starts random-crypted swap devices, is never
started.

So yes, this is a different bug. Please file a new bug report against
friendly-recovery; feel free to quote this message when filing.

> But what is when i start the recovery Mode because i can't start the PC
> normally. I can not rescue my data because friendly-recovery hangs on
> mounting my swap partitions!

Friendly-recovery also gives options for you to launch an interactive shell
from which to recover the system. You should be able to remount your
filesystem read-write by hand from the shell ('mount -orw,remount /') and
recover from there.

Ideally, you would be able to interact with mountall anyway to tell it to
skip a missing partition, just as you do during a normal boot;
friendly-recovery can probably accomplish this by further manipulating the
plymouth splash.

OK, thanks for your answer! :)

I filed Bug #981792 and quoted your description of the problem.

I had the same problem and as in the above discussion, it happens only when the home folder is encrypted, I have tried with normal installation which doesn,t show any message

I don,t think whether some one would have found some fix for this.....

This bug don't seems to be fixed for me in Precise. Should i reinstall my system to get it working?
Please excuse me if this is not a right place to ask about.

Grosso, please file a new bug report and describe the problem you're experiencing; it's almost certainly not this bug.

Sorry, I'm afraid I'm not experienced enough and maybe I'm missinterpretating my problem. I will ask in a more apropiated place before open a new bug, but please, give me a hint because i can't see where is the difference.
I come to this bug because gparted shows /dev/sda7, where is my swap, as unmounted. The swapon -s output is

/dev/mapper/cryptswap1 partition 4883452 0 -1

In /etc/crypttab I see

cryptswap1 /dev/sda7 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

and in fstab

# swap was on /dev/sda7 during installation
#UUID=5e2afbd9-b8d7-4fc9-93c3-180bc6a78363 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

the blkid output is

/dev/sda5: UUID="88b905be-17ba-4181-ba80-c406502f8a68" TYPE="ext4"
/dev/sda6: UUID="9b1fe7e8-fce4-4169-996a-942120cae381" TYPE="ext4"
/dev/mapper/cryptswap1: UUID="4ca3b417-1385-4f6e-a7ec-4b11804e6e8a" TYPE="swap"

So perhaps my swap is mounted after all and is normal that gparted shows /dev/sda7 as unmounted.

Please excuse me for my bad english and for posting in a fixed bug.
Thank you

On Sat, Jun 23, 2012 at 09:43:31PM -0000, grosso wrote:
> Sorry, I'm afraid I'm not experienced enough and maybe I'm
> missinterpretating my problem. I will ask in a more apropiated place
> before open a new bug, but please, give me a hint because i can't see
> where is the difference.

> I come to this bug because gparted shows /dev/sda7, where is my swap, as
> unmounted.

Yes, that has absolutely nothing to do with this bug report. This bug
report is about a message *at boot time* informing users that the encrypted
swap device could not be mounted.

gparted is correct when it tells you that /dev/sda7 in not mounted. It's
*not* mounted - /dev/mapper/cryptswap1 is mounted, and gparted has no idea
of the mapping between /dev/mapper/cryptswap1 and /dev/sda7.

But this information is available in /sys, so gparted could learn to parse
that. You should file a wishlist bug against gparted for this, if you would
like to see this implemented.

I installed 12.04, fresh installation, and this problem persists.

The boot process doesn't seem to find the encrypted partitions and asks me do skip S or go manual M.

These are the versions I have:

ii cryptmount 4.2.1-1 Management of encrypted file systems
ii cryptsetup 2:1.4.1-2ubuntu4 disk encryption support - startup scripts
ii cryptsetup-bin 2:1.4.1-2ubuntu4 disk encryption support - command line tools

# cat /etc/crypttab | grep -v '^#' | grep -v '^$'
cryptswap /dev/sda5 /dev/urandom swap
encriptado /dev/sda6

# grep -e 'cryptswap' -e 'encriptado' /etc/fstab
/dev/mapper/cryptswap swap swap defaults 0 0
/dev/mapper/encriptado /encriptado ext4 defaults 0 0

I can manually open the encrypted devices with no problem.

I've read in this thread (#38) that one could insert a sleep before a bulkid. I don't know if this is the solution. Where should I place it?
I kindly ask you to check this once again because it worked in 10.04 and now it doesn't.

Luís,

Comment #38 wasn't a workaround, it was a regression test to try to trigger the bug.

The fix for this bug is definitely in 12.04. Please file a separate bug report for your issue, including the /etc/fstab and /etc/crypttab, as well as the exact text of the message you're shown on boot.

I just installed http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current//images/netboot/boot.img.gz

and chose home encryption during the command-line installation. I get the same message "could not mount /dev/mapper/cryptswap1 M for manual S for skip" during boot. The only thing I did is "sudo tasksel install lubuntu-desktop".

Now I read here that it's fixed, but I can't see the solution between all the code.
Can somebody sum up the steps to manually fix this problem?

I'm familiar with sudo and vim and I'm looking for something like.
1. Use "sudo command --options"
2. Open "/etc/file-that-should-be-changed" and change "remove-bug=false" to "remove-bug=true"

It would help me and also the next person who googles this problem.
Thank you!

This error is back in Quantal

Guys, following Steve's suggestion, I've opened another bug, #1061190. Please go there and subscribe to it.

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".