# [SOLVED] boot problem decrypting w/ cryptsetup-1.1.3-r1

## freifunk_connewitz

hi

after the upgrade of cryptsetup to version 1.1.3-r1 my encrypted partitions (not root!) did not mount at bootup anymore. I've been using the /etc/conf.d/dmcrypt configuration for a while now, so it's not the case that I would use the old /cryptfs config file anymore. the problem rather lays somewhere in the dm-crypt addon-script of checkfs, because before the checkfs-initscript always triggered cryptsetup successfully and asked me for the passwords. but now checkfs just complains there would be no dev/mapper/XXX device to check and skips to the next step, thus skipping the decryption of my partitions, too. not good.

however, after a while of futile searching through the forums and google I gave up and threw =sys-fs/cryptsetup-1.1.3-r1 into my /etc/portage/package.mask and remerged it (downgrading). if you encounter the same problem you probably should do the same. and although I'm not sure bout this, perhaps this package should be masked unstable again.Last edited by freifunk_connewitz on Fri Jan 14, 2011 8:57 pm; edited 1 time in total

----------

## majestyk

I have exactly the same problem. I guess it would work out if I would be running baselayout-2, but that package is still not marked stable for my architecture. Downgrading cryptsetup worked for me, too. Thanks for the hint!

----------

## kernelOfTruth

I haven't seen any of such problems:

so yes, it most probably is an incompatibility of cryptsetup and the stable-marked baselayout

running baselayout-2*, openrc and cryptsetup-1.1.3-r1 works fine for me

FYI:

if anyone's planning to try out cryptsetup-1.2* in the future - don't - or better make a backup and have a liveCD available

I kept getting segfaults    :Confused: 

edit:

seems to be a toolchain related problem (binutils) from what I found out so far

----------

## Zarhan

I've ran into this same issue. Fortunately I only used encrypted swap at boottime..

----------

## vaclav.blazek

The problem is inside /lib/rcscripts/addons/dm-crypt-start.sh (and ....-stop.sh), from version 1.1.3-r1 there is SVCNAME used to get config file: /etc/conf.d/${SVCNAME}. In case of baselayout-1 the value of SVCNAME is "localmount" => config file not found => nothing done => no dmcrypt mapping created.

There are these possibilities:

 * upgrade to baselayout-2

 * downgrade to 1.1.2

 * fix those two rc addon files to work with baselayout-1

EDIT: found this one https://bugs.gentoo.org/show_bug.cgi?id=350399

----------

## Princess Nell

Epic fsck-up. New versions of Xorg and config files, I can deal with, but this is bordering on sabotage. I'm seriously pissed off.

```

# emerge sys-apps/anger-management

```

----------

## selig

I have run into this issue today, after rebuilding world (emerge -e world), cryptsetup got upgraded as well. I was WTF when it was not asking for the passphrase to my key and did not mount my /home and swap. After a couple of hours of investingating how the rc system actually works (through some weird "addons"), I found out that the dm-crypt addon gets executed via the checkfs script. The problem is, it checks for /etc/conf.d/$SVCNAME and tries to read configuration from it - but $SVCNAME is "checkfs" in this case. I did this nasty workaround hack:

```

cd /etc/conf.d

ln -s dmcrypt checkfs

```

And it is working now... but OMG, how can they release it as "stable" when there is such an incredible bug in it?

----------

## frostschutz

I'm using 1.1.3 however the disks get decrypted in booting stage (initramfs) using my own code so naturally such a configuration file issue would not be on my radar.

Maybe no one tested the supposedly standard setup...

----------

## freifunk_connewitz

fixed in version 1.1.3-r2

but now another thing popped up: obviously the dmcrypt-startup-script has problems to follow the post-mount-entries in /etc/init.d/dmcrypt. I was wondering why my KDE failed to start ("failed to call to lnusertemp") and found out why - after creating crypt-tmp somehow the dmcrypt startup process ignored the entry 

```
post_mount='chmod 1777 /tmp'
```

. thus, /tmp was set to 755, so was /var/tmp (I link that to /tmp), so nobody but root could write to /tmp, so KDE fails to start.

changed it manually, but we'll see what happens at the next boot. otherwise: back again to cryptsetup-1.1.2. damnit.

EDIT: the post_mount problem already seems to be in consideration of the Gentoo devs (https://bugs.gentoo.org/show_bug.cgi?id=350399), but isnt solved yet in the version mentioned above, so it's still adviceable to stick to cryptsetup 1.1.2.

----------

## freifunk_connewitz

solved in current stable cryptsetup-1.1.3-r3

----------

