A lot of times, when I paste medium-large files into USB mass storages, I can see that KDE immediately tells me that the copy is complete. Looking the activity led of Kingston usb mass storage, I can see that the computer is not copying. When finally I click on umount button, the computer starts copying the files inside the USB mass storage.. But, during this copy, I have the following system 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. In the past I saw that after this error. the USB mass storage seemed umounted. If I tried to remount it without physically removing it from USB port, the mount failed. To make the computer read again the USB mass storage, you had to physically remove it and mount it again. After that you could see that the copied data was corrupted. Instead, today, when I had the same problem, after the umount, I was able to remount it without physically removing it, and the data seemed okay. This bug happened also with other USB mass storages like pen drives and Android phones on both my computers. To check if it was a KDE problem, I tried to copy and umount from the console (as normal user), but I had the identical error message With Fedora 14 this did not happen
I'm seeing the same problem with Fedora 16. I make backups to a USB disk attached to my house server using rsync. The server is never logged in from its console, so X-server isn't used (the whole backup process is done by running bash scripts from the command line. The overall sequence looks like this: - plug the USB disk into a USB port - login as root via ssh from another Linux box running Fedora 15. - run a series of backups - logout of root - unplug the USB drive and put it back in its firesafe. Each backup is carried out by a bash script that does the following steps: - mounts the USB drive via its label - does the backup with rsync - obtains the device name with: usb_device=$(df | grep "$usb_disk" | cut -d' ' -f1) - unmounts the drive - runs fsck as: fsck $usb_device However, fsck always fails with a message saying that the disk is mounted, which it isn't, as running "ls -a /mountpoint" shows clearly that no filing system is mounted in that directory (it contains '.', '..' and nothing else. The hardware etc. details: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ w/4Gb RAM motherboard is a Gigabyte revision 0 GA-M68M-S2P Linux version 3.2.7-1.fc16.i686.PAE (mockbuild.fedoraproject.org) (gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) ) #1 SMP Tue Feb 21 01:30:59 UTC 2012
Created attachment 567719 [details] Full "sudo lshw" report for mcomment #1
try: (on a fully uptodate F16 x86_64, dont know about i686) systemctl disable cups.service and reboot. after that umount behaves normally again here. systemctl start cups.service is enough to get the umount problems back. I am using this small script using an USB memory stick (with LED :-) luks/ext4 on /dev/sdb1 No idea so far how cups prevents unmounting. by mere luck I had a spare identical system which was last updated on Mar 19 which behaved OK. Then I updated in small chunks and the problems become visible when cups update was involved..... grr. Hope this helps, Konrad ----- snip ----- #!/bin/bash echo "luksOpen..." echo -n somepassword |cryptsetup luksOpen /dev/sdb1 cmemstick ret=$? [ $ret -ne 0 ] && { echo "luksOpen fail"; exit 1; } echo "mount..." mkdir -p /a mount /dev/mapper/cmemstick /a || { echo "mount fail"; exit 1; } echo "copying..." date cp /tmp/somebigfile /a/foobar echo "umount..." date umount /a echo "luksClose..." date cryptsetup luksClose cmemstick || { echo "luksClose fail"; exit 1; } echo "dmsetup table..." dmsetup table |grep -w cmemstick echo OK
BTW, the problem was introduced between cups-1.5.2-1 (my previous installed version and cups-1.5.2-2 from koji. all later koji versions up to 1.5.2-8 from today cause the umount problems -k
Could this be related to bug #807672?
*** Bug 806909 has been marked as a duplicate of this bug. ***
Tim: it sounds pretty likely. Can those hitting this please try disabling PrivateTmp for cupsd - copy /lib/systemd/system/cupsd.service to /etc/systemd/system/cupsd.service and change PrivateTmp=yes to PrivateTmp=no in the copy in /etc - and see if that solves it? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Tim: note that wwoods was saying yesterday on IRC that he had weird issues with loop devices that went away when he killed cupsd, so that might be another consequence.
FWIW I changed the test update for cups (cups-1.5.2-8.1.fc16) earlier today so that it removes the PrivateTmp line altogether.
I've just tried again with on my Fedora 16 system, fully patched as of 2012-03-23 at approximately 19:00. This system does not a copy of cupsd.service, only cups.service and this does not contain a PrivateTmp property. There is nothing in /etc/sysconfig that would seem to be connected with CUPS As an elaboration of what I see at the point when fsck thinks the disk is busy: - My script starts by creating a directory in /mnt which I set to the same name as the partition label, i.e. Formac_1, and mounts the disk there, using the partition label to mount it, so the diskmis mounted as /mnt/Formac_1 - After the backup, the script unmounts the disk and deletes the directory it created using the command "rmdir Formac_1" before running fsck. After the failure the /mnt directory is empty, so the umount must have successfully disconnected the disk from the filing system or rmdir would have failed. Today the USB disk was mounted as /dev/sdc and, after fsck failed, both /dev/sdc and /dev/sdc1 were shown by "ls /dev/sd*". - At this point I unplugged the USB drive, waited 5 seconds, and plugged it in again. After this both /dev/sdc and /dev/sdc1 were no longer present and the disk had been recognised and attached as /dev/sdd with /dev/sdd1 as the partition. cfdisk showed it as expected (partition label Formac_1, partition size correct and fsck reported the disk as not having been unmounted cleanly, ran a check and didn't find any errors.
Martin: what does 'rpm -q cups' say?
*** Bug 808109 has been marked as a duplicate of this bug. ***
*** Bug 808121 has been marked as a duplicate of this bug. ***
Tim, 'rpm -q cups' says 'cups-1.5.2-1.fc16.i686'
Setting: PrivateTmp=false in: /lib/systemd/system/cups.service Had no effect on my system. kernel-PAE-3.3.0-4.fc16.i686 cups-1.5.2-6.fc16.i686
Martin Gregorie and Terry Barnaby seem to be seeing some other issue, whereas the PrivateTmp thing is certainly the cause of the issue Konrad Karl is seeing (cups-1.5.2-1.fc16 is the last version that did *not* have PrivateTmp=true). I was added in to this bug report in the last week, and now that I look at the date of the original report I can see that it pre-dates the PrivateTmp=true issue by quite some time. This suggests there is some other underlying issue to be discovered.
I agree, I believe the cups thing is just showing up a kernel bug. There is no way a process should be able to stop umount working correctly, at least I hope ! I remember I had a similar, but slightly different, issue with USB disks when I first installed F16. I suspect some kernel fixes/bugIntroductions is going on in this area ...
Tim: then should we un-dupe one of the 'dupes', make the other 'dupe' a dupe of that, and edit the update to say it fixes that bug, leaving this one open? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes. Resetting component back as it was before comment #3.
Another example (this time on Fedora 17) 20 minutes ago, I started copying 7gb of data into my new 32gb microsd card. After a few minutes KDE notification system told me the file transfer has been completed, but the led on sdcard reader indicated the opposite. Only a few minutes later, the led on card reader stopped bliking. So why KDE indicates the system finished the file transfer when it was not true?
Re comment #20, this is called a write cache. If you aren't getting the D-Bus error on unmount anymore, there's no bug!
*** Bug 826519 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.