Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

69-mixxx-usb-uaccess.rules causes long boot time Ubuntu 24.04 #13290

Open
mrbrico opened this issue May 26, 2024 · 8 comments
Open

69-mixxx-usb-uaccess.rules causes long boot time Ubuntu 24.04 #13290

mrbrico opened this issue May 26, 2024 · 8 comments
Labels

Comments

@mrbrico
Copy link

mrbrico commented May 26, 2024

Bug Description

After upgrading to Ubuntu 24.04 boot times increased to around 4 minutes, I tracked this down to the above, commenting out KERNEL=="hiddev*", NAME="usb/%k", GROUP="uaccess" fixed the extremely long boot times.

By default this is enabled in the udev rule /usr/lib/udev/rules.d/69-mixxx-usb-uaccess.rules

Only some distribuions require the below

KERNEL=="hiddev*", NAME="usb/%k", GROUP="uaccess"

Maybe default this should be commented out and enabled if needed...?

Version

2.4.1

OS

Ubuntu 24.04

@mrbrico mrbrico added the bug label May 26, 2024
@acolombier
Copy link
Contributor

Hi @mrbrico , I haven't yet moved to 24.04 (waiting for the July SP).
Would you be able to provide some system logs to try and narrow down the problem?

@mrbrico
Copy link
Author

mrbrico commented Jun 10, 2024 via email

@mrbrico
Copy link
Author

mrbrico commented Jun 10, 2024

log_messages_udev_disabled.log
log_messages_udev_enabled.log

with the 1 min delay between the following when the rule is enabled
19:24:31 kernel: iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
19:23:35 kernel: Console: switching to colour frame buffer device 240x75

@acolombier
Copy link
Contributor

acolombier commented Jun 10, 2024

Thanks for the logs and the kind words.

I'm not sure there is enough info to narrow down this bug. Could you try the following:

  • Enable the udev rule
  • Reload udev (sudo udevadm control --reload-rules && sudo udevadm trigger)
  • Reboot (make sure the problem is still there)
  • Run sudo journalctl --boot=-1 and share that. This will include both dmesg and systemd logs (which should be used to run udev daemon)

In the meantime, I have just checked on my end (PopOS 22.04) with sudo systemctl status udev.service and spotted that in the logs:

hiddev4: /usr/lib/udev/rules.d/69-mixxx-usb-uaccess.rules:61 Only network interfaces can be renamed, ignoring NAME="usb/%k".

I will look if I can fix that!
Edit: already tracked as #12526

@mrbrico
Copy link
Author

mrbrico commented Jun 10, 2024

Journalctl boot log with the rule enabled...
journalctl_boot.log

This error is what lead me to comment out the line in the rule...
systemd-udevd[506]: /usr/lib/udev/rules.d/69-mixxx-usb-uaccess.rules:61 Unknown group 'uaccess', ignoring.

@acolombier
Copy link
Contributor

Yeah, this rule seems to be quite out of date, but that warning should block the system.

I can see you've started the reboot at 20:04:42 and the system rebooted at 20:04:46, does that mean you were unable to reproduce the issue this time?
Also, do you use a HID controller with Mixxx?

@mrbrico
Copy link
Author

mrbrico commented Jun 10, 2024

The delay is still there when the rule is enabled, its about 1 min delay now though... if I disable boot quiet in grub I can see systemd just stop for about 1 min before continuing. I could not find anything obvious in the logs and just went through errors I saw that may have affected boot time, plymouth / app amour /network manager until I tried the udev error above..

The system log shows the delay but not why, like it just stops for 1 min
19:24:31 kernel: iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
19:23:35 kernel: Console: switching to colour frame buffer device 240x75

I use A&H k2 controllers or NI x1 controllers, also testing with serato dvs.. I never had the pioneer xdj 1000 mk2's working

@acolombier
Copy link
Contributor

Thanks for the details.
I will try to reproduce this in a VM soon and report my findings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants