Bug 625490

Summary: Mount of crypto file system on internal drive fails ...
Product: [openSUSE] openSUSE 11.3 Reporter: Klaus Fischer <Klaus.Fischer>
Component: BasesystemAssignee: Thomas Fehr <fehr>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: aschnell, Klaus.Fischer
Version: Final   
Target Milestone: ---   
Hardware: x86   
OS: openSUSE 11.3   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Requested files: YaST2 logs, fstab, crypttab

Description Klaus Fischer 2010-07-26 10:01:12 UTC 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.6) Gecko/20100626 SUSE/3.6.6-1.2 Firefox/3.6.6

Problem is that I tried to update a machine that did run openSuSE 11.1 to 11.3. For user data I used an encrypted partition on the internal hard drive. Although the installation routine seemed to be perfectly happy in the beginning when I gave the information that there is an encrypted partition (it asked for the password, which I thought I did enter correctly, and seemed to mount the partition correctly in the first place), in a later stage the installation procedure started to complain about the partition. Because I had already started installation (at least I thought so), I did not think that it would make sense to stop at this stage and continued the installation. Now I have 11.3 installed and cannot access the encrypted partition anymore (it is not that bad, because I of course synced the partition with an external hard drive and therefore, I hope that, even if I do loose the partition, I won't loose any data, however, it is still annoying and I would like to know whether it is possible to save the partition).

Interesting enough the installed system can mount at least most of the encrypted partitions on usb drives that I tried. Still that some of them fail is another sad story that makes the use of cryptofs rather questionable ...

I try to give you some details on the partition:

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

Interesting enough it seems that somebody introduced yet another problem like this in openSuSE 11.2 (please note, I was talking about openSuSE 11.3 before!) but I am going to report on this in another bug report.

In case you have any questions, you can contact me at Klaus.Fischer@dfki.de.

Thank you very much for your cooperation,
best regards,

Klaus

Reproducible: Always

Steps to Reproduce:
Cannot say for sure. You would need to install openSuSE 11.1 with an encrypted partition on the internal drive and then try to update to 11.3.
Actual Results:  
Cannot mount the encrypted partition

Expected Results:  
I should be able to mount the encrypted partition
Comment 1 Thomas Fehr 2010-07-27 09:23:28 UTC 
Please attach file from /var/log/YaST, so that I can see exactly what was going on.

If you changed /etc/fstab and/or /etc/cryptotab after install/update please attach also
current versions of  /etc/fstab and /etc/cryptotab.

In 11.3 the fstab entries for encrypted partitions needs to contain "nofail" instead of "noauto".
As far as I can see we missed to update that in /etc/fstab automatically. Try changing "noauto"
to "nofail" in fstab line of the encrypted mount point and see if this make boot.crypto mount
your partition successfully. during system start.

You can manually test if your encrypted partition is still valid by the command
    cryptsetup luksOpen /dev/sda7 cr_sda7
it will ask you for the crypt password and sets up a device mapper device named
/dev/mapper/cr_sda7. This device allows unencrypted access to the data on /dev/sda7.
Comment 2 Klaus Fischer 2010-07-27 19:14:17 UTC 
Created attachment 378716 [details]
Requested files: YaST2 logs, fstab, crypttab

Hi,

first of all thanks for taking care of this.

In the attachedment I send you the logs of YaST2, fstab and crypttab.

Please note the fstab is the one that was produced by the installation procedure. The nofail option was added by the installation procedure because I did not know that it would exist or would be helpful. However, as I wrote mount fails. I of course also tried to mount with deleting noauto but this did not change anything. I am also aware of that the second none in the cr_sda7 line was specified with "noauto" by the intallation procedure. So this I did change manually. However, if I leave noauto (I of course also tried with the nofail option as just explained, no change) I am not asked for a password.

The command that you told me is not really of help because when I use it then the system just tells me that cr_sda7 already exists.

An explanation for all the trouble that came to my mind is that I remember that I told the installation procedure to reread mount points from /etc/fstab of the already installed system. As far as I remember the installation started to complain about sda7 after this although it seem to work ok before.

Please send me message in case you need any additional information.

Thank you very much for your help.

Cheers,

Klaus
Comment 3 Klaus Fischer 2010-07-27 19:15:41 UTC 
Sorry, forgot check the check box before committing ... :-(
Comment 4 Thomas Fehr 2010-07-28 09:56:48 UTC 
Unfortunately I have to tell you that yast2-storage destroyed the content of your encrypted
volume. This is of course a bug. I am will try to reproduce this here and will create a fix.

Fortunately you write that you have a backup of your data, so at least there is no data loss.

You can fix your system the following way (you must be root to be able to do this):
- execute /sbin/cryptsetup status cr_sda7, this should show something like:
     /dev/mapper/cr_sda7 is active:
       cipher:  aes-cbc-essiv:sha256
       keysize: 128 bits
       device:  /dev/sda7
       offset:  1032 sectors
       size:    57222435 sectors 
       mode:    read/write
- create an ext3 filesystem on the encrypted volume
    mkfs.ext3 /dev/mapper/cr_sda7
- mount it where it belongs
   mount  /dev/mapper/cr_sda7 /crypto/Linux

If anything goes wrong here just email me at fehr@suse.de.
 
Afterwards you can restore your data from your backup to /crypto/Linux.
The setup should also be fine after next reboot.
Comment 5 Thomas Fehr 2010-07-28 13:50:03 UTC 
Just as a warning for everyone using "Import fstab" feature. 

If /etc/fstab contains encrypted partitions there is a popup that asks for encryption password.
Be very sure to enter the correct encryption password here, entering a wrong password 
destroys content of encrypted partition due to a bug in yast2-storage.

To be completely on the save side refrain from using "Import fstab" feature if you have 
encrypted volumes in /etc/fstab.
Comment 6 Thomas Fehr 2010-07-29 14:08:25 UTC 
Problem is fixed in SVN Head and openSuSE-11.3 branch.

NOTE: Of course the problem is still present on 11.3 installation media, so everyone using 
"Import fstab" feature in 11.3 having encrypted partitions still needs to be very careful.
Comment 7 Thomas Fehr 2011-08-09 10:34:22 UTC 
forgot to close