Bug 532606 - After 12beta update, LUKS strangeness, inability to unmount
After 12beta update, LUKS strangeness, inability to unmount
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
12
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Milan Broz
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-02 19:26 EST by Ryan Rix
Modified: 2013-02-28 23:07 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-22 17:48:59 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 Ryan Rix 2009-11-02 19:26:40 EST
Description of problem:
I have a small (20gb) LUKS encrypted Logical Volume mounted at /private since I installed Fedora 11. This has worked fine, presenting me with the password dialog to unlock the device in plymouth and from the command line. After upgrading to Fedora 12, my system hangs if plymouth is enabled until i change to text login mode, at which point, I am greeted with a PIN dialog to unlock /dev/dm-0, rather than the /private it asked for before. After I enter the key, I get a ton of I/O errors and other things which did not appear before. In fact, it appears as if LVM is unlocking the device twice.
I'm sorry for the horrible quality, but I've only got a craptastic camera phone. Here is a log of what happens shortly after unlocking the device. Note that the checks on the harddisk are because of a hard-stop I did, but these errors occured both before and after this hard stop: http://twitpic.com/o2cdd/full

I finally got sick of this and realized that GPG suited my needs just as well, if not better for encrypting the files I had stored on this device, so I decided to delete it and save myself the troubles. Unfortunately, s-c-lvm says that the device is in use, it's not listed in /etc/mtab and mount, and lsof|grep private says that no files are open in the /private partition. Which is just wierd.

[rrix@TheSwan ~]$ sudo lsof|grep private
kded4      2602      rrix  mem       REG      253,3    295348      23668 /usr/lib/libkhotkeysprivate.so.4.3.0
akonadise  3957      rrix  mem       REG      253,3   1378444      70240 /usr/lib/libakonadiprivate.so.1.2.1
yakuake    3978      rrix  mem       REG      253,3   1002048      94052 /usr/lib/libkonsoleprivate.so
konversat  3985      rrix  mem       REG      253,3   1002048      94052 /usr/lib/libkonsoleprivate.so
kontact    4100      rrix  DEL       REG      253,3               449996 /usr/lib/libkontactprivate.so.4.3.0
kontact    4100      rrix  DEL       REG      253,3               449952 /usr/lib/libkaddressbookprivate.so.4.3.0;4aef525c
kontact    4100      rrix  DEL       REG      253,3               450011 /usr/lib/libkorganizerprivate.so.4.3.0
kontact    4100      rrix  DEL       REG      253,3               449984 /usr/lib/libkmailprivate.so.4.3.0
kontact    4100      rrix  DEL       REG      253,3               449574 /usr/lib/libakregatorprivate.so.4.3.0
konqueror  4317      rrix  mem       REG      253,3     41928      28478 /usr/lib/libkonquerorprivate.so.4.3.0
konqueror 20155      rrix  mem       REG      253,3     41928      28478 /usr/lib/libkonquerorprivate.so.4.3.0
[rrix@TheSwan ~]$ rpm -q lvm2
lvm2-2.02.53-2.fc12.i686
[rrix@TheSwan ~]$ cat /etc/mtab
/dev/mapper/vg_theswan-root / ext4 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
/dev/sda2 /boot ext3 rw 0 0
/dev/mapper/vg_theswan-home /home ext4 rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
Comment 1 Milan Broz 2009-11-03 04:27:11 EST
This looks really terryfiyng, but there is no risk of losing data - the IO error are on temporary cryptsetup device, which is wrongly accessed by other application, cryptsetup intentionally remaps it to error devoce to prevek possible keyslot leaks.

BTW for the LUKS device is in use probably because LVM voulmes are activated on it (you need to deactivate them first.)

(Please can you retest it with new updates? See the duplicate bug.)

*** This bug has been marked as a duplicate of bug 528909 ***
Comment 2 Ryan Rix 2009-11-03 15:33:51 EST
Thanks; I know no data is at risk, it's just pretty annoying how it hangs up plymouth and is impossible to delete. I'm playing with lvchange right now, but somehow it's in use to the point where I can't even lvchange it... I'm confused by the matter in general. I odn't have enough experience with LVM to debug it :(

I'll update and then take a look at 528909
Comment 3 Ryan Rix 2009-11-04 18:39:17 EST
The bug that this one has been marked duplicate of is on a component I don't even have installed. I'm going to open this back up, as a result.
Comment 4 Bug Zapper 2009-11-16 09:56:57 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Milan Broz 2010-06-22 17:48:59 EDT
I added flags instructing udev rules to not scan temporary devices in cryptsetup, also it now tries to used udev if avaliable, so in next release these messages ("buffer i/o error" when scanning) should never appear again.
(It requires new udev + device-mapper, so it is in next Fedora release only.)

no idea how it is with s-c-lvm and umount, if you have still that problem, please report separate bug, thanks.

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