I’ve navigated into those directories, but I can’t find anything that would tell me what USB that exactly is. Is it just trial by error, or is there a method for finding it out?
A method could be, leaving the essential ones (mouse and keyboard) first.
Rebooted now 4 times successfully.
I guess that the XboxOne USB Adapter was the culprit. I didn’t even know that it was still plugged into the PC. Sorry for the hassle, but I’ve learnt something at least.
Thanks!
2 Likes
smooch
1 Like
If this was really the issue, then it is a bug, as systemd/udev rules should not break the system because of an incompatible/failing external device plugged in.
Then it should be reported upstream, so they can fix it. It would help upstream devs, if you had found the actual udev rule, or other component to blame and gather more journal info.
1 Like
Aς ακούσουμε τον Τακτικός…
Das würde den Entwicklern helfen…!
1 Like
Würde ich gerne dabei unterstützen, müsste aber zuerst wissen wo ich sowas machen kann, und was upstream überhaupt ist.
Kenne mich da aber zu wenig aus 
我同意你们所有人的意见!
1 Like
“Upstream” meaning is, Arch Linux is the major SOURCE of EndeavourOS, next to Calamares (the installer).
As EnOS is based on Arch Linux, it is pulling most all packages from the Arch Linux repositories. The point-and-click adventure you are having with EndeavourOS is the comfort-zone that many and more linux-tryers are seeking to find these days in a safe way, and the usual experience with EnOS is a great one!
Upstream error reporting in this case would mean, getting in touch with the developers of systemd, with systemd being heavily disputed as the “holy grail”, it is still being used by most Linux distros (including Arch & EnOS, Fedora and many others).
Perhaps, @petsam could point us to the correct spot for your bug-report, if not already linked correctly?
2 Likes
Gotcha, that makes sense then. Thanks for clarifying that.
1 Like
Have a look at the following. Looks like it would add some udev-rules to handle game devices:
1 Like
This is a fairly probable place and still a fallback, if you can’t find the exact udev rule file and confirm the owner package.
IIRC I had seen a previous topic/issue of OP that was advised to do something that included udev rules or similar. I did not look further and didn’t ask (directly ), so I can’t know the answer.
Only OP could give the answer, from us humans 
.
Would that mean that by unplugging the USB Adapter, those udev-rules would get removed?
Since my reboot has been fixed by unplugging it, I would say that that automatically removes those entries.
No. What I think it means is that it would add some udev rules to handle the adapter so you won’t be needing to unplug it.
I haven’t really looked further into it. Perhaps you could do some research when you find time.
Also a bit of reading (that I have to do myself as well):
1 Like
No to both lines 
udev rules are text files that are installed by a package.
Main rules files are installed (and owned) by systemd.
Other packages may include and install such files.
There is no auto-deletion of files, when a device is connected or removed.
More info at the upstream (Arch) Wiki.
1 Like
It was regarding taking mouse sensitivity from Windows over to Linux, but I decided not to go that route.
I disabled mouse acceleration in Windows, got used to it, then went into Linux, and selected “Flat” profile for Mouse Acceleration.
Then I took a measurement tape to get the 1:1 sensitivity 
1 Like
I may be understanding it wrong, but if those USB Adapter rules aren’t being removed after I unplug it, how come unplugging it fixes the reboot?
Nevertheless, I’ll give that Wiki page a read
1 Like
From my limited understanding of the issue and looking at the screenshot, it seems the usb device is not properly recognized. The udev is looking for an MTP device that it doesn’t find. Perhaps someone else could further explain the whole thing.
By the way, you could post terminal output as text. It makes it easier to quote and it will be accessible by search engines.
Just copy-paste-highlight and pres Ctrl-E to format.
1 Like
Thanks about that, didn’t know it was possible like that.
Out of curiousity, I ran that command journalctl -fu systemd-udevd again, and got following output:
Jun 20 17:04:13 smokus-linux mtp-probe[725]: bus: 1, device: 4 was not an MTP device
Jun 20 17:04:14 smokus-linux mtp-probe[738]: checking bus 5, device 3: "/sys/devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb5/5-4"
Jun 20 17:04:14 smokus-linux mtp-probe[738]: bus: 5, device: 3 was not an MTP device
Jun 20 17:04:14 smokus-linux mtp-probe[740]: checking bus 5, device 2: "/sys/devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb5/5-3"
Jun 20 17:04:14 smokus-linux mtp-probe[740]: bus: 5, device: 2 was not an MTP device
Jun 20 17:04:14 smokus-linux mtp-probe[753]: checking bus 5, device 2: "/sys/devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb5/5-3"
Jun 20 17:04:14 smokus-linux mtp-probe[753]: bus: 5, device: 2 was not an MTP device
Jun 20 17:04:15 smokus-linux mtp-probe[757]: checking bus 5, device 3: "/sys/devices/pci0000:00/0000:00:08.1/0000:2f:00.3/usb5/5-4"
Jun 20 17:04:15 smokus-linux mtp-probe[757]: bus: 5, device: 3 was not an MTP device
Jun 20 19:04:11 smokus-linux systemd-udevd[445]: Configuration file /usr/lib/udev/rules.d/77-mm-fibocom-port-types.rules is marked executable. Please remove executable permission bits. Proceeding anyway.
Please remove executable permission bits What’s that supposed to mean?
Is it because of this checkbox?:
If so, should it be safe to uncheck it? I don’t even knoow what that’s for.
A quick google search gave me this and this result. Apparently it’s a bug in the package modemmanager
Apparently it has been fixed upstream, but I’ve no clue what it’s used for though.