You are not logged in.
I formatted and created lvm volumes (physical and logical) on a new extern (USB) hard drive from my raspberry pi, which is running archlinuxarm. When I attach the hard drive to my main archlinux machine, running vgscan and then "vgchange -a y" makes the volumes visible, however I can't mount them:
mount: /dev/mapper/vgBigBook-lvmedia: can't read superblock# fdisk -l
...
fdisk: cannot open /dev/mapper/vgBigBook-lvmedia: Input/output errorlsusb does show correctly the drive:
Bus 002 Device 013: ID 1058:1140 Western Digital Technologies, Inc. My Book Essential USB3.0
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x1058 Western Digital Technologies, Inc.
idProduct 0x1140 My Book Essential USB3.0
bcdDevice 10.16
iManufacturer 1 Western Digital
iProduct 2 My Book 1140
iSerial 5 5743415A414A343436343137
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 44
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 USB Mass Storage
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 6 MSC Bulk-Only Transport
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
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 0x00000002
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 32 micro seconds
Device Status: 0x0001
Self Poweredany ideas?
Last edited by Nareto (2013-04-24 15:04:54)
Offline
this is getting very frustrating... journalctl gives this when I plug in the drive and try to access it (for example by running "fdisk -l").
On my laptop instead (which is also an up-to-date archlinux 64bit) I still get the "No caching mode page present" error but not the "buffer I/0 error", and *most* of the times I've been able to correctly mount it - not allways though, sometime it behaves exactly as on my desktop.
I tried uninstalling udiskie and udisks which weren't working no more anyway, to take away a layer of complexity, but still after a reboot I'm in the same situtation.
Maybe I should mention the hard drive is USB3 and is self-powered through its own power supply plugged in the electrical outlet. I tried various USB3 and USB2 ports on my desktop without change, while my laptop only has USB2 (and the inconsistent behaviour on the laptop was with the drive allways plugged in the same port)
Offline
I though maybe it has something to do with the fact that the raspberry pi has little RAM and I used it to partition and mkfs.ext4 large partitions - I did get some errors about memory, which I can't remember now. Anyhow I'm reformatting the drive from the desktop and will see if it works
Offline
I had some weird behaviour - even after reformatting at first I got same types of errors... in the end though (after quite some trials) it's working - I think the turning point was deleting the old volume groups, reformatting, creating new ones with different names, rebooting and then creating the logical volumes, formatting them, and running fsck to check they're ok... Again I'm not sure what, but something in that list of actions made it work.
Offline