<heftig> kay: systemd commit 22582bb broke cups usb printing for me
<heftig> because the "lp" group isn't applied anymore
<heftig> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp"
<heftig> moving this line to the end of 50-udev-default.rules restores correct behavior, as it's after usb_id
The 'kmod' builtin, like the 'firmware' and 'uaccess' builtins, does not set
any variables, so don't use IMPORT.
Notice that this changes the behaviour slightly: the processing of subsequent
rules for the event that loads a module will no longer wait for the module
loading to finish. This is not expected to cause any problems, but we should
keep an eye on it.
The properties will still be set in the udev database, but they will not be used
for setting the interface names. As for the other kernel commandline switches,
we allow it to be prefixed by 'rd.' to only apply in the initrd.
On Thu, Dec 6, 2012 at 9:20 AM, Robert Milasan <rmilasan@suse.com> wrote:
> It seems that the added rules:
>
> ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="046b",
> ATTR{idProduct}=="ff10", TEST=="power/control",
> ATTR{power/control}="auto"
>
> creates problems for people with Supermicro X8ST3 mb (and maybe
> other Supermicro mb's) and renders the KVM-over-IP unusable, at BIOS
> and GRUB the KVM works perfectly, but after that the device is unusable.
>
> Dropping the rule fixes the issue.
>
> Reference bug: https://bugzilla.novell.com/show_bug.cgi?id=792576
HP iLO fw versions below 1.50 incorrectly report that HP iLO virtual
Kbd/Mouse supports remote wakeup. With the rules change in commit
3bfc7a97b1, the HP iLO was listed for
power control.
In iLO fw versions less than 1.50, the iLO Kbd/Mouse become unresponsive
once they are suspended. HP iLO fw versions 1.50+ correctly report that
they don't support remote wakeup, which makes the rules moot in any case.
Much like logind has a client in loginctl, and journald in journalctl
introduce timedatectl, to change the system time (incl. RTC), timezones
and related settings.
Commits 5e9eb156c and 32567f8 introduced persistent symlinks for input devices
with more than one interface. However, this does not ensure stability for the
"default" interface, i. e. with interface number 00 or a nonexisting one. If a
device with a higher interface number appears first, it'll claim the symlink
name without an interface number, and the "interface 00" device won't get any.
Fix this by creating the default symlink only for interface 00 or a nonexisting
one, so that we properly partition the two cases over the two rules.
https://launchpad.net/bugs/1057824
All "btrfs" file systems will be registered with the kernel when they
show up.
Incomplete multi-device volumes will set SYSTEMD_READY=0, to prevent
access until the volume is complete and fully registered.
