Nope, my speculation is definitely wrong. The disk shows up in lsscsi: [anovak@octagon ~]$ lsscsi ... [9:0:0:0] disk Seagate Backup+ Hub BK D781 /dev/sdb
Also, it shows up in lsusb -t with a "uas" driver. Maybe the problem is the uas driver itself? Here's the full description of the USB device, if that helps: [anovak@octagon ~]$ sudo lsusb -v -d 0bc2:ab38 Bus 001 Device 008: ID 0bc2:ab38 Seagate RSS LLC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bc2 Seagate RSS LLC idProduct 0xab38 bcdDevice 1.00 iManufacturer 2 Seagate iProduct 3 Backup+ Hub BK iSerial 1 NA8TQC87 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 85 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Command pipe (0x01) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x0000f41e Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0001 Self Powered ** Also affects: hdparm (Ubuntu) Importance: Undecided Status: New ** Also affects: zfs-linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1774569 Title: gsmartcontrol, hdparm, and ZFS all refuse to talk to an apparently working Seagate Backup+ Hub drive after upgrade to 18.04 Status in gsmartcontrol package in Ubuntu: New Status in hdparm package in Ubuntu: New Status in zfs-linux package in Ubuntu: New Bug description: I recently upgraded from 17.10 to 18.04. After the upgrade, I noticed that my Seagate Backup+ Hub external drive was displaying a series of puzzling symptoms: 1. gsmartcontrol can't get SMART data from the drive. I am pretty sure it used to report SMART data? Here's a log of it not working: <warn> [hz] Warning: exit: Command line did not parse. <warn> [app] execute_smartctl(): Smartctl binary did not execute cleanly. <warn> [app] StorageDevice::execute_device_smartctl(): Smartctl binary did not execute cleanly. <warn> [app] SmartctlParser::parse_section_info_property(): Unknown property "Physical block size" <warn> [app] SmartctlParser::parse_section_info_property(): Unknown property "Logical Unit id" <warn> [app] SmartctlParser::parse_section_info_property(): Unknown property "Temperature Warning" <warn> [app] SmartctlParser::parse_section_data(): Unknown Data subsection encountered. <warn> [hz] Warning: exit: Some SMART command to the disk failed, or there was a checksum error in a SMART data structure <warn> [app] SmartctlParser::parse_section_info_property(): Unknown property "Physical block size" <warn> [app] SmartctlParser::parse_section_info_property(): Unknown property "Logical Unit id" <warn> [app] SmartctlParser::parse_section_info_property(): Unknown property "Temperature Warning" <warn> [app] SmartctlParser::parse_section_data(): Unknown Data subsection encountered. 2. hdparm used to be able to spin down the drive. I had it configured to spin it down after a few minutes of inactivity, in the hdparm config file. Now that no longer happens, and hdparm can't seem to talk to the drive meaningfully at all: [anovak@octagon ~]$ sudo hdparm -I /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ATA device, with non-removable media Standards: Likely used: 1 Configuration: Logical max current cylinders 0 0 heads 0 0 sectors/track 0 0 -- Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 0 MBytes device size with M = 1000*1000: 0 MBytes cache/buffer size = unknown Capabilities: IORDY not likely Cannot perform double-word IO R/W multiple sector transfer: not supported DMA: not supported PIO: pio0 [anovak@octagon ~]$ sudo hdparm -y /dev/sdb /dev/sdb: issuing standby command SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think this may be related to https://askubuntu.com/questions/1037997 /upgraded-to-18-04-usb-harddrive-doesn-t-idle-anymore which is someone else having the same problem. 3. The ZFS tools think the drive is hosed: [anovak@octagon ~]$ sudo zpool status hub pool: hub state: UNAVAIL status: One or more devices could not be used because the label is missing or invalid. There are insufficient replicas for the pool to continue functioning. action: Destroy and re-create the pool from a backup source. see: http://zfsonlinux.org/msg/ZFS-8000-5E scan: none requested config: NAME STATE READ WRITE CKSUM hub UNAVAIL 0 0 0 insufficient replicas ata-ST6000DM003-2CY186_ZF200PC8 UNAVAIL 0 0 0 This may be related to the drive having adopted a new /dev/disk/by-id name during the upgrade? I think it was "ata- ST6000DM003-2CY186_ZF200PC8" when I added it to my zpool by its symlink under /dev/disks/by-id, but now it is "usb- Seagate_Backup+_Hub_BK_NA8TQC87-0:0": [anovak@octagon ~]$ ls -lah /dev/disk/by-id/usb-Seagate_Backup+_Hub_BK_NA8TQC87-0\:0 lrwxrwxrwx 1 root root 9 May 31 20:52 /dev/disk/by-id/usb-Seagate_Backup+_Hub_BK_NA8TQC87-0:0 -> ../../sdb This *shouldn't* cause trouble; you should be able to export the zpool and re-import it under the new name. But zpool import shows nothing to import: [anovak@octagon ~]$ sudo zpool import no pools available to import And I also can't export or even destroy the busted zpool, because zpool doesn't think it exists for exporting or destroying purposes: [anovak@octagon ~]$ sudo zpool export hub cannot export 'hub': no such pool or dataset [anovak@octagon ~]$ sudo zpool destroy hub cannot destroy 'hub': no such pool or dataset 4. The weirdest thing is that the drive itself seems to be working correctly. I see /dev/sdb1 and /dev/sdb9, as expected for a ZFS drive. I can `cat /dev/sdb1 | xxd | less` and see the data stored on the drive, including what I think is the ZFS label (at 0x4000, with a bunch of ZFS-y strings in it) that zpool is upset about not seeing. I see the partitions in `gparted` just fine, too; there's no indication that there's anything wrong with the partition table. Even the device's integrated USB hub seems to be working fine. This is definitely not a hard drive failure. If I had to speculate, I would guess that the drive is being treated as a generic USB mass storage device now, when it used to be being handled as a SATA device in a USB-to-SATA enclosure (which I think it is). That would explain the name change, and the difficulty that hdparm and gsmartcontrol have in talking to it. The ZFS weirdness with not being able to export/destroy the pool has to be another issue; it happens even when the drive is disconnected from the system entirely. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gsmartcontrol 1.1.3-1 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu May 31 20:46:52 2018 InstallationDate: Installed on 2017-08-06 (298 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gsmartcontrol UpgradeStatus: Upgraded to bionic on 2018-05-29 (3 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gsmartcontrol/+bug/1774569/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp