The device on /dev/sdx is not created when inserting new devices

[Joan]

I am on kubuntu xenial (upgraded from 15.10), from a couple of weeks I noticed that the pendrives i insert to my computer are detected but the devices under /dev are no longer created.
I if reboot the pc with the pendrive already plugged in it works without issues. I'm suspecting from udev because of this text in syslog (full output in the summary)

Jun 7 15:02:55 pc systemd-udevd[24747]: inotify_add_watch(9, /dev/sdb, 10) failed: No such file or directory

I'm up to date on all the packages
- linux-image-4.4.0-22-generic
- udev - 229-4ubuntu6
---
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: jjuvanteny 2047 F.... pulseaudio
 /dev/snd/pcmC1D0p: jjuvanteny 2047 F...m pulseaudio
 /dev/snd/controlC1: jjuvanteny 2047 F.... pulseaudio
CurrentDesktop: KDE
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=120e7a9e-4193-4d2d-a46e-6fdf0fa5b16c
InstallationDate: Installed on 2015-03-27 (439 days ago)
InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Beta amd64 (20150326)
MachineType: LENOVO 20DF004USP
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic root=UUID=c62be6bc-f11b-4970-8ee1-976bf2e7fb9d ro quiet splash
ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-22-generic N/A
 linux-backports-modules-4.4.0-22-generic N/A
 linux-firmware 1.157
Tags: xenial
Uname: Linux 4.4.0-22-generic x86_64
UpgradeStatus: Upgraded to xenial on 2016-04-22 (47 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/08/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: J5ET41WW (1.12 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20DF004USP
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrJ5ET41WW(1.12):bd12/08/2014:svnLENOVO:pn20DF004USP:pvrThinkPadE550:rvnLENOVO:rn20DF004USP:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.name: 20DF004USP
dmi.product.version: ThinkPad E550
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1589997

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joan (aseques)]

Unfortunately apport-collect does not work in my system (I guess that apport-kde is not in a very good shape, can I provide the logs in another way?

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.7-rc1 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc1-yakkety/

[Joan (aseques)]

I tried with linux-image-4.7.0-040700rc1-generic, but couldn't boot, I am thrown into console with this message, I had to reboot into the linux-image-4.4.0-22-generic to boot the machine.

------------
Error parsing PCC subspaces from PCCT
error getting socket: Address family not supported by procotol
error initializing udev control socket
could not listen on fds: Invalid argument
error getting socket: Address family not supported by procotol
------------

[penalvch (penalvch)]

Joan, would the following work to gather the previously requested logs:
apport-cli -u 1589997

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

apport information

[Joan (aseques)]

I had to patch apport-kde (see https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1368911), but finally could use apport-collect

[penalvch (penalvch)]

Joan, would the latest mainline kernel (4.7-rc2) allow a test?

[Joan (aseques)]

Ok, I just booted into 4.7-rc2, it seems to work fine, the usb reappears every time under /dev with the same name, and I can use it normally.

[Joan (aseques)]

I wanted to say on the last comment (I posted it before finishing) that the only strange thing is a message in the syslog saying that the device "appeared twice with different sysfs paths", might caused by me plugging/unplugging the device.

[penalvch (penalvch)]

Jaon, the next step is to fully reverse commit bisect from kernel 4.4 to 4.7-rc2 in order to identify the last bad commit, followed immediately by the first good one. Once this good commit has been identified, it may be reviewed for backporting. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

After the fix commit (not kernel version) has been identified, then please mark this report Status Confirmed.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Joan (aseques)]

Unfortunately I can reproduce the bug anymore, after installing 4.7rc2 the devices appeared in my system but strangely the order was changed, so sda was the removable disk and sdb the fixed drive, I did an dd to sdb (to create a bootable pendrive) and screwed my system. So I'm now in a freshly installed ubuntu (thankfully, only the first 2G where lost, so I could recover my /home/)
Feel free the close the bug as appropiate

[penalvch (penalvch)]

Joan, to clarify, the originally reported issue is no longer reproducible in the new install with the default Ubuntu kernel (not upstream)?

[Joan (aseques)]

Yes, exactly that, I can no longer reproduce it with the current system

[penalvch (penalvch)]

Joan, let this be marked Invalid for now given it's not reproducible.

[Joan (aseques)]

Hello again, it seems that the issue arose again, I don't know at what point but it's still present. Apparently the kernel upgrade didn't fix the issue, because when it appeared back on the new install I upgraded the kernel again to current version, and it's still happening

$ uname -r
4.7.0-040700rc6-generic

About the bios upgrade, I updated it to the current version 1.25, so it shouldn't be a problem.
What could I provide to help with the diagnostic of the issue.

[Joan (aseques)]

I changed the status into confirmed (didn't see how to reopen the issue), if I have to open a new bug referring this one, just tell me.

Thanks

[Joan (aseques)]

It seems to me that the problem is on boot, I have found that:
- If I boot without a device then it doesn't work, it happened to me with a USB to serial (not creating /dev/ttyUSB0 and also with pendrives /dev/sdx
- If I boot with the device, then I can plug / unplug without issues, even new devices of the same type (different pendrives)

[Joan (aseques)]

Sure, there you go

$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
J5ET54WW (1.25 )
07/18/2016

[penalvch (penalvch)]

Joan, to keep this relevant to upstream, one would want check for, and test the latest mainline kernel (now4.8-rc6) as it is released.

Could you please advise?

[Joan (aseques)]

Done, I'm on rc7

$ uname -r
4.8.0-040800rc7-generic

What I observed is that after booting the system, the ports work properly, but on the next day (laptop being only locked and connected to the power outlet), they just do the wrong behavior

[Joan (aseques)]

I finally found out the cause for this, still no idea about a proper solution. I am using vmware horizon to connect to a windows computer, it has a funcion called usb redirection that allows you to use your usb from the windows computer.
It seems that when vmware horizon is open, the usb devices are redirected there and my laptop doesn't see them, when I close it, everything works normally.
So I suppose that the issue can be closed. Thanks for your help

[penalvch (penalvch)]

Joan, if using a later kernel had an improving effect, then is VMware confirmed the root/only root cause?

[Joan (aseques)]

No, the only thing that affected the operation of the usb ports was the vmware horizon software. I conjectured other things before finding the root cause.

[Joan (aseques)]

I forgot to update the thread with the solution, since vmware horizon v4.3 there is n option to easily choose what to do with the usb devices connected. To be able to use the devices normally it's just a matter of deselecting the devices from the menu.
This bug should be closed.

Thanks for your help

[Joan (aseques)]

I'm closing the bug myself because the issue was only vmware horizon keeping the hardware for itself.