ecryptfs-setup-swap hints after reboot
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| eCryptfs |
Undecided
|
Unassigned | |||
| ecryptfs-utils (Ubuntu) |
High
|
Unassigned | |||
Bug Description
After changing the the script
* /usr/bin/
* from old version with:
*****
# Add crypttab entry
echo "cryptswap$i $swap /dev/urandom swap,cipher=
*****
* into latest version with:
*****
# Add crypttab entry
echo "cryptswap$i UUID=$uuid /dev/urandom swap,cipher=
*****
the function is no more usable! See also https:/
After some reboots in a fresh installed Ubuntu as well other derivates, the command "swapon -s" shows no swap-device available either connected. Only a new, manually setup solves the problem by typing in a terminal (device may be i.e. /dev/sdb3):
sudo -s
umount /dev/sdb3
mkswap /dev/sdb3 # copy UUID shown into next cmdline
echo "RESUME=
sudo echo "cryptswap1 /dev/sdb3 /dev/urandom swap,cipher=
update-initramfs -u
exit
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ecryptfs-utils 104-0ubuntu1
ProcVersionSign
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
Date: Sat Apr 19 20:37:12 2014
ProcEnviron:
LANGUAGE=de:en
TERM=xterm
PATH=(custom, no user)
LANG=de_DE.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: Upgraded to trusty on 2014-04-08 (11 days ago)
| syscon-hh (syscon-kono) wrote : | #1 |
| description: | updated |
| description: | updated |
| syscon-hh (syscon-kono) wrote : | #3 |
A possible workaround inside the script "/usr/bin/
*******
# Add crypttab entry
echo "cryptswap$i UUID=$uuid /dev/urandom swap,offset=
*******
Please test the supplement "offset=8" as a sufficient space to avoid the UUID will be overwritten.
Alternativily it should be tested to use the Option "skip" instead.
| tlu (thomas-ludwig-gmx) wrote : | #4 |
I had the same problem after installing Kubuntu 14.04 64bit. During the installation process I mounted an existing home partition encrypted with ecryptfs. Result: The swap partition was not available/mounted. After manually implementing syscon-hh's solution in the first post, all is well.
| tlu (thomas-ludwig-gmx) wrote : | #5 |
I should have added that sudo blkid reported a different UUID for the swap partition than the one used in /etc/crypttab. Replacing that one with the UUID reported by blkid did not solve the problem.
| Foehn (foehn-2) wrote : | #6 |
This bug also affected me with Ubuntu 14.04 and encrypted home-directory. The swap partition existed but was not mounted as a crypted swap.
My workaround:
Changing /etc/crypttab in (e.g.):
#cryptswap1 UUID=a81fe18e-
cryptswap1 /dev/sda6 /dev/urandom swap,cipher=
was successfull.
"free" gives:
Gesamt Belegt Frei Gemeinsam Puffer Cached
Speicher: 7966568 1840508 6126060 180132 84148 814660
-/+ Puffer/Cache: 941700 7024868
Auslagerungsdatei: 15624188 0 15624188
and suspend to disk is possible.
| Albert Pool (albertpool) wrote : | #7 |
On Trusty, blkid is also unable to read the UUID of a swap partition of a Raring system, while that swap is working fine on Raring.
I will check tomorrow what blkid does on Raring.
| Albert Pool (albertpool) wrote : | #8 |
@syscon-hh: I hope to be able to test your 'skip' option tomorrow.
| Albert Pool (albertpool) wrote : | #9 |
Turns out Raring does not use UUID's here but /dev/sdXY names. That explains why it used to work (and silently the mint 16 system on sdb here has been using the swap of the hot-pluggable sda drive with trusty-based mint 17 on it...)
| Albert Pool (albertpool) wrote : | #10 |
@ syscon-hh: offset=8 appears to work, skip=8 does not help to preserve the UUID after a reboot (skip without a value is ignored by cryptdisks_start).
| Albert Pool (albertpool) wrote : | #11 |
@ syscon-hh: or did you mean offset=8,skip=0? I will test that too.
| Albert Pool (albertpool) wrote : | #12 |
@ syscon-hh: I do not see any difference using it with offset=8 or offset=8,skip=0.
| syscon-hh (syscon-kono) wrote : | #13 |
@ Albert - both options should be used alternatively only:
* offset=8
or
* skip=8
never both in one line.
for further Informations see "man cryptsetup" -> "options"
| Albert Pool (albertpool) wrote : | #14 |
@ syscon-hh: in that case, offset=8 works, skip=8 does not. So offset=8 it is.
| Star Man (starman) wrote : | #15 |
Hello everyone, I reached here from bug Bug #1301383.
I'd like to know if this issue is gonna be adressed by the time 14.04.1 comes out, since installing it as is today doesn't enable the SWAP partition...
| isync (o-zucker) wrote : | #16 |
Alberts hint in #9 is correct. I've just fixed this issue on my system:
https:/
Most verbose and explanatory comment:
https:/
| ryokenau (ryokenau) wrote : | #17 |
I followed through all the comments, but I've still run into problems after rebooting.
Comment #3 by syscon-hh <https:/
After this process is completed (as explained by Albert)...
"Then you can convert your unencrypted swap into an encrypted one, using sudo ecryptfs-
Again, use swapon -s to verify that the swap is enabled; but now it should display /dev/mapper/
...swap is not activated after a reboot. I confirmed that the latest changes to /etc/fstab and /etc/crypttab made by ecryptfs-setup-swap have remained intact.
So I tried manually enabling swap:
$ sudo swapon -a -v
Which resulted in the following error:
read swap header failed: Invalid argument
So I tried doing this:
$ sudo mkswap /dev/mapper/
$ sudo swapon -a -v
And swap was up and running again!
But does swap work after rebooting? It sure does, albeit with the following errors in dmesg:
device-mapper: ioctl: Unable to change name on mapped device cryptswap1_
The only hint I can find so far is in /var/log/
* cryptswap1 (starting)...
Device cryptswap1_
...done.
Any suggestions on what's happening here?
| no longer affects: | ecryptfs |
| c4pp4 (c4pp4) wrote : | #18 |
@ syscon-hh
I can confirm your workaround #3.
UUID alongside offset=8 is working well in my case.
| Dekker500 (dekker-crater) wrote : | #19 |
Ouch. This was painful to resolve.
The workarounds proposed do not work "out of the box" when encountered after a "default" installation of 14.04.01 using encrypted fs and home directory. Under those conditions, the encrypted swap is named ubuntu--vg-swap_1. Following the instrucions in post 3, 9, and 17 leave the system in a slightly odd state as the ubuntu--vg-swap_1 is properly setup, but the /etc/crypttab has an entry for "cryptswap1" (which is why Ryokenau was having trouble).
Wish I had time to detail proper fix, but I needed to manually adjust /etc/crypttab to point to proper ubuntu--vg-swap_1, and adjusting /etc/fstab with appropriate UUID for the swap file.
| Changed in ecryptfs-utils (Ubuntu): | |
| importance: | Undecided → High |
Well, I've seen a similar bug in Precise for quite a long time:
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
and any proposed solution to clear the infamous message 'The disk drive for /dev/mapper/
Ubuntu Trusty 14.04.1
$ free --human
total
Mem: 15.7G
-/+ buffers/cache: 985M
Swap: 0.0B
$ swapon --summary
Filename Type Size Used Priority
https:/
cryptswap1 UUID=01234567-
to
cryptswap1 UUID=01234567-
the problem persists. The same with the line:
cryptswap1 /dev/sdaX /dev/urandom swap,cipher=
after formating the swap partition with the old UUID:
sudo mkswap --label Ubuntu\ Swap --uuid 01234567-
and rebooting the system. So I guess the problem is due to a race condition of the /etc/init.
My final solution to this problem:
DON'T DISABLE /etc/init.
1. DEACTIVATE AUTOMATIC MOUNTING OF CRYPTSWAP1:
Modify /etc/fstab changing the line:
/dev/mapper/
to
/dev/mapper/
and modify /etc/crypttab changing the line from:
cryptswap1 UUID=01234567-
to
cryptswap1 UUID=01234567-
Don't forget to replace my sample UUID with the correct for your system. On my system offset=6 was sufficient, because cryptsetup already skips the two first sectors of the swap partition.
2. REBUILD YOUR SWAP PARTITION
CAUTION: you must replace /dev/sdaX with the correct swap partition for your system!
sudo mkswap --label Ubuntu\ Swap --uuid 01234567-
Don't forget to replace my sample UUID with the correct for your system. The label is optional (I like swap partition labels :D)
3. CREATE AN UPSTART SCRIPT ( /etc/init/
start on started mountall
script
/sbin/
/sbin/swapon /dev/mapper/
end script
4. REBOOT AND VERIFY YOUR SYSTEM
$ free --human
total used free shared buffers cached
Mem: 15.7G ...
-/+ buffers/cache: ...
Swap: 16.0G ...
$ swapon --summary
Filename Type Size Used Priority
/dev/mapper/
| Albert Pool (albertpool) wrote : | #23 |
What happened on Trusty was that cryptswap started using UUID instead of /dev/sdXY names, and the encryption with a random key overwrites the partition's UUID unless an offset in crypttab is used. So I wouldn't tag it as a duplicate of a Precise bug, a whole new problem was created by switching to UUID in Trusty.
Yes, Albert, you are right. My last precise/cryptab backup says:
cryptswap1 /dev/sdaX /dev/urandom swap,cipher=
My problem with trusty seems to be two different bugs happening at the same time. The first, the UUID problem, that is solved with offset = 6 & mkswap, and the second, the hateful message 'The disk drive for /dev/mapper/
| Albert Pool (albertpool) wrote : | #25 |
I would keep the two problems in separate bugs, since they do not have the same cause. This is the bug for the problems with the partition UUID and the crypttab file.
| Redsandro (redsandro) wrote : | #26 |
A note of warning:
Without swap, you are used to your laptop suspending to RAM when closing the lid.
@Wetware Random Number Generator (tnrng)
> wrote on 2014-10-10: #22
> My final solution to this problem:
This causes laptops to try to hibernate when you close the lid. Failing. Losing all unsaved changes. Even though in Power Management settings are set to suspend (not hibernate).
Got any clue on how to get closed laptops to suspend again in stead of hibernate?
| Albert Pool (albertpool) wrote : | #27 |
About power management settings being ignored, please ask on the forum of Ubuntu (or the distro you are using) or open a new bug. It should be unrelated to this bug, you just never saw this problem because you were never able to hibernate at all.
That hibernate fails, is yet another different problem. It is by design that the encrypted swap created by ecryptfs-setup-swap won't work with hibernate. I think it has been discussed at length in other bug reports or on forums already, with other encryption methods (such as encryption with a password instead of a random key) being suggested as solutions. Not encrypting your swap would of course allow you to hibernate as well.
In short, you already fixed the problem which this bug describes, the other problems which are left to fix are beyond the scope of this bug.
| Jarno Suni (jarnos) wrote : | #28 |
As for #17, in my experience swap was activated sometimes, but not always, during reboot.
| dalesd (dalesd) wrote : | #29 |
I'm in the same situation as Ryokenau.
Back to Dekker500's comment #19, does this only occur when you check the installer options for encrypted filesystem and encrypted home?
In other words, if you run the installer and select "Erase disk and install Ubuntu" and check "Encrypt the new Ubuntu installation" and "Use LVM" but *not* "Encrypt my home folder", would that work around this bug?
If the entire disk is encrypted, it's redundant to encrypt /home too, correct? At least, for a single-user machine.
As shown here:
https:/
https:/
https:/
| ScarySquirrel (coproc-sbcglobal) wrote : | #30 |
Hey.
I have a way to work around this in 14.04, 14.10, and 15.04:
COMPLETE FIX -- Ubuntu Utopic Unicorn 14.10 -- The disk drive dev/mapper/
| Eric (ericscott07) wrote : | #31 |
Hi there, I believe I patched the issue in ecryptfs-setup-swap which causes this problem in the first place.
This program now sets the swap's fstab to noauto, crypttab offset to 6, and creates a file in /etc/init which mounts the swap partition automatically as soon as it's ready.
I beleve there are 2 problems with the current setup. The first one is caused by the cryptswap changing the uuid of the drive. This is fixed by using an offset of 6 (* 512 bits) to skip the portion where the uuid is apparently stored. The second one is caused by fstab trying to mount the swap before cryptab has encrypted the partition. This is fixed by mounting the partition with the /etc/init file.
This program will still find multiple swap partitions on the harddrive, encrypt them, and mount them automatically at boot.
You can also use it to fix your current system by doing the following:
Delete all mention to the swap partitions in your /etc/fstab and /etc/crypttab.
Restart your computer.
Reformat your swap partitions.
Enable your swap partitions and make sure they are running working properly.
Finally in the directory containing my patched verson run:
chmod +x ecryptfs-setup-swap
sudo ./ecryptfs-
and restart your computer .
Now your swaps should all be encrypted and working!
If this doesn't work for you please let me know.
| no longer affects: | ecryptfs |
| Eric (ericscott07) wrote : | #32 |
I would also like to add that this attachment is basically just automating #22's solution to the problem.
The attachment "ecryptfs-
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
| tags: | added: patch |
| Eric (ericscott07) wrote : | #34 |
Yes that is a patch for the ecryptfs-setup-swap script. If ubuntu were to use it to replace the current ecryptfs-setup-swap in the installation iso we would no longer have this bug.
| syscon-hh (syscon-kono) wrote : | #35 |
Yes this patch is working - but under *upstart* only.
Using the coming up systemd feature this patch will destroy more than the patch helps.
| Eric (ericscott07) wrote : | #36 |
Well that's too bad. I'll try to find a way that doesn't use upstart then. Thanks for the information! I'll keep you guys posted.
| Eric (ericscott07) wrote : | #38 |
So, from what I can tell, this is the only way to do it while working with an init upstart system. I suppose that when ubuntu makes that change, I'll just have to write another patch. I do believe archlinux had was having a similar problem with crypttab and uuid's. They use systemd but, they just assume you set it up yourself, using /dev/disk/by-id (wich is unique for every disk) (or apply an offset of 6). I also don't remember there being a problem after that, so maybe since they use systemd the issue is avoided (maybe).
| Eric (ericscott07) wrote : | #39 |
Okay, so I believe that I fixed the issue without using upstart. This version instead uses sysvinit instead. Please let me know what you think. This would fix the issue for the installer if it was added to the iso.
You can also use it to fix your current system by doing the following:
Delete all mention to the swap partitions in your /etc/fstab and /etc/crypttab.
Restart your computer.
Reformat your swap partitions.
Enable your swap partitions and make sure they are working properly.
Finally in the directory containing my patched verson, run:
chmod +x ecryptfs-setup-swap
sudo ./ecryptfs-
and restart your computer.
Should I create a ppa for this?
| syscon-hh (syscon-kono) wrote : | #40 |
Stay with script for upstart version as provided with #32
Due to *systemd* will work no longer with *init.d* anyway.
The version #39 makes nothing else then to provide the *crysetup* in background only.
| syscon-hh (syscon-kono) wrote : | #41 |
Now our solution -> provided for *systemd* computers:
*/etc/fstab*
# LABEL=COMMON-SWAP none swap sw 0 0
uncomment swap-volume only!
*/etc/crypttab*
# <target name> <source device> <key file> <options>
cryptswap1 LABEL=COMMON-SWAP /dev/urandom swap,cipher=
Required are *offset=8* - otherwise the given basis (swap-volume) will be destroid! For testing purpose only the *LABEL* definition has been used.
*/etc/rc.local* (extension modul)
/sbin/cryptdisk
/bin/sleep 5
/sbin/swapon /dev/mapper/
Comments: -> */bin/sleep 5* -> t.b.d. - depends on volume / GiB to be crypted.
*/etc/rc.local* -> will be started from */lib/systemd/
root@USB-GNOME:~# blkid | grep COMMON-SWAP
/dev/sdb1: LABEL="COMMON-SWAP" UUID="c939105e-
PARTUUID=
root@USB-GNOME:~# swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 8519672 0 -1
| sudodus (nio-wiklund) wrote : | #42 |
I can confirm that *offset=8* in the line in */etc/crypttab* makes cryptswap survive reboots. I have tested it in Lubuntu Vivid 32-bit.
I used the simple method described in comment #3.
| sudodus (nio-wiklund) wrote : | #44 |
Don't get me wrong. I read this bug report, and I see that there are many comments that point forward to squashing the bug.
The previous post (#42) describes a work-around method that works today with Lubuntu Vivid. It does not contain what will be used to squash the bug. See the following link
http://
I was confronted with this bug simply because I checked "Encrypt home folders" during a fresh installation of Ubuntu LTS 14.04 .
There seems to be a certain amount of unwillingness to resolve this issue because we are moving from Upstart to systemd.
This I understand.
However, why not leave users then with at least a working unencrypted swap, instead of a non-functional encrypted swap?
After all, during installation I checked for encrypting /home, not swap. Furthermore, the risks involved with a plain, unencrypted swap are very limited.
Here is how I recovered from the disfunctional swap without reinstalling, nor rebooting, whilst keeping /home encrypted:
http://
| sudodus (nio-wiklund) wrote : | #46 |
*** This bug is a duplicate of bug 953875 ***
https:/
which is actually squashed now. The working version of cryptswap is available when you install 15.04.
For example, the following iso test case for Lubuntu works (I have tested it)
http://
Status changed to 'Confirmed' because the bug affects multiple users.