Bug 309531 - add cryptsetup(-luks) and crypto kernel modules to rescue cd
add cryptsetup(-luks) and crypto kernel modules to rescue cd
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-27 14:14 EDT by Till Maas
Modified: 2013-01-09 23:26 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-10 13:28:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Till Maas 2007-09-27 14:14:30 EDT
Description of problem:

The rescue cd does not contain cryptsetup-luks, but this would be useful in
cases one has an encrypted filesystem on ones harddisk and needs to access data
from there.

Imho these kernel modules are needed, to make cryptsetup-luks work:
kernel/drivers/md/dm-crypt.ko
kernel/drivers/block/cryptoloop.ko
kernel/crypto/blkcipher.ko
kernel/crypto/deflate.ko
kernel/crypto/md4.ko
kernel/crypto/xcbc.ko
kernel/crypto/crc32c.ko
kernel/crypto/sha512.ko
kernel/crypto/sha256.ko
kernel/crypto/crypto_null.ko
kernel/crypto/camellia.ko
kernel/crypto/anubis.ko
kernel/crypto/arc4.ko
kernel/crypto/fcrypt.ko
kernel/crypto/aes.ko
kernel/crypto/lrw.ko
kernel/crypto/ecb.ko
kernel/crypto/tgr192.ko
kernel/crypto/khazad.ko
kernel/crypto/cbc.ko
kernel/crypto/blowfish.ko
kernel/crypto/wp512.ko
kernel/crypto/cast5.ko
kernel/crypto/pcbc.ko
kernel/crypto/twofish_common.ko
kernel/crypto/tea.ko
kernel/crypto/des.ko
kernel/crypto/gf128mul.ko
kernel/crypto/cast6.ko
kernel/crypto/michael_mic.ko
kernel/crypto/serpent.ko
kernel/crypto/twofish.ko

Optionally also these:
kernel/arch/i386/crypto/twofish-i586.ko
kernel/arch/i386/crypto/aes-i586.ko

And this kernel module seems to be useful for a rescue cd, too:
kernel/fs/ecryptfs/ecryptfs.ko
Comment 1 Till Maas 2007-11-12 03:57:09 EST
It would be helpful, if these modules were also on the normal install image, btw.
Comment 2 Chris Lumens 2007-11-30 00:11:55 EST
Dave - if you haven't already taken care of all of this as part of your
encrypted filesystem support, this may be something for you to look into.
Comment 3 Bruno Wolff III 2008-03-10 12:04:08 EDT
I was just able to use rescue mode on a system with encryption over raid. I have
the raid arrays mounted and they seem OK. (I haven't done the actual rescuing
yet, but that should be possible.) I do have a nit about how it works though.
I get asked to enter a password for each partition as well as each array. I
think for software raid partitions, besides looking for a luks signature, it
should also look for the raid array info. If it finds both, then the encryption
should be over raid and it shouldn't try to use it for that partition. If it
finds luks, but no raid info, then it should prompt for a password because it
might be raid over encrypted partitions.
To get it to work I hit cancel as each partion was asked about and then gave the
password (there was just one for all of the  encrypted arrays) for the first
array and checked global password and then wasn't prompted for the the other
two. All of them (/, /home and /play) were mounted under /mnt/sysimage.
Comment 4 Jeremy Katz 2008-03-10 13:28:55 EDT
Bruno -- can you file something separate on the RAID case (as yeah, it
definitely seems like that needs to be fixed).  But it looks like the basic bits
here are all set

Note You need to log in before you can comment on or make changes to this bug.