Here is an example of the problem, with kernel image 4.0.8-2 amd64 (from Debian snapshots). The relevant output from dmesg, from the time I give the "Safely Remove Drive" command is below. The output shows the device disconnecting then about 0.4 seconds later it is detected as a new device (see lines I marked with asterisks):

[   59.310643] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[   59.428081] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
***** [   59.464441] usb 2-2: USB disconnect, device number 2
***** [   59.841273] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd
[   59.863925] usb 2-2: New USB device found, idVendor=0bc2, idProduct=2322
[   59.863937] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[   59.863944] usb 2-2: Product: Expansion
[   59.863950] usb 2-2: Manufacturer: Seagate
[   59.863956] usb 2-2: SerialNumber: NA8DFHL6
[   59.871807] scsi host5: uas
[   59.874809] scsi 5:0:0:0: Direct-Access     Seagate  Expansion        9300 PQ: 0 ANSI: 6
[   59.876620] sd 5:0:0:0: Attached scsi generic sg2 type 0
[   59.876695] sd 5:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 TB/931 GiB)
[   59.876698] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[   59.877103] sd 5:0:0:0: [sdb] Write Protect is off
[   59.877107] sd 5:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[   59.877297] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   59.877677] xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
[   59.877681] xhci_hcd 0000:04:00.0: @000000026312df00 00000000 00000000 1b000000 01038000
[   60.646377]  sdb: sdb1
[   60.647569] sd 5:0:0:0: [sdb] Attached SCSI disk
[   61.378077] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)

Any idea why the disconnected device is then immediately being detected as a new device?

P.S. I have no idea what to do with this information, but I've noticed a pattern:
- In the old kernels that don't have this issue (e.g., 3.16.x), only xhci_hcd kernel module exists
- In the kernels that have the issue (3.18-4.3), which I would like to use once I can fix this, both xhci_hcd and xhci_pci kernel modules exist
- In newer kernels that don't have this issue (but give me graphics artifacts) (4.4+) neither kernel module exists

Hi, Geoff42. I'm using the Arc-Darker theme plus my scrollbar hack (plus a custom metacity-1 theme--see rant below). I don't use emacs (I'm a vim/geany person) so can't comment there, but my scrollbar hack works nicely in Synaptic.

I was hoping my scrollbar hack would work with any theme, but I guess I was just lucky with all the themes I tried.

Rant: Another annoying thing about the new themes are the "flat" window titlebars. When these titlebars overlap, it is impossible to know where one window's titlebar ends and another window's titlebar begins. I spent an unhealthy amount of time hacking a metacity-1 theme to a) have titlebar color gradient, b) use Arc-Darker's minimize/maximize/close buttons, and c) integrate well with the colors of the Arc-Darker theme. The metacity theme is here in case anyone is interested. I know the theme works if you are using metacity or marco as your WM, probably wouldn't work with other WMs but I'm not sure. To try it: Download the tarball, extract it, put the extracted folder in /usr/share/themes/, then customize your theme to use FineryDark-ArcButtons for "window borders".

I'm talking about the weird, ghostly icon that moves between the original location and new location. It happens when I drop the icon at the new location. You can see it in the video.

This is definitely not something I've seen in MATE before. Given the erratic nature of this (only part of the icon shows up in the blur, bits and pieces of the desktop background fly away and back, sometimes it does not happen at all) I'm pretty sure this is a bug.

This is not a big deal, of course, but if one of you smart guys has an instinct of what could be causing this (or know for a fact what is causing it), I'd like to try fixing it.

The missing step was to add test to the end of the TARGETS list at the top of /etc/init.d/.depend.start

At this point I don't understand why it worked, but am happy to be one step closer to understanding.

Thanks again!

So far, so good with linux-libre kernel 4.15.14, which I got from here: http://linux-libre.fsfla.org/pub/linux- … ol/main/l/

No graphics glitches with this kernel, and so far no hung boots. Too early to tell if hung boots issue is solved given that it only happens once in a while, but I will be optimistic and will try (again) marking this issue as solved.

If I don't post again, it's because the hung boots went away.

Problem happens sometimes with startx as well. At least startx produces a (helpful?) error message when it happens:

The interesting bit is "intel_do_flush_locked failed: Invalid argument" of course. I did some duck-ducking and it sounds like this could be a kernel bug. If so, this is extremely strange because I'm running the same kernel in ascii that I was running in jessie without any issues (I'm using the older kernel 3.16.51-3+deb8u1 because ascii's default kernel causes some graphics artifacts on my machine: https://dev1galaxy.org/viewtopic.php?id=1905).

Problem just recurred despite 1-4 in post #20.

I'm giving up on getting X and a display manager to consistently play nice. Will try my luck with startx, hopefully it will be more consistent.

Thanks, catprints. I did it just now and everything was checked.

So a recap of where I am at this point:
1. Tried using slim instead of lightdm, but problem recurred so I'm back on lightdm.
2. Uninstalled consolekit. Problem recurred afterwards but I'm leaving consolekit uninstalled since it seems superfluous.
3. Ran pam-auth-update as root. Everything is checked in the prompt.
4. Did full system upgrade again this morning.

I'll update the thread when I have something new to share.

fsmithred and golinux, thank you both very much. Based on the simple word or in fsmithred's post and golinux's link, I realized that I don't need both consolekit and elogind.

I tried uninstalling elogind (to simulate the package lineup in my problem-free Devuan Jessie partition) but doing so would force the removal of a truckload of packages including most of MATE. Therefore, I uninstalled consolekit. So far no negative consequences and I've booted my system 20 times for testing without any "hung" boots so far (using lightdm from ascii's repo). Fingers crossed...

fsmithred, is it possible that the intermittent nature of my issue was because of a race condition between elogind and consolekit?

Problem recurred with slim. Darn. I guess lightdm is innocent.

I'll try the other things but am running out of hope of nailing down this issue.