Suse/NovellThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have two encrypted partitions (one internal the other external) which worked fine in openSuse 11.1.
I just installed 11.2 and can no longer access either partition.
Yast partitioner asks for the passphrase but then fails to mount saying I need to specify the file system type (which is not an option available to me).
I have tried #cryptsetup luksOpen /dev/sda4 data
which asks for and accepts the passphrase saying the device is unlocked. But when I try to mount the partition I am again asked to specify the fs type, but it does not accept ext3 when specified.
fsck and e2fsck report bad superblock for the various block numbers I have tried.
I have seen elsewhere that it may be related to VIA and a padlock module but it is not clear to me how to proceed in that direction.
I find it hard to believe that I am the only person to have had this experience and would appreciate any help available.
(ps otherwise I am very impressed with 11.2 - shame about my data!)
Yes, I have tried that and after:
# cryptsetup luksOpen /dev/sda4 data2
Enter LUKS passphrase for /dev/sda4:
key slot 0 unlocked.
Command successful.
I do:
# mount -t ext3 /dev/mapper/data2 /data2
and get:
mount: wrong fs type, bad option, bad superblock on /dev/mapper/data2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
dmesg gives me this:
[123831.055052] padlock: VIA PadLock not detected.
[123831.101519] padlock: VIA PadLock Hash Engine not detected.
This thread (https://bugs.launchpad.net/ubuntu/+s...ux/+bug/206129) suggests either using alais or blacklist to disable the padlock-sha module. When I try that I get this in dmesg when I try to mount after unlocking:
[ 59.800835] Intel AES-NI instructions are not detected.
[ 65.642599] VFS: Can't find ext3 filesystem on dev dm-0.
Both fsck and e2fsck report bad superblock (for the various block numbers I have tried):
fsck from util-linux-ng 2.16
e2fsck 1.41.9 (22-Aug-2009)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/data2
e2fsck -b 8193 /dev/mapper/data2
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/data2
I am certain that it is ext3 not ext2. Fdisk reports thus:
/dev/sda1 * 1 2357 18932571 83 Linux
/dev/sda2 2358 2877 4176900 82 Linux swap / Solaris
/dev/sda4 2878 19929 136970190 83 Linux
If it helps, luksDump gives this:
LUKS header information for /dev/sda4
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
MK digest: e8 3b f5 8c 89 ea 6e eb 68 41 db a8 97 6f 13 92 0e 34 05 e7
MK salt: 66 88 f1 5a 37 e8 f2 b7 80 5f 58 8f 89 3d b3 9c
cd af 45 52 76 91 ea 87 58 8f 8b ae 0f 38 21 db
MK iterations: 10
UUID: 4a6a9b44-5a52-486e-8f7d-e1edc5ef0168
Attempts to mount after fsck or e2fsck both return the same superblock error as does using ext2:
mount -t ext2 /dev/mapper/data2 /data2
mount: wrong fs type, bad option, bad superblock on /dev/mapper/data2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
The encrypted partition was /dev/sdc1 (a 260GB external drive on a USB connection, originally encrypted by SUSE 10.3, I think). I wished to mount it as /data4.
and that was it. At one point I needed to input the passphrase for the encrypted partition so that it could be unlocked. After the second step /dev/mapper/data4_map was created and available to be mounted.
By the way, prior to this and while trying to find a solution, I had used dd to create a copy of the partition (dd if=/dev/sdc1 of=cryptimage.img) and ended up reformatting /dev/sdc1 as ext3. I then restored the image to /dev/sdc1 using dd (dd if=cryptimage.img of=/dev/sdc1). It was good to see that dd handled the encrypted data perfectly, although it did take about 36 hours to make each copy!
My only regret was that I did not figure out the solution until after I had already reformatted my internal drive (/data2). Fortunately the external drive is my (paranoid!) backup so I did not lose any data.
My only regret was that I did not figure out the solution until after I had already reformatted my internal drive (/data2). Fortunately the external drive is my (paranoid!) backup so I did not lose any data.
No paranoid there. That is why people use RAID arrays.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.