Activity log for bug #1072351

Date Who What changed Old value New value Message
2012-10-28 13:25:27 Thomas Bernard bug added bug
2012-10-29 15:54:51 Thomas Bernard description Description: Ubuntu 12.04.1 LTS Release: 12.04 Kernel: 3.2.0-32-generic-pae (Distribution: Lubuntu) Package: libmtp9 - Media Transfer Protocol (MTP) library Version: 1.1.3-1ubuntu0.1 Hardware: Desktop PC, rather new Hi folks, I just want to tell you how I spend the last two days: I have Lubuntu 12.04 installed and it works fine for a while despite a warning message on every boot. I don't remember the whole msg exactly, but it looked like this: "mtp-probe: checking bus X, device XX: "/sys/devices/pci0000:00/0000...usbX/X-X - No such file or directory" The X represents some digits respectively. While booting with an USB stick attached the msg showed up two times, without USB stick just one time. What expected to happen: No error msg at boot time, full access to USB sticks without problems What happened: Two days ago I tried to copy a (relatively) large amount of data at once onto an 4GB USB stick with a FAT32 filesystem (which is no mtp device, obviously). After 165 MB had been copied the system did not responds anymore. There were more than 3GB of free space left, so I was wondering, what happened. It wasn't freezed, because Conky still worked. But no reaction on mouse/keyboard input. I tried to change to tty1, tty2 and so on - no success. The LED of the stick flickered like crazy - nothing else. I was not be abel to do any thing, except for having a beer... I was waiting until the beer was finished, then I decided to hard resetting the machine. While rebooting the computer stopped at the BIOS boot screen (the USB stick was still in place and doesn't stop to flicker). So I removed the stick and did a reset again. The computer starts normally, the warning msg still comes up. Then I plugged in the USB stick, it was reckognized and the system asked if it should open the drive with the file manager. I pressed okay - the system denied cooporation immediately. I tried it several times with always the same result - a non-respondig system. Sometimes it freezed (Conky clock stood still, CPU graphs even), sometimes just no response. What gaves me a hint: I tried a lot of things to access the stick. Then I startet the system with root console only and attached the stick. But first I had to edit /etc/default/grub and invoke update-grub to be able to access the console by avoiding to enter the graphic environment first (see post scriptum). This gaves me the first clue what happened: when I plugged in the USB stick mtp-probe tried to access the device and stopped with no success, but didn't exit. Pressing CTRL-C terminates the programm and the system works. I guess, the same thing happened before behind the scenes, but pressing CTRL-C won't affect a program that runs in the background of a graphic environment. I still believed my usb stick was damaged, so I run Photorec_static to save my data. This program had no problems to access the whole drive. So I further searched the net and found a lot of bug reports in 2011 complaining about similiar issues and eventually I had been pointed to libmtp9. Solution I deinstalled libmtp9 and that solved all of the problems - almost. Without libmtp9 I was be able to mount the USB stick and access all of the data with no problems. The warning message at boot time doesn't shows up anymore. Two files were left that I couldn't delete from the stick. A message told me, the filesystem would be read only. That are the files where the copy process stopped. Well, that is another pair of shoes, but since I was be able to read all the data (and delete all other files) I copied the content of the stick to the harddrive and invoked mkfs.vfat to build a new partition. Now the stick works fine again, the warning message at boot time is gone and I'm lucky that nothing worse happened. Conclusion I don't know if libmtp9 is necessary or even essential to access certain devices. But I know what it does to me and from now on I will consider this whole program as a bug, since this issue is not new and a year ago they said it has been fixed. It isn't, obviously. Fortunately its encapsulated into a package and I hope I will always remember to remove it ( as well as the packages belonging to libmtp9: libmtp-runtime, libmtp-common) from my system before I'm going to work with it seriously. Best regards, Tom PS: Furthermore, this story tells me, that it isn't a good idea to set GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true which is the standard setting in (L)Ubuntu, since this makes it hard to maintain the system in case of an issue like described above. At least GRUB_HIDDEN_TIMEOUT should have a value of 5 to be able to access the GRUB boot menu by pressing SHIFT, e.g. to access the root console without entering the graphic environment at first. However, I commented out both lines and set "noplymouth" as kernel boot parameter in order to see, what happens at boot time. That seems to be at least recommendable. Description: Ubuntu 12.04.1 LTS Release: 12.04 Kernel: 3.2.0-32-generic-pae (Distribution: Lubuntu) Package: libmtp9 - Media Transfer Protocol (MTP) library Version: 1.1.3-1ubuntu0.1 Hardware: Desktop PC, rather new Hi folks, I just want to tell you how I spend the last two days: I have Lubuntu 12.04 installed and it works fine for a while despite a warning message on every boot. I don't remember the whole msg exactly, but it looked like this: "mtp-probe: checking bus X, device XX: "/sys/devices/pci0000:00/0000...usbX/X-X - No such file or directory" The X represents some digits respectively. While booting with an USB flash drive attached the msg showed up two times, without it just one time. What expected to happen: No error msg at boot time, full access to USB flash drives without problems What happened: Two days ago I tried to copy a (relatively) large amount of data at once onto a 4GB USB flash drive with a FAT32 filesystem (which is no mtp device, obviously). After 165 MB had been copied the system did not responds anymore. There were more than 3GB of free space left, so I was wondering, what happened. It wasn't freezed, because Conky still worked. But no reaction on mouse/keyboard input. I tried to change to tty1, tty2 and so on - no success. The LED of the flash drive flickered like crazy - nothing else. I was not be abel to do any thing, except for having a beer... I was waiting until the beer was finished, then I decided to hard resetting the machine. While rebooting the computer stopped at the BIOS boot screen (the USB flash drive was still in place and doesn't stop to flicker). So I removed it and did a reset again. The computer starts normally, the warning msg still comes up. Then I plugged in the device, it was reckognized and the system asked if it should open the drive with the file manager. I pressed okay - the system denied cooporation immediately. I tried it several times with always the same result - a non-respondig system. Sometimes it freezed (Conky clock stood still, CPU graphs even), sometimes just no response. What gaves me a hint: I tried a lot of things to access the flash drive. Then I startet the system to the root console only and attached the device. But first I had to edit /etc/default/grub and invoke update-grub to be able to access the console by avoiding to enter the graphic environment first (see post scriptum). This gaves me the first clue what happened: when I plugged in the USB flash drive mtp-probe tried to access the device and stopped with no success, but didn't exit. Pressing CTRL-C terminates the programm and the system works. I guess, the same thing happened before behind the scenes, but pressing CTRL-C won't affect a program that runs in the background of a graphic environment. I still believed my USB flash drive was damaged, so I run Photorec_static to save my data. This program had no problems to access the whole drive. So I further searched the net and found a lot of bug reports in 2011 complaining about similiar issues and eventually I had been pointed to libmtp9. Solution I deinstalled libmtp9 and that solved all of the problems - almost. Without libmtp9 I was be able to mount the drive and access all of the data with no problems. The warning message at boot time doesn't shows up anymore. Two files were left that I couldn't delete. A message told me, the filesystem would be read only. These are the files where the copy process stopped. Well, that is another pair of shoes, but since I was be able to read all the data (and delete all other files) I copied the content to the harddrive and invoked mkfs.vfat to build a new partition. Now the drive works fine again, the warning message at boot time is gone and I'm lucky that nothing worse happened. Conclusion I don't know if libmtp9 is necessary or even essential to access certain devices. But I know what it does to me and from now on I will consider this whole program as a bug, since this issue is not new and a year ago they said it has been fixed. It isn't, obviously. Fortunately its encapsulated into a package and I hope I will always remember to remove it ( as well as the packages belonging to libmtp9: libmtp-runtime, libmtp-common) from my system before I'm going to work with it seriously. Best regards, Tom PS: Furthermore, this story tells me, that it isn't a good idea to set GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true which is the standard setting in (L)Ubuntu, since this makes it hard to maintain the system in case of an issue like described above. At least GRUB_HIDDEN_TIMEOUT should have a value of 5 to be able to access the GRUB boot menu by pressing SHIFT, e.g. to access the root console without entering the graphic environment at first. However, I commented out both lines and set "noplymouth" as kernel boot parameter in order to see, what happens at boot time. That seems to be at least recommendable.
2012-11-04 11:10:23 Thomas Bernard branch linked lp:ubuntu/precise/libmtp
2012-11-17 12:12:16 Thomas Bernard summary USB stick attached and libmtp9 causes the whole system to deny cooperation USB thumb drive attached and libmtp9 causes the whole system to deny cooperation