
On 2017-04-20 10:33, Oliver Neukum wrote:
Am Donnerstag, den 20.04.2017, 00:18 +0200 schrieb Stefan Bruens:
On Mittwoch, 19. April 2017 19:43:54 CEST Carlos E. R. wrote:
On 2017-04-19 17:49, Brüns, Stefan wrote:
On Mittwoch, 19. April 2017 12:02:42 CEST Carlos E. R. wrote:
[10513.194995] sd 6:0:0:0: [sdb] No Caching mode page found 2017-04-18T16:35:04.755846-03:00 linux-turion64 kernel: [10513.194998] sd 6:0:0:0: [sdb] Assuming drive cache: write through The log stops there, there is no partition, and the desktop can not see anything. The problem is in the kernel side if the above cut is all.
You better read the whole log: 2017-04-18T15:28:38.579746-03:00 linux-turion64 kernel: [ 6526.777400] sd 6:0:0:0: [sdb] Assuming drive cache: write through 2017-04-18T15:28:38.609581-03:00 linux-turion64 kernel: [ 6526.804888] sdb: sdb1 < sdb5 sdb6 > sdb2
That's a different phase. When the partitions are not seen at the point I marked on the log, the desktop doesn't see the disk. It has happened to me at times, but reconnecting the disk solves the issue. At worst, a reboot.
So obviously there *is* a partition table, detected by the kernel. Likely the next line of the truncated log would show the partition table again.
He said no.
Android phones can expose themselves as either mass storage devices (this is limited to the SD card) or MTP device (allowing access to both internal flash and SD cards), some also as PTP (digital camera) device. MTP and PTP are not handled by the kernel.
This part was a plain hard disk, not a phone. The phone was a second log.
Hi,
true, but why does the HDD fail? We need to have a closer look.
On a following post he said the issue got solved on the next snapshot :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)