Re: USB Attached SCSI breakage due no udev involvement

From: Dio Putra
Date: Sun May 10 2020 - 09:15:42 EST


On 5/10/20 4:48 PM, Dio Putra wrote:
On 5/10/20 3:48 PM, Greg KH wrote:
On Sun, May 10, 2020 at 03:35:34PM +0700, Dio Putra wrote:
On 5/10/20 2:32 PM, Greg KH wrote:
On Sun, May 10, 2020 at 02:10:04PM +0700, Dio Putra wrote:
On 5/10/20 1:54 PM, Greg KH wrote:
On Sun, May 10, 2020 at 01:48:24PM +0700, Dio Putra wrote:
On 5/10/20 12:47 PM, Greg KH wrote:
On Sun, May 10, 2020 at 09:55:57AM +0700, Dio Putra wrote:
Hi, it's first time for me to report user-space breakage in here, so
i'm begging your pardon.

I want to report that Linux 5.4 breaking my USB mount workflow due
udevadm monitor report here (I'm using vanilla kernel 5.4.39 on
Slackware64 Current and vanilla kernel 4.4.221 on Slackware64 14.2):

<snip>

Sorry, but what actually changed that you can see in the logs?
Sorry, what do you mean? The dmesg log or the kernel changelogs?

Either, your message made them pretty impossible to compare with all of
the line-wrapping :(

I'm so sorry for first message mess, because that message has been sent by
Gmail Website. Can I send my logs as attachment? I try to convenient everyone
here. ( FYI, I just switched to Thunderbird with these settings:
https://www.kernel.org/doc/html/v4.12/process/email-clients.html#thunderbird-gui )

Sure, attachments work, but better yet, if you can show the difference
in a few lines that is much nicer than having to dig through large
numbers of log files.

Okay, I'll attach long messages and trim it as far as I can.

Again, I really do not understand what exactly is "not working".

Please explain that when you send the new log messages.

Okay, here's compilation of "dmesg | grep -i udev && udevadm
monitor && lsblk" on linux-4.4.221 vs linux-5.4.39. You can check
my attachment here because I can't explain it by words (I'm not
english native speaker anyway, which makes it so difficult to
explain it for me).

What functionality broke? What used to work that no longer does work?

Yes, it supposed that just work and kernel could talk with udev, not just handled by the kernel.

I don't understand, what functionality changed? What exactly used to
work that no longer does?
linux-5.4 has been never called the udev dependencies whereas
linux-4.4 will call any udev dependencies if necessary, that's the problem.

I do not understand what exactly you mean by "call udev dependencies".

udev is used to create symlinks and set user/group permissions on device
nodes in /dev/ which is created by devtmpfs. What exactly is not
happening in your /dev/ with the move to a newer kernel?

Would I send my dmesg log with "udev.log-priority=debug" as attachment then?

Did you change anything else other than the kernel on your system? Did
you change to a newer version of udev/systemd or anything else?

I'm using eudev-master from their official mirror github:
https://github.com/gentoo/eudev

Have you contacted the eudev developers to see if something different
needs to be set in your kernel when moving 4 years in kernel development
forward? Are you sure you have all the correct config options enabled?

It's my bad not to contact the eudev developers first. However I'm not quite
sure to contact the eudev developers would solve the problem, but CMIIW.

Why such a huge leap forward all at once, how about going from 4.4.y to
4.9.y and then 4.14.y and then 5.4.y? That might help narrow things
down a bit easier.

Unfortunately I need to think twice due almost ran out of electricity
here every time I power on my laptop for long time. So maybe I can't.

But if these steps are necessary, I'll think solution later.

Why would it take a long time to do this type of change?

It's a weak machine, it took appropriately 2 hours to just compiling
linux kernel. I need to think twice too because electricity is expensive here.

After deep digging into /dev/ folder, indeed some important file has been deleted after restart on Slackware.

On behalf from myself for linux-kernel community, I'm really sorry for causing these noise. Thank you Greg and all for the hints.
thanks,

greg k-h