e04658277d531763a5cbbb6e212041a35e0d9ff4 |
|
01-Jul-2015 |
David Herrmann <dh.herrmann@gmail.com> |
Revert "kmod-setup: don't print warning on -ENOSYS"
This partially reverts commit 78d298bbc57e412574ea35e6e66f562d97fd9ebc.
The changed coding-style is kept, but the ENOENT->ENOSYS conversion is
reverted.
kmod was fixed upstream to no longer return ENOSYS. Also see:
https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=114ec87c85c35a2bd3682f9f891e494127be6fb5
The kmod fix is marked for backport, so no reason to bump the kmod
version we depend on. |
78d298bbc57e412574ea35e6e66f562d97fd9ebc |
|
11-Jun-2015 |
Daniel Mack <daniel@zonque.org> |
kmod-setup: don't print warning on -ENOSYS
-ENOSYS is returned from kmod_module_probe_insert_module() if a module isn't
available, not -ENOENT. Don't spit out a warning in that case unless the
warn_if_unavailable flag is set.
Also factor out the condition into an own variable for better readability. |
85c675538fd18eefe0bbfd6fc87d9e0f38f3207a |
|
08-Jun-2015 |
Daniel Mack <daniel@zonque.org> |
kmod-setup: split warn flags
Traditionally, we used to warn about ipv6 being a module or being
unavailable. This was changed in b4aa82f16 ("kmod-setup: don't warn
when ipv6 can't be loaded") in a way that neither of the two conditions
will cause a log message.
Now, while running a setup without any IPv6 is completely fine and
shouldn't cause any warning, we should still warn about ipv6 being a
module instead of built-in.
To achieve this, split the boolean warn flag into two: one for a
feature not being built-in but shipped as a module, and one to
print an error when a module is entirely unavailable.
We will, however, still warn if kmod returns anything else than
-ENOENT in the attempt of loading the module, and at the very least,
turn the message into a debug log. |
d79acc309327f8c0863bd3da8b93d926a1c93ba1 |
|
06-May-2015 |
David Herrmann <dh.herrmann@gmail.com> |
bus: don't switch to kdbus if not requested
Whenever systemd is re-executed, it tries to create a system bus via
kdbus. If the system did not have kdbus loaded during bootup, but the
module is loaded later on manually, this will cause two system buses
running (kdbus and dbus-daemon in parallel).
This patch makes sure we never try to create kdbus buses if it wasn't
explicitly requested on the command-line. |
1d3087978a8ee23107cb64aa55ca97aefe9531e2 |
|
22-Apr-2015 |
Lennart Poettering <lennart@poettering.net> |
kmod-setup: load ip_tables kmod at boot
The module is currently no auto-loadable (and this is unlikely to change
anytime soon, given it's API is via getsockopt/setsockopt). It is needed
by networkd and nspawn currently.
Users who really don't like the module to be loaded have the option to
blacklist it still, or not compile it at all. But for all others this
should make things work out-of-the-box. |
63cc4c3138fd0ce9cc97884373a2dd8959a13ee9 |
|
13-Nov-2014 |
Daniel Mack <daniel@zonque.org> |
sd-bus: sync with kdbus upstream (ABI break)
kdbus has seen a larger update than expected lately, most notably with
kdbusfs, a file system to expose the kdbus control files:
* Each time a file system of this type is mounted, a new kdbus
domain is created.
* The layout inside each mount point is the same as before, except
that domains are not hierarchically nested anymore.
* Domains are therefore also unnamed now.
* Unmounting a kdbusfs will automatically also detroy the
associated domain.
* Hence, the action of creating a kdbus domain is now as
privileged as mounting a filesystem.
* This way, we can get around creating dev nodes for everything,
which is last but not least something that is not limited by
20-bit minor numbers.
The kdbus specific bits in nspawn have all been dropped now, as nspawn
can rely on the container OS to set up its own kdbus domain, simply by
mounting a new instance.
A new set of mounts has been added to mount things *after* the kernel
modules have been loaded. For now, only kdbus is in this set, which is
invoked with mount_setup_late(). |
3dfb265083347cb5700dc38f7cc0f479f378e6e9 |
|
04-Nov-2012 |
Kay Sievers <kay@vrfy.org> |
kmod-setup: mounting efivarfs, *after* we tried to mount it, is pointless
The mount() system call, which we issue before loading modules, will trigger
a modprobe by the kernel and block until it returns. Trying to load it again
later, will have exactly the same result as the first time. |
f271dd97622b656c1c013d181ea615c671cc2438 |
|
30-Oct-2012 |
Lee, Chun-Yi <joeyli.kernel@gmail.com> |
systemd: mount the EFI variable filesystem
Add efivarfs to the mount_table in mount-setup.c, so the EFI variable
filesystem will be mounted when systemd executed.
The EFI variable filesystem will merge in v3.7 or v3.8 linux kernel.
Cc: Kay Sievers <kay@vrfy.org>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Mantas MikulÄ—nas <grawity@gmail.com>
Cc: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com> |