2

I have an old Maxtor USB 250GB external drive I'm trying to use on the Raspberry Pi 2 running Raspbian. It has the latest updates, upgrades and firmware.

root@raspberrypi:~# uname -a
Linux raspberrypi 4.0.6-v7+ #799 SMP PREEMPT Fri Jun 26 15:50:02 BST 2015 armv7l GNU/Linux

My goal is to format the drive to use it as ext4, but I'm having troubles along the way with error messages. I have connected the drive to Dell server running CentOS 6 and don't have any problem with it there, but I do on the Raspberry Pi 2. Here is an example of what is happening...

I reconnected the drive to the pi. I powered it up and so far the dmesg output looks good:

[28642.569595] usb 1-1.2: new high-speed USB device number 5 using dwc_otg
[28642.670536] usb 1-1.2: New USB device found, idVendor=0d49, idProduct=7000
[28642.670561] usb 1-1.2: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[28642.670578] usb 1-1.2: Product: OneTouch
[28642.670594] usb 1-1.2: Manufacturer: Maxtor
[28642.670610] usb 1-1.2: SerialNumber: XXXXXXXX    
[28642.671859] ums-onetouch 1-1.2:1.0: USB Mass Storage device detected
[28642.672627] input: Maxtor OneTouch as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/input/input1
[28642.673106] scsi host1: usb-storage 1-1.2:1.0
[28643.875946] scsi 1:0:0:0: Direct-Access     Maxtor   OneTouch         0200 PQ: 0 ANSI: 0 CCS
[28643.877462] sd 1:0:0:0: Attached scsi generic sg0 type 0
[28643.878482] sd 1:0:0:0: [sda] 490232832 512-byte logical blocks: (250 GB/233 GiB)
[28644.085084] sd 1:0:0:0: [sda] Write Protect is off
[28644.085124] sd 1:0:0:0: [sda] Mode Sense: 1c 00 00 00
[28644.291701] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[28645.356829] sd 1:0:0:0: [sda] Attached SCSI disk

Now let's see what fdisk has to say about the drive:

root@raspberrypi:/home/pi# fdisk -l

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa6202af7

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    15523839     7700480   83  Linux

Disk /dev/sda: 251.0 GB, 250999209984 bytes
255 heads, 63 sectors/track, 30515 cylinders, total 490232832 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x762f6146

**Disk /dev/sda doesn't contain a valid partition table**


root@raspberrypi:/home/pi# fdisk /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x8b811c4f.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/sda: 251.0 GB, 250999209984 bytes
255 heads, 63 sectors/track, 30515 cylinders, total 490232832 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8b811c4f

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 
Using default value 1
First sector (2048-490232831, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-490232831, default 490232831): 
Using default value 490232831

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

Error closing file

If I do the above to a USB thumb drive, I don't get any of the bolded errors above. When I connect the drive to a Dell server/CentOS and do this, I don't get errors about closing the file.

I don't know what else to do at this point. So I will proceed with doing a mkfs, maybe that will fix it? Just wishing thinking. :-)

root@raspberrypi:/home/pi# mkfs.ext4 /dev/sda1
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
15327232 inodes, 61278848 blocks
3063942 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1871 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

I guess that looks OK, I don't know if the number of Superblock backups matters or not?

Let's mount it, see what the deal is now.

root@raspberrypi:/home/pi# mount -t ext4 /dev/sda1 /mnt
root@raspberrypi:/home/pi# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  2.6G  4.3G  38% /
devtmpfs        459M     0  459M   0% /dev
tmpfs            93M  244K   93M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           186M     0  186M   0% /run/shm
/dev/mmcblk0p1   56M   20M   37M  35% /boot
/dev/sda1       230G   60M  219G   1% /mnt
root@raspberrypi:/home/pi# grep sda1 /etc/mtab
/dev/sda1 /mnt ext4 **ro**,relatime,data=ordered 0 0

It's read-only. This is what is happening. I can cd to this drive and try to write to it, but it gives an error that it is read-only. Sometimes after it is mounting it is "rw" but only for a short period of time, like a minute.

Here is the updated dmesg:

[29114.978050]  sda: sda1
[29114.979357] blk_update_request: critical target error, dev sda, sector 0
[29363.970597] blk_update_request: critical target error, dev sda, sector 0
[29363.996206] blk_update_request: critical target error, dev sda, sector 0
[29476.782828] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[29480.273343] blk_update_request: critical target error, dev sda, sector 0
[29485.304704] blk_update_request: critical target error, dev sda, sector 243533848
[29485.304763] Aborting journal on device sda1-8.
[29485.593418] EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal
[29485.605341] EXT4-fs (sda1): Remounting filesystem **read-only**

This is where I end up. As odd is it seems, if I connect it to the Mac and use Disk Utility I can format and write to the drive as Mac format of FAT32 and on the Dell server/CentOS without a problem.

Is this the drive? Is this the Raspberry Pi 2's Raspbian OS? I have seen postings at the link below that it might be a bug. But it seems like there would be more information or an update about it by now?

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=103177

Edward_178118
  • 209
  • 3
  • 9
  • First, put max_usb_current=1 in /boot/config.txt if you have not yet (see here), reboot, and make sure you are using at least a 2 amp power supply. You need to rule out this issue before you proceed. – goldilocks Jun 28 '15 at 15:27
  • 1
    I'm using a "EasyAcc® US 5V 2A Micro USB Wall Charger" for power. The Maxtor 250GB drive gets it's power from AC. How does it know to equate max_usb_current to anything? – Edward_178118 Jun 28 '15 at 15:34
  • I've added max_usb_current=1 in /boot/config.txt. I'm still having the same problem with the same error messages. Would using another OS (which one?) on the Raspberry Pi 2 help trouble-shoot this further? – Edward_178118 Jun 28 '15 at 15:38
  • Okay -- I didn't want to bother asking "How are you powering the drive?" so I just skipped to that suggestion. You're right, it doesn't matter in this case, but now we have ruled out power as an issue. – goldilocks Jun 28 '15 at 16:16

1 Answers1

1

Based on this bug report, you may be able to work around the problem for your Maxtor drive (it is referred to specifically in post #34 of that report) by adding a file to /etc/modprobe.d containing:

options usb-storage quirks=0d49:7010:uw
# See below:               ^^^^^^^^^

The filename may have to end with .conf and it should be owned root (you can't create anything there non-root anyway). Note the hexadecimal id string I've indicated (and don't actually include that ^^^^ line in the file). If you have the exact same drive, this string is probably the same, but you should check first with lsusb, which should include a line clearly identifying the drive including a hex string like that one (four digits:four digits). Use that if it is different.

You will have to reboot to make this effective.

I presume you don't have anything important on the drive right now, since you were trying to format it. If otherwise, make sure you have that stuff backed up before you proceed, since this is a kernel bug. If this fix appears to work, you are probably good to go; the posts about that are from March and there have not been any qualifications added since then.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • 1
    Thanks for the info. I think you mean /etc/modprobe.d and not /etc/modules.d. I did the lsusb, and my drive is a 7000 instead of the 7010, even though I did make the change and reboot. I'm still having the same issues though. If this is a kernel bug, and since this drive is old, I'm going to hazard a guess that there is an incompatibility with this old Maxtor drive in the current OS. I'm going to try this with Pidora since it is also a different Kernel version so it might work. I'm still new to the Raspberry Pi, where is the best place to report my findings? – Edward_178118 Jun 28 '15 at 17:36
  • Yeah, whoops, that should have been modprobe.d, fixed. WRT pidora, the current kernel there is I think 3.12, so if this bug was introduced in 3.13, it should be okay. You could also transplant that kernel into Raspbian, or sift through the revision history here to find one there. – goldilocks Jun 28 '15 at 17:52
  • 1
    Pidora apparently doesn't have a build for the raspberry pi 2. So that's not an option at the moment. I tried Snappy Ubuntu, but the Kernel is 3.16 and it has the same problem but with more verbose error messages. – Edward_178118 Jun 29 '15 at 11:01