Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 108698 - dm-crypt mappings in /etc/conf.d/cryptfs are not properly created & mounted on boot
Summary: dm-crypt mappings in /etc/conf.d/cryptfs are not properly created & mounted o...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Benjamin Smee (strerror) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-10 01:40 UTC by P. Schnell
Modified: 2006-12-28 16:32 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description P. Schnell 2005-10-10 01:40:18 UTC
I have encrypted my whole system using this guide:
http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS
If I map & mount the encrypted partitions by hand, everything is working fine.
I'm using 
sys-apps/baselayout-1.12.0_pre8-r2
and
sys-fs/cryptsetup-luks-1.0.1

This is my /etc/conf.d/cryptfs:

swap=swap
source='/dev/sda2'
options='-d /dev/urandom -c blowfish-cbc-essiv:sha256 -s 256'
pre_mount='mkswap ${dev}'

mount='dl1'
source='/dev/sda6'
type=luks
options='-d /root/dl1.key -c serpent-cbc-essiv:sha256 -s 256'

mount='dl2'
source='/dev/sda7'
type=luks
options='-d /root/dl2.key -c serpent-cbc-essiv:sha256 -s 256'

mount='storage1'
source='/dev/hdc1'
type=luks
options='-d /root/storage1.key -c serpent-cbc-essiv:sha256 -s 256'

mount='storage2'
source='/dev/hdc2'
type=luks
options='-d /root/storage2.key -c serpent-cbc-essiv:sha256 -s 256'

mount='storage3'
source='/dev/hda1'
type=luks
options='-d /root/storage3.key -c serpent-cbc-essiv:sha256 -s 256'

mount='storage4'
source='/dev/hda2'
type=luks
options='-d /root/storage4.key -c serpent-cbc-essiv:sha256 -s 256'

I'm pretty sure this is setup correctly, because the quirk is that it works 5%
of the time,
but most of the time this is what I get while booting:

*setting up dm-crypt  mappings...                          [ok]
*dm-crypt map swap...                                      [ok]
*running pre_mount commands for swap...                    [ok]
*dm-crypt map dl1...                                       [ok]
*/bin/cryptsetup -d /root/dl1.key -c serpent-cbc-essiv:sha256 -s 256 luksOpen
/dev/sda6 dl1...     [ok]
key slot 0 unlocked
*dm-crypt map dl2...                                       [ok]
*/bin/cryptsetup -d /root/dl2.key -c serpent-cbc-essiv:sha256 -s 256 luksOpen
/dev/sda7 dl2...     [ok]
key slot 0 unlocked
*dm-crypt map storage1...                                  [ok]
*/bin/cryptsetup -d /root/storage1.key -c serpent-cbc-essiv:sha256 -s 256
luksOpen /dev/hdc1 storage1...     [ok]
key slot 0 unlocked
key slot 0 unlocked
*dm-crypt map storage2...                                  [ok]
*/bin/cryptsetup -d /root/storage2.key -c serpent-cbc-essiv:sha256 -s 256
luksOpen /dev/hdc2 storage2...     [ok]
key slot 0 unlocked
key slot 0 unlocked
key slot 0 unlocked					   [ok]
fsck /dev/mapper/dl1 is mounted. e2fsck: cannot continue, aborting.
*dm-crypt mapping storage2 is already configured
*dm-crypt map storage3...     
*/bin/cryptsetup -d /root/storage3.key -c serpent-cbc-essiv:sha256 -s 256
luksOpen /dev/hda1 storage3...     [ok]
* dm-crypt map storage4 ...
* /bin/cryptsetup -d /root/storage4.key -c serpent-cbc-essiv:sha256 -s 256
luksOpen /dev/hda2 storage4
key slot 0 unlocked.
key slot 0 unlocked.                                                           
                [ ok ]
* Checking all filesystems ...
fsck: cannot check /dev/mapper/root: fsck.reiserfs not found
fsck.ext3: No such file or directory while trying to open /dev/mapper/dl1
/dev/mapper/dl1:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

/dev/mapper/dl2 is mounted.  e2fsck: Cannot continue, aborting.

fsck.ext3: No such file or directory while trying to open /dev/mapper/storage1
/dev/mapper/storage1:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
     e2fsck -b 8193 <device>

/dev/mapper/storage2 is mounted.  e2fsck: Cannot continue, aborting.

Some filesystem could not be mounted blabla Press CTRL-D to continue or Enter
for root console




I press CTRL + D and the system goes on booting.
These error messages always seem to vary, sometimes storage3, 4 & 5 don't get
mapped & mounted properly,
sometimes it's dl1, storage2 & 5 etc.
Since it says "dm-crypt mapping storage2 is already configured" I first thought
that maybe the mappings
are not destroyed correctly while shutting down, but even if I unmap everything
by hand before rebooting
the problem still consists. Because it is kind of random, I am pretty sure that
the flaw lies within the
boot scripts (localmount, checkfs) & baselayout.
Maybe someone more adept with booting procedure in regard to dm-crypt mappings
could take a  look at this.
Thank you!


Reproducible: Sometimes
Steps to Reproduce:
1. Encrypt partitions via dm-crypt & luks
2. Setup /etc/conf.d/cryptfs
3. Boot
Comment 1 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2005-11-25 16:10:52 UTC
Is this still a problem or have the latest ebuilds (baselayout and
cryptsetup-luks) solved this? Please let me know so I can either help you solve
it or close this bug.

On a different note your first entry, the pre_mount= line is unneccesary, the
swap= line will tell the script to do everything else that is necessary. For
example my entry in /etc/conf.d/cryptfs is:
swap=crypt-swap
source='/dev/mapper/vg0-swap'
Comment 2 P. Schnell 2005-11-30 08:30:15 UTC
I just upgraded to the latest  baselayout-1.12.0_pre11-r3 &
cryptsetup-luks-1.0.1-r1 and changed /etc/conf.d/cryptfs to your suggestions,
but the
problem still persists. I did 6 reboots, and
only once the crypto-mappings were created correctly, the other 5 failed, just
the  swap gets mapped correctly everytime. I have no idea whats wrong and it
seems i'm the only one with that problem.
Any further help would be greatly appreciated.
Comment 3 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-10-12 04:10:38 UTC
Please try upgrading your setup to 1.0.3-r3, read the /etc/conf.d/cryptfs and modify your setup accordingly. let me know if it doesn't work for you.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-12-28 16:32:16 UTC
This bug is awaiting user response...