| Age | Commit message (Collapse) | Author |
|---|
|
Check existence of loop/backing_file in sysfs and mark loop devices with
SYSTEMD_READY if missing. Such loop files is uninitialized and it's not
ready for use yet (there's no file attached).
|
|
there's a suitable root partition
|
|
|
|
This will do until all net properties are imported.
|
|
Resolve spotted issues related to missing or extraneous commas, dashes.
|
|
udev seems to have a race condition with swapon to see which can open
/dev/zram0 first, causing swapon to fail. Seems to be most noticeable
on arm devices one out of every 7 times or something.
|
|
Ensure to start getty programs on all essential system consoles on Linux on
System z. Add these essential devices to the list of virtualization_consoles
to always generate getty configurations.
For the sake of completion, the list of essential consoles is:
/dev/sclp_line0 - Operating system messages applet (LPAR)
/dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR)
/dev/ttyS0 - Already handled by systemd (3215 console on z/VM)
/dev/hvc0 - Already handled by systemd (IUCV HVC terminal on z/VM)
Depending on the environment, z/VM or LPAR, only a subset of these terminals
are available.
See also RH BZ 860158[1] "Cannot login via Operating System Console into RHEL7
instance installed on a LPAR". This bugzilla actually blocks the installation
of Linux on System z instances in LPAR mode.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=860158
|
|
|
|
We don't need any GOTO, if we merge all matches into a single line.
|
|
The path_id-builtin provides useful unique aliases for DRM devices. If we
want to configure DRM render-nodes for compositors, we want to avoid
storing the whole sys-path in configuration files. Hence, allow users to
store the short PATH_ID instead.
Load path_id-builtin unconditionally on DRM devices now to always provide
this alias.
|
|
|
|
Also add shell completions.
|
|
This introduces a new key NamePolicy, which takes an ordered list of naming
policies. The first successful one is applide. If all fail the value of Name
(if any) is used.
The possible policies are 'onboard', 'slot', 'path' and 'mac'.
This patch introduces a default link file, which replaces the equivalent udev
rule.
|
|
This tool applies hardware specific settings to network devices before they
are announced via libudev.
Settings that will probably eventually be supported are MTU, Speed,
DuplexMode, WakeOnLan, MACAddress, MACAddressPolicy (e.g., 'hardware',
'synthetic' or 'random'), Name and NamePolicy (replacing our current
interface naming logic). This patch only introduces support for
Description, as a proof of concept.
Some of these settings may later be overriden by a network management
daemon/script. However, these tools should always listen and wait on libudev
before touching a device (listening on netlink is not enough). This is no
different from how things used to be, as we always supported changing the
network interface name from udev rules, which does not work if someone
has already started using it.
The tool is configured by .link files in /etc/net/links/ (with the usual
overriding logic in /run and /lib). The first (in lexicographical order)
matching .link file is applied to a given device, and all others are ignored.
The .link files contain a [Match] section with (currently) the keys
MACAddress, Driver, Type (see DEVTYPE in udevadm info) and Path (this
matches on the stable device path as exposed as ID_PATH, and not the
unstable DEVPATH). A .link file matches a given device if all of the
specified keys do. Currently the keys are treated as plain strings,
but some limited globbing may later be added to the keys where it
makes sense.
Example:
/etc/net/links/50-wireless.link
[Match]
MACAddress=98:f2:e4:42:c6:92
Path=pci-0000:02:00.0-bcma-0
Type=wlan
[Link]
Description=The wireless link
|
|
Changing the default MODE= for the group accessi, but not specifying
a GROUP= does not provide anything.
It disables the default logic that the mode switches to 0660 as soon
as a GROUP= is specifed, which make custom rules uneccesarily complicated.
https://bugs.freedesktop.org/show_bug.cgi?id=70665
|
|
Devices should show up in systemd regardless whether the user invoked
"udevadm trigger" or not. Before this change some devices might have
suddenly disappeared due issuing that command.
|
|
Since the kernel no longer exposes a large number of "dead" loop devices
it is OK to expose them now in systemd, so let's do that. This has the
benefit that mount dependencies on loop devices start to work.
|
|
Much like for rfkill devices we should provide some stability regarding
enumeration order, hence include the stable bits of the device path in
the file name we store settings under.
|
|
Let's include the stable device path for the rfkill devices in the name
of the file we store the rfkill state in, so that we have some stability
regarding enumeration order.
|
|
This works analogous to the existing backlight and random seed services
|
|
backlights if we have both for the same device
|
|
Piggy-backing on the display backlight code, this saves and restores
keyboard backlights on supported devices.
The detection code matches that of UPower:
http://cgit.freedesktop.org/upower/tree/src/up-kbd-backlight.c#n173
https://bugs.freedesktop.org/show_bug.cgi?id=70367
[tomegun: also work for devices named "{smc,samsung,asus}::kbd_backlight"]
|
|
This makes the description string of the backlight service a bit nicer.
|
|
As many laptops don't save/restore screen brightness across reboots,
let's do this in systemd with a minimal tool, that restores the
brightness as early as possible, and saves it as late as possible. This
will cover consoles and graphical logins, but graphical desktops should
do their own per-user stuff probably.
This only touches firmware brightness controls for now.
|
|
Otherwise systemd-udevd will rename on "change" and "move" events,
resulting in weird renames in combination with biosdevname
systemd-udevd[355]: renamed network interface eth0 to em1
systemd-udevd[355]: renamed network interface eth1 to p3p2
systemd-udevd[357]: renamed network interface eth0 to p3p1
systemd-udevd[429]: renamed network interface p3p2 to ens3f1
systemd-udevd[428]: renamed network interface p3p1 to ens3f0
systemd-udevd[426]: renamed network interface em1 to enp63s0
or
systemd-udevd[356]: renamed network interface eth0 to em1
systemd-udevd[356]: renamed network interface eth0 to p3p1
systemd-udevd[420]: renamed network interface p3p1 to ens3f0
systemd-udevd[418]: renamed network interface em1 to enp63s0
systemd-udevd[421]: renamed network interface eth1 to p3p1
|
|
|
|
On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/. A side effect of this is that, after the driver has
> been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
> uevents and they don't match the default rule for autoloading modules matching
> MODALIAS:
>
> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>
> any more. However, there are some modules whose module aliases match specific
> CPU features through the modalias string and those modules should be loaded
> automatically if a compatible CPU is present. Yet, with the processor driver
> bound to the CPU devices the above rule is not sufficient for that, so we need
> a new default udev rule allowing those modules to be autoloaded even if the
> CPU devices have drivers.
|
|
|
|
|
|
Otherwise, when a network device is renamed, systemd-sysctl is run twice
with the same network device name: once for ACTION="add" and once for
ACTION="move".
|
|
Partially revert 2b3c81b02fa5dd47b19558c7684e113f36a48486, which
tried to avoid inconsistent rules about when and how to create the
/dev/rtc symlink.
Instead of conditionally or not creating the /dev/rtc link at all,
now always create it with additional and more reliable udev rules.
First try to find the "system rtc" with the hctosys flag, if this
is not found, fall back to create the link for /dev/rtc0.
Our code now never actively searches for the "system rtc" it can
always use /dev/rtc.
|
|
The export of the RTCs hctosys flag is uneccesary, the kernel takes care
of the persistemt clock management itself, without any need for:
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
"Chaotic hardware platforms" without native kernel persistent clock
support will find the proper RTC with the logic rtc_open() without
the need for a custom symlink.
|
|
|
|
<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.
|
|
Distros that whish to support old kernels should set
--with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware"
to retain the old behaviour.
|
|
|
|
|
|
|
|
|
|
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
|
|
kmod is unecessary if loadable module support is disabled in the kernel,
so make the dependency optional.
|
|
|
|
<grawity> btw, in 15ce372b75a "call 'hwdb' with --subsystem=" you
actually added "usb_id --subsystem=usb" (75-tty-description.rules)
<kay> ouch :)
|
|
|
|
|
|
HP iLO fw versions below 1.50 incorrectly report that HP iLO virtual
Kbd/Mouse supports remote wakeup. With the rules change in commit
3bfc7a97b1824fcdfb738617d9a5450a20a22a0f, 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.
|
|
|
