Launchpad has imported 27 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=194249.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2006-06-06T16:16:27+00:00 Marco wrote: Description of problem: cryptsetup fail on CDs/DVDs encrypted with LUKS. This causes the Gnome desktop not to deal properly with them. Version-Release number of selected component (if applicable): cryptsetup-luks-1.0.3-0.rc2 How reproducible: Always. Steps to Reproduce: 1. Insert a CD/DVD encrypted with LUKS (with the Gnome desktop). Actual results: Asks for password, but fails to mount. (NOTE: the cleartext dm device is faulty, that's why the mount fails.) Expected results: After asking for the password to unlock the LUKS volume, the cleartext version should be mounted under /media/something. Even w/o automagic mounting of the device, the clear text version of the volume should be available for later mounting. Additional info: This is a well-known bug, see: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2006-March/000213.html It should be solved already: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2006-March/000250.html AFAICS, all it takes is to rebuild from the new tarball (rc3). As a workaround, encrypted CDs/DVDs can be accessed by mapping the reader device to a loop device and having cryptsetup work on the latter. losetup /dev/loop0 /dev/cdrom cryptsetup luckOpen /dev/loop0 myvolume mount /dev/mapper/myvolume /media/myvolume There's no quick and clean way to fix /usr/share/hal/scripts/hal-luks-* to do the above, AFAIK. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/0 ------------------------------------------------------------------------ On 2006-06-07T09:57:25+00:00 Marco wrote: Created attachment 130664 detect CDs/DVDs in hal-luks-setup Well I've tried cryptsetup-1.0.3 (release), but does not seem to work yet. The only way to successfully Open the LUKS volume is to pass the --readonly to cryptsetup: cryptsetup luckOpen --readonly /dev/cdrom myvolume If you don't specify --readonly, cryptsetup keeps asking you for the password (even if it reports that the key has been successfully unlocked). As a consequence g-v-m keeps asking for the password as well. Attacched is a small patch/hack to fix this behaviour. Anyway for some reason I still have to find the process stops there. The clear text dm device (luck_crypto_<UUID>) is created, but not mounted nor added as a volume. In summary, it seems that the upstream cryptsetup package still has issues with CDs/DVDs. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/1 ------------------------------------------------------------------------ On 2007-07-26T18:51:12+00:00 Till wrote: (In reply to comment #1) > Created an attachment (id=130664) [edit] > detect CDs/DVDs in hal-luks-setup > Attacched is a small patch/hack to fix this behaviour. Anyway for some reason > I > still have to find the process stops there. The clear text dm device > (luck_crypto_<UUID>) is created, but not mounted nor added as a volume. > > In summary, it seems that the upstream cryptsetup package still has issues > with > CDs/DVDs. hal-luks-setup is part of the hal package and when the clear text dm device is created with above patch, imho it is not a bug in cryptsetup, because it did its work, but maybe in gnome or in hal. I change this bug to hal, because at least your patch regards hal. Can you test, whether it works with gnome and your patch in F7, please? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/4 ------------------------------------------------------------------------ On 2007-07-30T10:07:06+00:00 Marco wrote: Well, it's hard to place the blame here. cryptsetup has issues, it keeps failing when you try to open a luks volume that is on readonly media (CD/DVD). It should at least detect the problem, and not keep asking the user for a password. I'd say that the unlock routine keeps failing, but the program doen't really handle the failure right. The message is even deceiving: # cryptsetup luksOpen /dev/scd0 myvolume Enter LUKS passphrase: key slot 0 unlocked. Enter LUKS passphrase: key slot 0 unlocked. Enter LUKS passphrase: key slot 0 unlocked. Command failed: device-mapper: reload ioctl failed: Invalid argument Please note that I kept typing the right password (it does work, says key slot0 unlocked, but something fails later and it restarts asking the password). As a WORKAROUND to this cryptsetup 'bug', I tried and patched the hal script. With --readonly cryptsetup works for cd/dvd. Whether this patch should be in it's hard call, depends on how the bug is fixed... if cryptsetup recognizes the readonly media and assumes --readonly, this patch will be totally useless. If cryptsetup just fails sensibly ("error: media is not writable, please use --readonly"), then this little patch will be necessary. Anyway, I should stress it's not enough. I don't understand much on the internals of the mount mechanics under gnome/nautilus/hal. Even with my patch, the volume won't be mounted. Only, a dm device appears in this form: /dev/mapper/luks_crypto_bd6949c6-a617-4bb0-b3b0-723df33f9023 which is just what I think the script I patched is supposed to provide. What I'm missing, it's why it stops there, and does not mount it. I don't see any difference with a USB stick with a luks volume (which I think works just fine). The device file is a working iso9660 image, which I can manually mount. It has a volume name even: # iso-info -f /dev/mapper/luks_crypto_bd6949c6-a617-4bb0-b3b0-723df33f9023 iso-info version 0.77 x86_64-redhat-linux-gnu Copyright (c) 2003, 2004, 2005 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. __________________________________ ISO 9660 image: /dev/mapper/luks_crypto_bd6949c6-a617-4bb0-b3b0-723df33f9023 Application: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM System : LINUX Volume : BCK200706C Once created the mapper device, I'd expect it to be either mounted under /media (/media/BCK200706C) or at least be visible via nautilus, but it's not. So the mount process stops somewhere, but I have no idea of where! BTW, all this has just been tried on a Fedora 7. There's a small obvious difference in the patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/122241/comments/5 ------------------------------------------------------------------------ On 2007-07-30T10:10:48+00:00 Marco wrote: Created attachment 160228 patch for hal-luks-setup-linux Slightly different version of the patch, for Fedora 7. This one applies to /usr/lib64/hal/scripts/linux/hal-luks-setup-linux, on x86_64. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/6 ------------------------------------------------------------------------ On 2007-07-30T10:17:01+00:00 Marco wrote: Created attachment 160229 patch for hal-luks-setup-linux Opps sorry, the previous one had some extra debugging commands, here's the clean one. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/7 ------------------------------------------------------------------------ On 2007-08-17T17:37:20+00:00 Till wrote: I have written a patch that makes cryptsetup "detect" read-only devices. I am not sure, whether this is really sane or if there is another way to do this in a better way. It only makes in unnecessary to provide "--readonly" when opening a cdrom device, so it does not solve this problem completely: http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/cryptsetup-luks/devel/cryptsetup-1.0.5-readonly_detection.patch?rev=1.1&only_with_tag=HEAD Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/8 ------------------------------------------------------------------------ On 2008-04-04T03:03:23+00:00 Bug wrote: Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/12 ------------------------------------------------------------------------ On 2008-04-04T16:44:54+00:00 Marco wrote: This bug is confirmed in F7 (as stated before). Confirmed on F8 as well. Mounting the volume with shell commands works fine: # cryptsetup luksOpen -r /dev/dvd myvol # mount -r /dev/mapper/myvol /mnt After doing some more tests, I discovered this: USB memsticks work, but only if they carry a partition table. That is, assuming /dev/sda is your USB sticks device, if /dev/sda1 is your LUKS volume everything works fine. The LUKS volume is detected, it asks for a passwork, it unlocks it and mounts it under /media/<volname>. But if you LUKS format /dev/sda (the disk as a whole) it doesn't. The symptoms are the same as for CD/DVDs (which of course don't carry a partition table). It asks for a password, correctly opens the device, but stops before mounting it, with no errors. I hope it helps somehow. I don't know where to look for further info. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/13 ------------------------------------------------------------------------ On 2008-04-10T23:04:47+00:00 John wrote: thanks for the update Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/14 ------------------------------------------------------------------------ On 2008-04-11T13:44:17+00:00 Matthias wrote: > I hope it helps somehow. I don't know where to look for further info. It would be really good to know how well this works on F9, since there have been quite a few changes in this area. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/15 ------------------------------------------------------------------------ On 2008-05-06T02:41:36+00:00 John wrote: Hi Marco, If possible could you try one more time on Fedora 9 (rawhide)? Thanks Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/17 ------------------------------------------------------------------------ On 2008-05-07T19:53:52+00:00 Marco wrote: Sorry, unfortunately I don't have access to a test system right now. I'll have to ask a friend to do that, I'll let you know. A couple of questions: is there a Live image of rawhide that I can use for the test? Is it possible to run a Live image (w/o installing it) of Fedora 9 Preview and update it to rawhide with yum? Would that make sense? (that is: does it need a reboot to test the changes? if so, it wouldn't make any sense to try that). Anyway, the test procedure is quite simple. Maybe someone else will be able to test it. Build a LUKS image, even on file: # dd if=/dev/zero of=luks.img bs=1024k count=10 # losetup /dev/loop0 luks.img # echo "test" | cryptsetup --batch-mode luksFormat /dev/loop0 Command successful. # echo "test" | cryptsetup luksOpen /dev/loop0 test key slot 0 unlocked. Command successful. # mke2fs -q -Ltest /dev/mapper/test # cryptsetup luksClose test # losetup -d /dev/loop0 Now luks.img holds a 10MB encrypted (although empty) ext2 fs. If you have a spare USB key, one you can completely wipe out, just first put the image into the first partition: (assuming /dev/sda is the USB storage device) warning: this destroyes the contents of the key # dd if=luks.img of=/dev/sda1 And just try inserting the key. It should ask for the LUKS password, and after you type it in ('test'), it should mount (hopefully under /media/test). Umount it. Now, put the same image on the whole USB device, not the first partition: # dd if=luks.img of=/dev/sda When you insert the key, you get the usual password requester, but it won't mount it correctly. If it does, the bug is solved. :) You'll have to repartition your USB key, tho. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/122241/comments/18 ------------------------------------------------------------------------ On 2008-08-07T21:38:12+00:00 Mike wrote: Tested in F9 fully updated as at 7th August 2008. DMCRYPT-LUKS encrypted CD placed in CDROM - dialogue pops up asking for Luks passphrase. No further response. No messages in /var/log/messages. No file opened in /media/ I can certainly make the CD contents visible by doing the following steps: MAPPER="cryptocd" CDROM=/dev/cdrom MOUNTDIR=/mnt/tmp LOOP=$(losetup -f) losetup $LOOP $CDROM && echo $LOOP >/tmp/loop_device cryptsetup luksOpen $LOOP $MAPPER mount /dev/mapper/$MAPPER $MOUNTDIR Entering the luks passphrase when prompted - then ls /mnt/tmp will list the files on the encrypted CD....(Note /mnt/tmp was already defined as a mount point. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/20 ------------------------------------------------------------------------ On 2008-08-07T22:01:19+00:00 Till wrote: (In reply to comment #13) > I can certainly make the CD contents visible by doing the following steps: > MAPPER="cryptocd" > CDROM=/dev/cdrom > MOUNTDIR=/mnt/tmp > LOOP=$(losetup -f) > losetup $LOOP $CDROM && echo $LOOP >/tmp/loop_device > cryptsetup luksOpen $LOOP $MAPPER > mount /dev/mapper/$MAPPER $MOUNTDIR This will not help to resolve the original problem, but you should not need to use losetup here I guess. And you can probably use mount.crypt from pam_mount to easily mount your cdrom with: mount.crypt /dev/cdrom /mnt/tmp umount.crypt /mnt/tmp should also work then. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/21 ------------------------------------------------------------------------ On 2008-11-26T06:58:33+00:00 Bug wrote: This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/24 ------------------------------------------------------------------------ On 2009-01-03T19:53:41+00:00 Mike wrote: Tested in F10 The mount works as per #13, but the suggestion from #14 does not as the command line does not recognise mount.crypt The file browser in gnome sees the encrypted volume and clicking it requests a passphrase but then fails to mount anything. Places in gnome again sees the encrypted drive and requests a passphrase but again fails to mount saying there is no mount point specified. There are no messages in /var/log/messages indicating any connection to the mount for the CDROM. This needs to be remedied for F10/F11 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/25 ------------------------------------------------------------------------ On 2009-01-03T19:55:04+00:00 Mike wrote: Please can this be re-assigned to F10? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/26 ------------------------------------------------------------------------ On 2009-01-03T20:45:38+00:00 Till wrote: (In reply to comment #16) > The mount works as per #13, but the suggestion from #14 does not as the > command > line does not recognise mount.crypt You need to install pam_mount to get mount.crypt Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/27 ------------------------------------------------------------------------ On 2009-01-03T22:02:41+00:00 Mike wrote: Ahh OK - with pam_mount installed then mount.crypt and umount.crypt do work as per #14 - however I get a request for the passphrase when the CD is loaded into the drive and again another request for the passphrase when I issue the mount.crypt command. Also going to the device list in the "computer" gui browser, and right clicking to eject the disk fails, but doing "eject /dev/cdrom" in the CLI does work. It would be nice if this could be cleaned up so it works in a smoother fashion. I know I could make a small script to mount and umount/eject but it would be nice to have this available by default, and it would also be nice to have this work such that on loading the CD, that the passphrase is requested, then at the same time a mount point entered so that the pam_mount is then executed "under the hood" - or is this a difficult facility to get working? I guess it would fail if an inappropriate mount point was specified but there could be a default such as /media/cdrom_crypt or somesuch? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/28 ------------------------------------------------------------------------ On 2009-07-19T08:05:46+00:00 Martin wrote: I myself had this problem and haven't paid attention until I saw this bug report referred from bug#122241 in bugs.launchpad.net (https://bugs.launchpad.net/bugs/122241) recently. Here is my result in Fedora 11: 1. Insert DVD 2. gnome-mount asks for passphrase; enter one 3. DVD volume appears in the desktop (yeah!) 4. Double-click to open it 5. nautilus launches, the icon disappears from desktop, and the icon is shown in nautilus 6. clicking the icon from nautilus asks for passphrase again, then complains that it's already given the passphrase, but nothing is mounted in /media. 7. 'mount /dev/mapper/devkit-disks/luks-* /mnt/cdrom' from command line works 8. umount and eject works from command line 9. ejecting from nautilus gets complaint that /dev/sr0 is busy used by another module, and eject fails. 10. Subsequent insertion of dvd gets request for passphrase but complains about /dev/sr0 busy. Nautilus shows the icon but no desktop icon. Eject gives the same complaint as above with failure. 11. command line mount/umount/eject all still works. For now, that's the workaround: Insert dvd, enter passphrase, then simply mount, umount, and eject from command line. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/29 ------------------------------------------------------------------------ On 2009-07-19T08:33:42+00:00 Martin wrote: I guess I spoke too soon. Here are more details: Fedora 11: 1. Insert DVD, enter passphrase when requested 2. icon of the unencrypted volume appears in the desktop, but it disappears as nautilus is launched, and nautilus shows the encrypted volume icon 3. Mount and umount from command line works 4. eject from nautilus works, as long as I don't do eject from command line So the workaround is: Insert dvd, enter passphrase; mount and umount from command line; eject from gnome/nautilus. Subsequent closing of DVD drive causes button press eject to not work. The only way to eject is command line eject. once this is done, re- inserting DVD causes the same problem as before: asks for passphrase, then complains that org.freedesktop.DeviceKit.Disks.Error.Busy: One or more block devices are holding /dev/sr0. The same error when trying to eject from nautilus, until the next reboot. But mount/umount/eject from command line works as usual. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/30 ------------------------------------------------------------------------ On 2009-07-20T06:20:26+00:00 Riumin wrote: I have the same problem - icon appears and immediately disappears in the desktop. After this the same error occured. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/31 ------------------------------------------------------------------------ On 2009-11-18T08:06:56+00:00 Bug wrote: This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/32 ------------------------------------------------------------------------ On 2009-11-22T05:10:25+00:00 Martin wrote: As of the latest update of Fedora 11 (11/17/2009), I find that the mounting problem is solved. I can enter the passphrase and access everything from nautilus. Now I have a different problem. When I eject the drive from GUI right- click, I get the following error, although the disk icon disappears: Unable to unmount DISK DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. If I manually eject the dvd, it comes out, but after closing the tray, I cannot open the tray anymore, either from command line or pushing a button. I can see that kcryptd is still running and /dev/mapper/devkit-* still exists, possibly locking the dvd device, which is why I couldn't open the tray. The only solution is to 'cryptsetup luksClose devkit-*' from command line. But this causes another problem. If I subsequently insert the same dvd and enter the passphrase, the following error occurs: The folder contents could not be displayed. 'userdisk' could not be found. Perhaps it has recently been deleted. I'm not sure I should open a new ticket (since the original problem has been solved) or let someone (original poster) move this to Fedora 11. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/33 ------------------------------------------------------------------------ On 2009-12-18T05:52:33+00:00 Bug wrote: Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/34 ------------------------------------------------------------------------ On 2009-12-18T11:04:39+00:00 Alasdair wrote: Ref comment #24 - please open a new bugzilla. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- mount/+bug/122241/comments/35 ** Changed in: gnome-mount (Fedora) Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/122241 Title: LUKS-encrypted CDROM / DVD ROM are detected but mounting fails To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/122241/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
