Reusing crypted file systems

Hi,

another problem that I seem to always experience when a new SuSE version comes along (in this case of course 11.3) is to get access to my encrypted file systems.

The good news for SuSE 11.3 is that encrypted partitions on usb drives can be quite easily mounted at least in KDE. The partions were created with 11.2 if I remember correctly.

Bad news is that I have another encrypted partiion on my system disk that was created with 11.1 (that was the version that was installed on the machine till today).

I thought I did everything correctly when installing 11.3 (I did a new installation rather than an update). The installation procedure asked me about the encrypted partition and asked for the password to mount it. It seemed ok in the first try but when I came to the step where I had to deal with the partiions of the system disk, I told the installation procedure to first re-read the data from the system disk and then retriev the fstab data from 11.1. Everything seemed to be ok in the first place but when I started the installation the installatino procdure already complained that the crypted partiation could not be mounted. I still continued with the installation (in the end, I have a back up of the data on the crypted partition).

After the installation was finished, I checked for the problem with the crypted partition. I found out that the installation procedure had messed up things quite significantly because I spcified *-part7 for the encrypted partition and the installation procedure entered *-part8 into /etc/crypttab. I fixed this manually and after the changes I was asked for the password at boot time. However, when I enter the password (which is for sure correct!), the system report:

FATAL: Error inserting padlock_sha (/lib/modules/2.6.34-12-default/kernel/drivers/crypto/padlock-sha.ko): No such device

I can reproduce this error message when I try: modprobe padlock-sha

What does the kernel module padlock-sha actually do???

Which device is meant here??? I would assume that because of this I get the error message:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/cr_sda7,
missing codepage or helper program, or other error
Manchmal liefert das Syslog wertvolle Informationen – versuchen
Sie dmesg | tail oder so

when I try to mount /dev/mapper/cr_sda7 (which is interesting enough correcty created).

It is really a pitty that dealing with crypto file systems is such a pain in the neck with SuSE. I say this because I already had this problem with this partition when I installed 11.1. At that time I updated from 10.3 to 11.1 and the partition had an encrypted ext2 file system. Now I am sure it is ext3 and it is an upgrade from 11.1 to 11.3. With this I do not consider it acceptable that I have to recreate the file system as a whole.

Can anybody give me a hint how I could save the partition and use it in 11.3 without creating a new file system?

Thank you very much for your help?

Cheers,

Klaus

On Sat, 24 Jul 2010 23:36:03 +0000, KUFischer wrote:

> Can anybody give me a hint how I could save the partition and use it in
> 11.3 without creating a new file system?

The thing is, you never, ever, should replace a working computer (linux)
operating system with another version that you haven’t tested that
fully works in your machine and with your needs.

Meaning, that you should have a dedicated test partition. On this, you
can test the factory version and report (bugzilla) those things that do
not work and you need, so that they have time to repair, or at least, so
that you get some information.

At worst, if the final version, installed in the extra partition, doesn’t
work, you can ask and wait till the problem is solved, before doing the
real upgrade.

In this case, I think it is trying to load a module that is not needed.

Let’s see, What is the output of:

file -s /dev/sda7
file -s /dev/mapper/cr_sda7

I assume you kept the old /etc/crypttab?


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

Hi Carlos,

thank you very much for your comments.

First of all, yes, I do agree with your suggestion but unfortunately the world is not perfect. The machine I am talking about is a bit older and therefore the internal hard disk is not big enough to allow me to have two reasonabl sized root partitions. At least this is the situation right now. I of course consider to use the internal disk for system data only and put all user data on an external drive. But this needs time. And yes, I have another machine that has more space on the internal drive and for this I do exactly as ou suggest. This is the machine to start with for every new version of SuSE. Unfortunately, so far I do not have a crypted partition on the internal disk of this machine. I tested crypted USB partitions and obviously had to learn that this is no prove that it will work out for the internal disk …

But to your questions:

file -s /dev/sda7
/dev/sda7: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: f0e0b382-0659-4042-bfae-fc11a1c

file -s /dev/mapper/cr_sda7
/dev/mapper/cr_sda7: symbolic link to `…/dm-0’
file -s /dev/dm-0
/dev/dm-0: data

cat /etc/crypttab
cr_sda7 /dev/disk/by-id/ata-WDC_WD2000JB-75DUA0_WD-WMACK1728589-part7 none none

I admit that I changed what the installation procedure produces (which however, was **** because it used part8 as alreday explained although definitely said correctly that part7 is the encrypted partition!). So what I did was replace part8 with part7 and put none instead of noauto. The later at least make /etc/init.d/boot.crypto restart ask for a password. However, it fails with the the error message.

device-mapper: remove ioctl failed: Device or resource busy
mount: wrong fs type, bad option, bad superblock on /dev/mapper/cr_sda7,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Funny (or not so funny :-() enough. Just today when I tried to start my notebook which is still running 11.2 and did work fine till yesterday, I cannot access my crypto partiion on this notebook anymore. I remember that there was a system update yesterday and it seems that this now makes the boot.crypto fail. When I try a /etc/init.d/boot.crypto restart I now (and this just started today!!!) get the error message:

Activating crypto devices using /etc/crypttab …
Please enter passphrase for cr_sda7:
Command failed: device-mapper: reload ioctl failed: Invalid argument

Please do not get confused it is just by chance that the crypted partition on both machines happen to have the same number.

I think somebody out there is doing something nasty to cryptofs and this should be fixed as fast as possible.

But anyway thanks for your help!

Cheers,

Klaus

Have you reported it in bugzilla. We are all just users like you here.

Hi,

thanks for your comment. No I did not report it. I thought I first ask here to see whether somebody has advise. I will submit a bug report tomorrow. The whole crypto story does not really look good. I seriously consider to look for another solution …

Cheers,

Klaus

On Sun, 25 Jul 2010 10:06:02 +0000, KUFischer wrote:

> Hi Carlos,
>
> thank you very much for your comments.

Welcome :slight_smile:

> First of all, yes, I do agree with your suggestion but unfortunately the
> world is not perfect. The machine I am talking about is a bit older and
> therefore the internal hard disk is not big enough to allow me to have
> two reasonabl sized root partitions. At least this is the situation
> right now. I of course consider to use the internal disk for system data
> only and put all user data on an external drive. But this needs time.
> And yes, I have another machine that has more space on the internal
> drive and for this I do exactly as ou suggest. This is the machine to
> start with for every new version of SuSE. Unfortunately, so far I do not
> have a crypted partition on the internal disk of this machine. I tested
> crypted USB partitions and obviously had to learn that this is no prove
> that it will work out for the internal disk …

Perhaps you could have a small test partition, like 5 or 7 GiB.

> But to your questions:
>
> file -s /dev/sda7
> /dev/sda7: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1]
> UUID: f0e0b382-0659-4042-bfae-fc11a1c

Ok, so the system detects the encrypted partition. That’s good.

> file -s /dev/mapper/cr_sda7
> /dev/mapper/cr_sda7: symbolic link to `…/dm-0’ file -s /dev/dm-0
> /dev/dm-0: data

Data… not good. Look at mine:

Elessar:~ # file -s /dev/sdc9
/dev/sdc9: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1]
UUID: …

Elessar:~ # file -s /dev/mapper/cr_cripta
/dev/mapper/cr_cripta: SGI XFS filesystem data (blksz 4096, inosz 256, v2
dirs)

And another:

Elessar:~ # file -s /dev/mapper/cr_other
/dev/mapper/cr_other: ReiserFS V3.6

I don’t have any one of ext3 type to check, but you see that the
filesystem type should be seen, after the password is accepted. If it
doesn’t match, the mapped device node does not appear, I believe (how can
we test that?)

A plain (not encripted) ext3 system would be seen like this:

/dev/sda7: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
(large files)

And an ext2 like this:

/dev/sda3: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3,
LBA flag 0x1, 1st sector stage2 0xd2927, GRUB version 0.97, code offset
0x48

Ahhh! I need to test “file” on a plain ext2 filesystem, not one that has
grub on it.

dd if=/dev/zero of=test_ext2 bs=32K count=10000
losetup /dev/loop7 test_ext2

file -s /dev/loop7

/dev/loop7: data

mkfs.ext2 /dev/loop7

file -s /dev/loop7

/dev/loop7: Linux rev 1.0 ext2 filesystem data

Ok, so it can get confused by grub, but youshould see something like
that, not plain “data”.

> cat /etc/crypttab
> cr_sda7
> /dev/disk/by-id/ata-WDC_WD2000JB-75DUA0_WD-WMACK1728589-part7 none none

That looks correct to me. It is what I have, with a different ID, of
course.

> I admit that I changed what the installation procedure produces (which
> however, was **** because it used part8 as alreday explained although
> definitely said correctly that part7 is the encrypted partition!). So
> what I did was replace part8 with part7 and put none instead of noauto.
> The later at least make /etc/init.d/boot.crypto restart ask for a
> password. However, it fails with the the error message.
>
> device-mapper: remove ioctl failed: Device or resource busy mount: wrong
> fs type, bad option, bad superblock on /dev/mapper/cr_sda7,
> missing codepage or helper program, or other error In some cases useful
> info is found in syslog - try dmesg | tail or so

The error given by the script is “designed” to be confusing on purpose,
IMO. YOu have to look carefully at the syslog.

Now is too late (3:15 AM), but tomorrow I can give you manual
instructions on how to mount an encrypted partition without the helper
script, so that we can check the steps. Tonight I may get things wrong,
I’m sleepy :wink:

I remember bugs I reported on this that might interfere, like KDE/Gnome
getting in the middle and breaking the script. Your system is fully
updated (YOU)? If not, please do.

Hold on… you have 11.3. I can’t vouch for that one, I haven’t really
tested it. My knowledge is only up to 11.2.

> Funny (or not so funny :-() enough. Just today when I tried to start my
> notebook which is still running 11.2 and did work fine till yesterday, I
> cannot access my crypto partiion on this notebook anymore. I remember
> that there was a system update yesterday and it seems that this now
> makes the boot.crypto fail. When I try a /etc/init.d/boot.crypto restart
> I now (and this just started today!!!) get the error message:

Wow. :frowning:

>
> Activating crypto devices using /etc/crypttab … Please enter
> passphrase for cr_sda7:
> Command failed: device-mapper: reload ioctl failed: Invalid argument
>
> Please do not get confused it is just by chance that the crypted
> partition on both machines happen to have the same number.

Understood.

>
> I think somebody out there is doing something nasty to cryptofs and this
> should be fixed as fast as possible.

At least as soon as we get a clearer idea of what is happening.

Did you try a reboot? Just in case.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

Hi Carlos,

thank you very much for your explanations. It will take some time to read and check them carefully. I can only do this when I am back home this evening. Now I first of all have to take care of my work.

But so much so far. From what I understood by briefly reading your comments, you are very right. The problem is that Linux does not recognize the file system type, for what ever reason …

Thank you very much for your help,
cheers,

Klaus

Oh, I forgot to mention: Yes, of course, I did reboot. Several times. And more important: The crypted partition 11.2 refuses to accept can be mounted after some fiddling around with 11.1 which I still have on the notebook …

Cheers,

Klaus

On 2010-07-26 08:36 GMT KUFischer wrote:

>
> Oh, I forgot to mention: Yes, of course, I did reboot. Several times.
> And more important: The crypted partition 11.2 refuses to accept can
> be mounted after some fiddling around with 11.1 which I still have on
> the notebook …

Mmmm… That 11.2 is fully updated? I mean the mandatory updates, the
ones from the “update” repo, kernel and such stuff.

I did not have problems reusing my 11.0 (and much earlier) encrypted
stuff in 11.2 (dunno about 11.3), so it has to work.

Later, time permitting, I’ll try to write up the manual mount procedure.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

Hi,

sorry, forget about the comment on 11.2. I messed things up there on my own while I tried to findout about the problem with 11.3. Could fix it again. However, the problem with the partition on 11.3 remains. I would be very glad if I could get access to this partition again …

Thanks for all your help,
cheers,

Klaus

Hi Carlos,

just as additional comments:

> file -s /dev/mapper/cr_sda7
> /dev/mapper/cr_sda7: symbolic link to `…/dm-0’ file -s /dev/dm-0
> /dev/dm-0: data

As you already pointed out, this is the main problem. To me it means that 11.3 is not able to decrypt the data on the partition and therefore is not able to find out what the file system could be. To me this either means that 11.3 is not equipped with the necessary mechanism for decryption or the data on the partition was corrupted during installation. I do not see any reasonable chance on my side to check whether the data on the partition is sane.

All I can say is that after I started to install 11.3 I never did intentionally write to this partition. So if the partition was damaged it was either by pure chance or by the installation procedure.

I actually experience a similar behavior as shown above with some encrypted partitions of some older usb drives that I use for backup. This is especially disappointing because this means that encrypted partitions are obviously no safe place to store data for a bit longer time. However, still encrypted LURKS partitions are the only means that I am aware of to make a native copy of ext3 file systems in a secure manner. it is a real petty that this options is jeopardized in this manner …

However, do not worry to much about me other than that you or other people involved in cryptofs think about what might be possible to improve the situation in the future. I decided to switch to using an external drive for the user data on the machine that I am talking about.

For now I just leave the partition dangling there. If an update comes along that allows me to read it again, fine. If not, of course, the data is lost. I will use the partition for the next SuSE upgrade as you suggested …

Anyway I learned again a bit of something about Linux in this process.

So thank you very much for your time and your help,
cheers,

Klaus

On 2010-07-27 09:36 GMT KUFischer wrote:

>
> Hi Carlos,
>
> just as additional comments:
>
> > file -s /dev/mapper/cr_sda7
> > /dev/mapper/cr_sda7: symbolic link to `…/dm-0’ file -s /dev/dm-0

/dev/dm-0: data

As you already pointed out, this is the main problem. To me it means
that 11.3 is not able to decrypt the data on the partition and
therefore is not able to find out what the file system could be. To
me this either means that 11.3 is not equipped with the necessary
mechanism for decryption or the data on the partition was corrupted
during installation. I do not see any reasonable chance on my side to
check whether the data on the partition is sane.

I don’t think it is damaged.

Let me dig out my notes.

Manual procedure (11.2, which is what I have). Verification:



Elessar:~ # file -s /dev/sdc10
/dev/sdc10: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1]
UUID: ...


First, I intentionally give wrong password:

Elessar:~ # cryptsetup luksOpen /dev/sdc10 cr_other
Enter LUKS passphrase for /dev/sdc10:
Enter LUKS passphrase for /dev/sdc10:
Enter LUKS passphrase for /dev/sdc10:
Command failed: No key available with this passphrase.

Elessar:~ #


So, wrong password will ask again for it, and in the end, fail. That's
good for us. Now I give the correct one:


Elessar:~ # cryptsetup luksOpen /dev/sdc10 cr_other
Enter LUKS passphrase for /dev/sdc10:
key slot 0 unlocked.
Command successful.
Elessar:~ #

A second attempt should fail:

Elessar:~ # cryptsetup luksOpen /dev/sdc10 cr_other
Command failed: Device cr_other already exists.


If entering the correct password fails, post the error here and we'll
think. It would help if you can test the same partition or external
disk with 11.2 or any other that works, because with that data we can
create a security bug at bugzilla (I consider crypto related bugs as
security bugs, unless told otherwise).


Second step: test.


Elessar:~ # cryptsetup status cr_other
/dev/mapper/cr_other is active:
cipher:  aes-cbc-essiv:sha256
keysize: 128 bits
device:  /dev/sdc10
offset:  1032 sectors
size:    104855160 sectors
mode:    read/write
Elessar:~ #

Elessar:~ # dmsetup ls
cr_other        (253, 1)
....


Elessar:~ # dmsetup info cr_other
Name:              cr_other
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1
UUID: CRYPT-...XXXXX

Elessar:~ #


The UUID above is almost the same the "file -s ..." command gave above,
save the "CRYPT-" and some new letters at the end.


Elessar:~ # dmsetup status cr_other
0 104855160 crypt


I don't know how to interpret that one.



Third step: attempt mounting.


Elessar:~ # file -s /dev/mapper/cr_other
/dev/mapper/cr_other: ReiserFS V3.6

I think that in your case, it is a symlink to /dev/dm-0. In 11.2 this
is not so, neither are symlinks. That's something new to me.


Elessar:~ # l /dev/dm-0
brw-rw---- 1 root disk 253, 0 Jun 20 11:47 /dev/dm-0

Elessar:~ # l /dev/mapper/cr_other
brw-r----- 1 root disk 253, 1 Jul 27 21:58 /dev/mapper/cr_other


Elessar:~ # mount /dev/mapper/cr_other /mnt/tmp
Elessar:~ # mount | grep "/mnt/tmp"
/dev/mapper/cr_other on /mnt/tmp type reiserfs (rw)
Elessar:~ #



To undo:

Elessar:~ # umount /dev/mapper/cr_other
Elessar:~ # cryptsetup remove cr_other
Elessar:~ #



Now, if the password phase did not complain, the dmsetup information
command seem correct (or not) and the mount fails or the filesystem is
not detected, the next step is reporting this in Bugzilla, soon. If
this is not reported, it will never be solved.

And, if it works, but the script crcrypto fails, then report that one.

You have to look carefully at the log to see if some message appears
during all this, and add to the report.

One bug I found at the start of 11.2, was that as soon as the password
was accepted by dmsetup or the script, the gnome automounter would see
the /dev/mapper device and instantly mount it under /media, making the
script subsequently fail. I think this was corrected.

> All I can say is that after I started to install 11.3 I never did
> intentionally write to this partition. So if the partition was damaged
> it was either by pure chance or by the installation procedure.

I doubt this happened. I hope!

> For now I just leave the partition dangling there. If an update comes
> along that allows me to read it again, fine. If not, of course, the
> data is lost. I will use the partition for the next SuSE upgrade as
> you suggested …

Yes, please, don’t format it. However, for this to be solved it has to
be reported in Bugzilla, otherwise it will be ignored unless somebody
else comes along and report it.

>
> Anyway I learned again a bit of something about Linux in this process.
>
> So thank you very much for your time and your help,
> cheers,

Welcome!

Although I don’t plan to update to 11.3, I really need that encryption
to disk works. Thus my interest :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

Hi,

just as an urgent comment on this matter.

THERE IS A SERIOUS BUG IN THE INSTALLATION PROCEDURE OF SUSE 11.3!!!

What I can tell for (almost ;-)) sure now is that the installation routine of 11.3 killed my crypto partition, the problem that I explained here. The installation does a format on the partition even when it is told not to do so! It is not really sure what causes the problem but we speculate that it happens when you try to import an existing fstab from the hard drive.

I can for sure say that after I did a re-read of the hard disk partition table and an import of fstab with no further change to the drive spec I had an identical result on two machines (desktop and notebook). In both cases the the crypto partition was no longer readable and a new file system had to be created.

Maybe it would be a good idea to make this thread sticky and include this behavior into the list of known and most annoying bugs.

Ok, well, just to mention, yes, I made a bug report in bugzilla …

Cheers,

Klaus

Ok, well, just to mention, yes, I made a bug report in bugzilla …

Could you please provide a link? Are there any likewise experiences about this? For I am about to upgrade to 11.3 soon and definitily do not want to lose my encypted partition.

On 2010-07-28 15:36, KUFischer wrote:
>
> Hi,
>
> just as an urgent comment on this matter.
>
> THERE IS A SERIOUS BUG IN THE INSTALLATION PROCEDURE OF SUSE 11.3!!!
>
> What I can tell for (almost ;-)) sure now is that the installation
> routine of 11.3 killed my crypto partition, the problem that I explained
> here. The installation does a format on the partition even when it is
> told not to do so! It is not really sure what causes the problem but we
> speculate that it happens when you try to import an existing fstab from
> the hard drive.
>
> I can for sure say that after I did a re-read of the hard disk
> partition table and an import of fstab with no further change to the
> drive spec I had an identical result on two machines (desktop and
> notebook). In both cases the the crypto partition was no longer readable
> and a new file system had to be created.

Not readable by 11.3 only, or also not readable by a 11.2 or older in the same computer? Because I
think you said that you tried again with 11.2 and it could read the data.

> Maybe it would be a good idea to make this thread sticky and include
> this behavior into the list of known and most annoying bugs.
>
> Ok, well, just to mention, yes, I made a bug report in bugzilla …

Please post the number.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

Executive summary:
I have a server at home currently running opensuse-11.2 (32 bit). I wanted to bring a bulk-load of files (mp3 collection) from home and got a spare usb hard drive, but the work computer refuses to see the file system as valid when the encrypted device is set up. The odd thing is that a colleague, running ubuntu 64 bit, can create the encrypted device and fsck and mount it and see the data.

I set up the encrypted file store on suse11.2 manually:


    # /sbin/cryptsetup create cr_fred /dev/sde1
    # mkfs.ext4 /dev/mapper/cr_fred
    # mkdir /mnt/fred
    # mount /dev/mapper/cr_fred /mnt/fred
    # rsync -av /home/mp3 /mnt/fred/
    ....
    # sync
    # umount /mnt/fred
    # /sbin/cryptsetup remove cr_fred

I then created entries in /etc/crypttab and /etc/fstab so I could mount the drive just by running “/etc/boot.crypto start”, and it worked.

I took the drive to work and followed a similar procedure and it failed


    # /sbin/cryptsetup create cr_fred /dev/sde1
    # fsck /dev/mapper/cr_fred
    fsck from util-linux-ng 2.17.2
    e2fsck 1.41.11 (14-Mar-2010)
    fsck.ext4: Superblock invalid, trying backup blocks...
    fsck.ext4: The ext2 superblock is corrupt while trying to open /dev/mapper/cr_fred

    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>

I thought I must have corrupted the drive, so I took it home and was able to mount it and fsck it etc no problem. Back at work, same problem as above. Got a colleague running ubuntu 64 bit to cryptsetup/fsck/mount and it was perfect.

I wondered what suse 11.3 was doing differently from 11.2, so I tried using “bash -x /etc/init.d/boot.crypto start” on my file server at home to see if there were any special parameters being passed to cryptsetup, but I didn’t see anything obvious.

My next guess is that the kernel is different - 11.2 at home is 2.6.31.12-0.2-pae, 11.3 at work is 2.6.34-8-desktop, colleague is (ubuntu 64) 2.6.32-24-generic

Like KUFischer above I am now worried about the safety of using an encrypted drive for long term storage, as it means I could suddenly lose the ability to decrypt my system or backup drives. I am now considering for off-site backups NOT using an encrypted drive and placing it in a locked fire safe whose physical key is hidden.

p.s. I found this useful tutorial:
https://help.ubuntu.com/community/EncryptedFilesystemHowto3

I think I shall re-do the crypt device as I missed out this step:

   cryptsetup luksOpen /dev/yyyy xxx

Interesting, I was able to access the USB drive using my fujitsu U2010 which runs 10.04-32bit-ubuntu-netbook-remix, so whatever it is, it’s specific to suse 11.3

On 2010-08-06 13:06, speculatrix wrote:
>
> Executive summary:
> I have a server at home currently running opensuse-11.2 (32 bit). I
> wanted to bring a bulk-load of files (mp3 collection) from home and got
> a spare usb hard drive, but the work computer refuses to see the file
> system as valid when the encrypted device is set up. The odd thing is
> that a colleague, running ubuntu 64 bit, can create the encrypted device
> and fsck and mount it and see the data.
>
> I set up the encrypted file store on suse11.2 manually:
>
> Code:
> --------------------
>
> # /sbin/cryptsetup create cr_fred /dev/sde1
> # mkfs.ext4 /dev/mapper/cr_fred
> # mkdir /mnt/fred
> # mount /dev/mapper/cr_fred /mnt/fred
> # rsync -av /home/mp3 /mnt/fred/
> …
> # sync
> # umount /mnt/fred
> # /sbin/cryptsetup remove cr_fred
>
> --------------------

The correct sequence is:

cryptsetup -v --key-size 256 luksFormat /dev/device

cryptsetup luksOpen /dev/device name

mkfs… /dev/mapper/name

cryptsetup remove name

Create the fstab and crypttab entries, mount and use. To mount manually, you skip the create and use
the open directly.

> I took the drive to work and followed a similar procedure and it failed
>
> Code:
> --------------------
>
> # /sbin/cryptsetup create cr_fred /dev/sde1

This would create a new one overwriting what you have, I believe.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

no, running cryptsetup create doesn’t write anythign to the drive, I was able to cryptsetup-remove and then -create over repeatedly. in fact usign “bash -x /etc/init.d/boot.crypto” shows this is done when suse creates the encrytion layer over the top of the raw device

yes, I now know I took a shortcut when initialising the encrypted volume in the first place :-/