Comment # 21 on bug 1021325 from 
When I came back home tonight, there was a kernel update waiting for me (to
4.4.46-11.1) so I did a few experiments, switching the USB connectors around,
with success but not immediately. I'll detail them below.

All changes were made while the GRUB bootup menu (to select one of several
possible kernels) was displayed, but after moving the selection bar to defeat
the timeout, and leaving it to the kernel I intended to boot (the new
kernel-default; if it hadn't worked at all I would have tried booting the
kernel-vanilla instead, and then looked for something else to try).

There are 4 USB slots on the front face of my computer, and some more on the
back face. Only the front ones are relevant here, I'll call them A, B, C, D
from right to left. IIUC A and B are on one hub and C and D on a different hub.

Originally they were plugged as follows:
A: mouse
B: keyboard
C: my drive, with a swap partition (for emergencies) and a data partition
D: a bootable 42.2 DVD-image on USB

Experiment 1: Boot the new kernel-default with no change.
Result 1: No joy. Both USB drives still end up disconnected, "parted -l" sees
only the hard disk inside the computer box, as /dev/hda.

Experiment 2: swap B and C. I now have A=mouse, B=mine, C=KB, D=DVD
Result 2: my drive (on slot B) is now recognised as /dev/sdb. DVD (unmoved on
D) is still disconnected.

Experiment 3: put them A=mine, B=DVD, C=KB, D=mouse
Result 3: Now the DVD (on B) is recognised as /dev/sdb but my disk (on A) is
disconnected.

Experiment 4: A=KB, B=mine, C=DVD, D=mouse
Result 4: Success! Now the "DVD" (on C) is seen as /dev/sdb and my disk (on B)
as /dev/sdc.

Next time I boot I'll try swapping both USB disks and see if slot C ends up on
/dev/sdb. Not urgent because my /etc/fstab mounts "my" drive by id and by label
and doesn't mount the other by default, but my sense of elegance will be more
satisfied if the partition mounted on /mnt/sdb1 happens to sit on drive sdb
rather than sdc.

The kernel I had until a day or two before comment #0 has been uninstalled as
part of this upgrade-and-reboot, and I don't intend to fetch it back (unless
you tell me to). The kernels now installed on my system are kernel-default,
kernel-debug and kernel-vanilla for versions 4.4.46-11.1 and 4.4.36-8.1. IIUC
the last kernel where I didn't have the problem before opening this bug was a
4.4.36-5.1 kernel-default. My policy is to always set the newest kernel-default
as boot default in the "Advanced" submenu of the GRUB bootloader.

Oliver: I'm not setting this bug to WORKSFORME because I have treated only
symptoms, not the underlying problem; you may want either to investigate some
more by telling me what to test (and in due course make the bug ASSIGNED) or
decide that the game is not worth the candle and RESOLVE WORKSFORME yourself
(in which case I won't fight it).

You are receiving this mail because: