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
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 ***
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
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.
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
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.