Further to my recent post Intermittent USB3 Drive Mount, sadly I have to report that, after ten days of perfect operation, this morning once again the drive mount failed.

# dmesg | tail

[ 7659.848351] usb 2-3: Product: USB3.0 Hub             
[ 7659.848352] usb 2-3: Manufacturer: VIA Labs, Inc.         
[ 7659.852937] usb 2-3: Disable of device-initiated U1 failed.
[ 7659.856435] usb 2-3: Disable of device-initiated U2 failed.
[ 7659.856473] hub 2-3:1.0: USB hub found
[ 7664.860293] hub 2-3:1.0: config failed, can't read hub descriptor (err -22)
[ 7664.863787] usb 2-3: Set SEL for device-initiated U1 failed.
[ 7664.867279] usb 2-3: Set SEL for device-initiated U2 failed.
[ 8137.312105] usb 2-3: reset SuperSpeed USB device number 3 using xhci_hcd
[ 8137.559139] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800bc7e8a20

Power Control

Following the tack from last time, I once again checked the USB power control status:

# grep . /sys/bus/usb/devices/*/power/control

As before these were mostly set to auto, so I switched on again using the same command as before:

# for F in /sys/bus/usb/devices/*/power/control; do echo on >"${F}"; done
# grep . /sys/bus/usb/devices/*/power/control

Clearly I need a more permanent fix to that command.

Auto-Suspend

I also discovered two more settings:

# grep . /sys/bus/usb/devices/*/power/autosuspend

Apparently to switch off auto-suspend you should set the delay seconds to -1:

# for F in /sys/bus/usb/devices/*/power/autosuspend; do echo -1 >"${F}"; done
# grep . /sys/bus/usb/devices/*/power/autosuspend

To set this permanently I created a file /etc/modprobe.d/autosuspend.conf:

options usbcore autosuspend=-1

I came across Ubuntu Bug 1371233, in which there was a suggestion to try:

# echo -1 >/sys/module/usbcore/parameters/autosuspend

And on the same lines the suggestion to edit /etc/default/grub file and append to the GRUB_CMDLINE_LINUX_DEFAULT line:

usbcore.autosuspend=-1

Followed of course by the obligatory:

# update-grub

Power Level

You can also check your USB power levels:

# grep . /sys/bus/usb/devices/*/power/level

Mine were already all switched on, but if not:

# for F in /sys/bus/usb/devices/*/power/level; do echo on >"${F}"; done
# grep . /sys/bus/usb/devices/*/power/level

Back to Basics

Having run through all the above, I still could not see my drive. Unplugging and plugging it back in seems to have no reaction in the logs, suggesting that my drive is not being seen at all.

Re-plugging the USB hub seems to respond okay:

Nov 27 11:51:47 asusi5 kernel: [11372.680605] usb 1-3: USB disconnect, device number 2
Nov 27 11:51:47 asusi5 kernel: [11372.775937] usb 2-3: USB disconnect, device number 3
Nov 27 11:51:54 asusi5 kernel: [11379.603869] usb 1-3: new high-speed USB device number 7 using xhci_hcd
Nov 27 11:51:54 asusi5 kernel: [11379.733470] usb 1-3: New USB device found, idVendor=2109, idProduct=2812
Nov 27 11:51:54 asusi5 kernel: [11379.733478] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 27 11:51:54 asusi5 kernel: [11379.733482] usb 1-3: Product: USB2.0 Hub
Nov 27 11:51:54 asusi5 kernel: [11379.733486] usb 1-3: Manufacturer: VIA Labs, Inc.
Nov 27 11:51:54 asusi5 kernel: [11379.734284] hub 1-3:1.0: USB hub found
Nov 27 11:51:54 asusi5 kernel: [11379.734556] hub 1-3:1.0: 4 ports detected

But still plugging in the USB3 drive into that hub still has no effect.

Next I tried re-plugging the USB hub into a different USB3 port. This time when I plugged back in the USB drive - it was recognised and worked perfectly.

Conclusions

It could be that one of the above fixes only affects new devices (the auto-suspend probably), and that by choosing a different port it was recognised as a new device and therefore worked.

Equally there could be a hardware problem with the original USB port, perhaps the connector inside the case is a bit dodgy.

For now I will monitor the situation for another week or two and report back.

I have a problem with a Samsung M3 Portable USB3 external hard drive only working intermittently. I use a couple of these for off-site backups for work and so I need them working reliably. In fairness a reboot does cure the problem, but I hate that as a solution.

To troubleshoot this problem, the first step was to check the system devices:

# ls -al /dev/disk/by-id

But only my main two system drives were showing, and not the USB3 drive, which would have been sdc, being the third drive (a, b, c).

System Logs

The next step was to check the system logs:

# dmesg | tail

This showed no issues at all. Then I checked syslog:

# tail /var/log/syslog

This was completely empty, and had not been written to for almost a year. I can’t quite believe I haven’t needed to check the logs in all that time, but there you are.

I checked that rsyslogd was running and it was as user syslog. But the /var/log/syslog file was owned by root with group adm, but whilst syslog was a member of the adm group, the files all had user rw permissions only -rw-------.

This was easily fixed:

# chmod g+rw /var/log/*
# service rsyslog restart

Now the syslog file was being written to, but there was a problem writing to /dev/xconsole:

Nov 17 12:20:48 asusi5 rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="11006" x-info="http://www.rsyslog.com"] start
Nov 17 12:20:48 asusi5 rsyslogd: rsyslogd's groupid changed to 103
Nov 17 12:20:48 asusi5 rsyslogd: rsyslogd's userid changed to 101
Nov 17 12:20:48 asusi5 rsyslogd-2039: Could no open output pipe '/dev/xconsole': No such file or directory [try http://www.rsyslog.com/e/2039 ]
Nov 17 12:20:48 asusi5 rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="11006" x-info="http://www.rsyslog.com"] exiting on signal 15.

So I duly visited the link mentioned, which gave instructions for disabling /dev/xconsole, but this made me nervous and further research suggested that that was indeed the correct fix for headless servers, but possibly not for a desktop PC. Instead I used the following fix:

# mknod -m 640 /dev/xconsole c 1 3
# chown syslog:adm /dev/xconsole
# service rsyslog restart

USB Powersaving

Now at least it seems that my syslog is working correctly. Unfortunately unplugging and plugging in the USB drive still was not writing to the logs! When I plugged in the drive the blue light would flash repeatedly and then switch off. I would have believed that the drive had a fault, if it weren’t for the fact that rebooting the PC solves the problem.

Thinking that perhaps this problem was USB3 related, I decided to Google for “USB3 drive not recognised” which found this post. Except, that post was only relevant when operating on battery power, whereas I am using a plugged in desktop PC. Clearly that page could not be relevant? Except that in my notification area there is a battery icon, relating to my Uninterruptible Power Supply. But surely Ubuntu couldn’t be treating my UPS as if it were a battery? Could it?

In order to find out the power status of my USB devices I followed the suggestion of typing:

# grep . /sys/bus/usb/devices/*/power/control

Most were flagged as “on”, but a number of devices were flagged as “auto”. I decided to try switching them on to see if that made any difference:

# for F in /sys/bus/usb/devices/*/power/control; do echo on >"${F}"; done
# grep . /sys/bus/usb/devices/*/power/control

Now all the devices were showing as on. Time to try out the drive again - I unplugged it and plugged it back in again. This time the power light flashed repeatedly and then went solid.

Unfortunately the drive was still not mounted, but at least it was alive now. What next? Ah yes, I should check the logs to see if they have any new messages, now that the drive is powered and my logs are working:

# dmesg | tail
[15243.369812] usb 4-3: reset SuperSpeed USB device number 2 using xhci_hcd
[15243.616871] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff880213c71800

Faulty USB-SATA Bridge

At last I have something to go on. I searched for that error message, which took me to this Debian.net page, which suggested:

Reason is faulthy usb-sata bridge ASM1051 in USB3 drives. It has nothing to do with motherboards. See this. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9c54caa456dccba938005f6479892b589975e6a Workaround was made to kernel 3.17-rc5. Now those disks works. Some perfectly and some works but data transfer is not smooth.

Could that be my problem? I checked my current Kernel:

# uname -r
3.13.0-68-generic

So yes, it could be. As I cannot read the device yet, I cannot check whether ASM1051 is present in my USB3 drive.

Having uninstalled 34 obsolete kernels and a further 8 newer kernels that weren’t in use, I was in a position to install the latest Kernel from Vivid with:

# apt install linux-generic-lts-vivid

The problem of course is that in order to boot onto the newer Kernel I must reboot, thereby fixing the problem anyway.

And finally

It would be easy to portray this as clear evidence of the difficulty of running Linux, certainly Samsung will have thoroughly tested their drive on Windows and Mac operating systems. That said such problems are not unheard of on the more popular operating systems and debugging such problems is far harder, I would argue, than the above logical steps.

Having rebooted, as expected, the drive worked. I tried running lshw to see if ASM1051 was present, but I could not find it. Of course upgrading the Kernel could have fixed the problem anyway.

For the present I will labour under the comforting belief that the problem is fixed and will update this post again when either the problem reoccurs on in a week’s time if all is well!

• Please see Intermittent USB3 Drive Mount Continued…

As a died-in-the-wool KDE user, I’m just coming to terms with KDE4 and mostly loving it. A few niggles remain, but in the main it is very good indeed. But I suppose I would hesitate to recommend it to a new user. Having seen and heard much praise for the latest Ubuntu 10.04 Lucid Lynx, which uses the Gnome desktop, I thought I’d give it a go.

I started by downloading the ISO image from the Ubuntu website and followed my instructions to Make A Linux USB Key, basically by formatting in super-floppy format (which I find to be the most consistently successful method) and using Unetbootin to write the ISO to the USB Key. Using a USB key is more convenient, more portable and more environmentally friendly than burning a CD/DVD.

I took a spare laptop, an HP NX7300, and inserted the USB Key. I entered the BIOS settings and changed the boot order to boot first from USB. I then booted up the laptop.

HP are not know for their Linux compatibility, but Ubuntu booted up with an attractive boot splash, before logging straight into the very attractively themed Gnome desktop. The new colour scheme is purple, which is very attractive, although brown still exists in the OpenOffice splash screen to remind us of what used to be.

As expected, network manager failed to activate, and I knew from past experience that I would need to load the proprietary broadcom driver. Continuing to play it dumb, I waited to see if I would get any help from Ubuntu. After about half a minute, the restricted drivers’ manager appeared on the top panel, although there was no guidance as to why it had appeared, nor what to do with it. I clicked on it and then clicked on the option to install the Broadcom STR driver and clicked activate.

After a minute or so it had loaded the Broadcom driver from the USB stick and I noticed that the wireless light had illuminated on the laptop. Promising! Unfortunately it then suggested I reboot to load the new driver; which obviously I can’t do, as I am running off a USB stick and would effectively start from scratch again if I rebooted. I decided to just wait and, sure enough, after a while when I clicked on the wireless symbol on the top panel it offered my local wireless access point. I selected it, and entered the encryption key, and I was connected.

At this point I had a completely usable desktop environment, including a full office suite (OpenOffice.org), a working web browser (Firefox) and everything else you could possibly wish in a modern desktop environment, all working off a USB stick. I still find that just amazing.

I must admit that I am surprised by Gnome, it looks gorgeous, it feels very integrated, as if it had been designed as a whole, rather than being a collection of applications brought together. No it’s not my much loved Debian, and no it’s not my much loved KDE, but it does feel easy to use, very uniform and just… well “right”.

I was particularly impressed by Rhythmbox, which had the built in music store, podcast reader, and local collection. This does look like an application which would reassure an erstwhile iTunes user. It’s probably not as good as amaroK, but having pushed amaroK on my mother and regretted it mightily, I think Rhythmbox is a good choice, being infinitely more user friendly.

I even set-up my Gmail account in Evolution, simply by clicking on the mail icon in the top panel and following the wizard to set up my Gmail account. I played completely dumb, it provided all the necessary server information and network settings for me, and all I needed to know was my Gmail address and password. That is incredible, anyone could set up their email if it’s that easy.

Having tested it, just to decide whether to recommend it to friends and family, I find myself sorely tempted to install it on my own laptop.

The Shortcut

Try erasing the contents of your USB key, then skipping down to Install Unetbootin below. You could be lucky, and save yourself some fiddling about!

Step 1: Make sure that your USB key is unmounted

Open a terminal and type:

$ mount

This will list your current mounts, including your USB key (if mounted). Take a note of the mount point (e.g. /media/disk) and type:

$ sudo umount /media/disk

Once you are confident that the drive is not mounted, you may proceed.

Step 2: Determine the device

Find you USB key by typing:

$ sudo fdisk -l

Disk /dev/sdc: 64 MB, 64487424 bytes
4 heads, 32 sectors/track, 984 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Disk identifier: 0x5187ef1e

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1         983       62896    6  FAT16

Step 3: Delete the old partitions

This will lose any data on this drive!!!

Ignore the number after the letter, so in the above example the device is /dev/sdc, not /dev/sdc1; the 1 is partition 1, but fdisk works on the whole drive, not just a single partition.

$ sudo fdisk /dev/sdX

Command (m for help):

• Type “p” and enter to view the existing partitions (generally only one)
• Type “d” and enter to delete the partition (if there are multiple partitions, you may need to enter 1 for the first)
• Type “p” to view the remaining partitions (there should not be any!)

At this point, nothing has really happened, you can “q” to quit and nothing will have been touched.

Step 4: Create the new partition

• Type “n” to make a new partition
• Type “p” to make this partition primary and press enter
• Type “1” (one) to make this the first partition and then press enter
• Press [enter] to accept the default first cylinder
• Press [enter] again to accept the default last cylinder
• Type “p” to view what you have done

This should display the current configuration of your drive:

Disk /dev/sdc: 64 MB, 64487424 bytes
4 heads, 32 sectors/track, 984 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Disk identifier: 0x5187ef1e

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         984       62960   83  Linux

Step 5: Change partition to W95 Fat32

• Type “t” to change type
• Type “b” for Win95 Fat32
• Type “p” to view what you have done

Step 6: Make partition bootable

• Type “a” to add bootable flag
• Type “1” (one) to select first partition
• Type “p” to view what you have done

Step 7: Write partition changes

Up to this point, nothing has actually been changed; if you are happy with the changes you have made, then:

• Type “w” to write the new partition information to the USB key

Step 8: Format the partition

The final step is to create the fat filesystem:

Note that this time we DO quote the partition number

$ sudo mkfs.vfat -F 32 /dev/sdx1

This process ends by sync’ing the disk.

Step 9: Mount the USB key

For most systems, this can be easily achieved by simply unplugging and replugging in the key, and taking option to Mount when prompted. Equally you can mount manually by typing:

Change “mountpoint” below for an appropriate name

$ sudo mkdir /mnt/mountpoint
$ sudo mount /dev/sdx1 /mnt/mountpoint

Step 9: Install Unetbootin

$ sudo aptitude install unetbootin

Step 10: Use Unetbootin

Run Unetbootin from your menu, either select a distribution and version, or take the option to install an already downloaded disk image.

Next select the usb drive.

Given the tiny size of my USB key, I am using slitaz, which is a minimal distribution.

Have a look at the contents of the USB drive, in at least one test, unetbootin had only copied a single file across. Just run unetbooting again if that happens.

Step 11: Reboot and Test

That’s it, you should now be able to reboot onto the drive.

Step 12: Troubleshooting

My first attempt was using FAT32, which did not work. Next I tried FAT16, which also did not work, then I tried EXT2, by change partition type to “83 Linux” and then typing the following command (replacing the “x” for your correct drive letter):

$ sudo mkfs.ext2 /dev/sdx1

This time the USB key was detected as USB-HDD and booted perfectly. It does seem that everyone’s has different experiences, and there is an element of trial and error to get things working.

If you have a usb key over 512mb and are using FAT32, then you might try reducing the size of the partition to 512k, and create a second partition with the remaining space.

See Alternative Methods for other options.

Step 13: Superfloppy

I understand that the problem with USB booting, is that many BIOS’s understand the superfloppy format - i.e. a formatted but unpartitioned drive. This is easy enough to create under Linux, simply delete the partitions in fdisk and format with:

# mkdosfs -I /dev/sdx

or possibly on older hardware:

# mkdosfs -v -F 16 -I /dev/sdx

The problem is that superfloppies will not be auto-mounted under Linux, with the result that Unetbootin cannot write to them. But you can mount superfloppies manually:

$ cd /media
$ sudo mkdir sdx
$ sudo mount /dev/sdx sdx

Then use unetbooting to write to /dev/sdx, and not forgetting to umount afterwards:

$ sudo sync
$ sudo umount sdx

Alternative Methods

Some distributions offer their own USB key creation software, including Ubuntu 8.10+, PuppyLinux 4.10+, and Slitaz, to name but a few.

Also, it is possible to obtain disk images that can be written to a usb key directly, thus circumventing these problems. For example:

• Debian Installer
• Debian Live

References

• Install a Live Ubuntu image on a USB stick
• PenDriveLinux
• Installing Debian Sarge from a USB memory stick
• Debian Wiki USB Boot
• Debian EeePC Install