If a user specifies multiple X11 keymaps, with a (at least the first
one) nonempty variant, and we don't match the whole combo, use
a converted keymap which includes the variant in preference to
the default, variantless, keymap.
E.g.: We would convert X11 config "layout=fr variant=mac" to "fr-mac",
but "layout=fr,us variant=mac," to "fr", because we don't have a
converted keymap which would match "fr,us", and we don't have a legacy
mapping for "fr,us". This is unexpected, and if we cannot match both,
it is still better to match the primary mapping and use "fr-mac".
Converting X11 to legacy keymaps and back is a fucking mess. Let's
make it at least possible to request detailed logs of what is being
changed and why (LOG_DEBUG level).
At LOG_INFO level, we would log the requested change of X11 or console
keymap, but not the resulting change after conversion to console or X11.
Make sure that every change of configuration on disk has a matching
line in the logs.
Functions either should generate error messages for everything they do
themselves, or for nothing and let the caller do it. But they certainly
shouldn't generate errors for some messages but not for others. Since
the function in this case is one that generates messages on its own, it
really should do that for everything, not just for some things, hence.
Yum was creating <container>/var/run/yum.pid and hence this directory
was created before filesystem package could create the symlink
/var/run -> /run.
This should be now fixed in yum.
It seems the return code of systemctl daemon-reload can be !=0 in some
circumstances, which causes a failure of the unit and breaks booting in
the initrd.
The check, if the directory/file already exists is only executed, if
there is a symlink target specified. In case of "/root", there is none,
so it is unconditionally tried to create the directory.
In case of a readonly filesystem, errno != EEXIST, but errno == EROFS,
so base_filesystem_create() and switch_root does not succeed.
This patch checks for existance not only in the symlink case.
This reverts commit 665c6a9eab.
On Tue, Sep 2, 2014 at 3:17 PM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
>
> With the other patch allowing missed replies included it's now getting
> stuck as there is no timer to send the 2nd and 3rd request.
After receiving a reply from the server, allow two missed replies before
switching to another server to avoid unnecessary clock hopping when
packets are getting lost in the network.
When all servers are exhausted, wait for one poll interval before trying
to connect again to the first server in the list. Also, keep increasing
the polling interval to make sure a client not getting any valid replies
will not send requests to any server more frequently than is allowed by
the maximum polling interval.
blueness> poettering, was there a reason for not removing
50-firmware.rules when you nuked userland firmware
loading?
Followup for v216-119-gbe2ea723b1.
Simplify the way we handler session-controllers and fix several
shortcomings:
* send ReleaseDevice() signals on forced session takeover
* fix mem-leaks for busnames in case VT preparation fails (non-critical)
* avoid passing pre-allocated names to helpers
The fact that unit names have to be quoted can be a bit surprising.
Show quotes in the hint commandline, but only after checking that this
is necessary, since quotes are visually heavy and usually not needed.
https://bugs.freedesktop.org/show_bug.cgi?id=82832
The whole DHCPv6 test message length was incorrectly used as the length
of DHCPv6 options causing the following bad memory access:
$ build/test-dhcp6-client
Assertion 'interface_index >= -1' failed at ../src/libsystemd-network/sd-dhcp6-client.c:129, function sd_dhcp6_client_set_index(). Ignoring.
=================================================================
==29135==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe204aa9148 at pc 0x7fe204a5958f bp 0x7fff3e47d470 sp 0x7fff3e47d460
READ of size 1 at 0x7fe204aa9148 thread T0
#0 0x7fe204a5958e in option_parse_hdr ../src/libsystemd-network/dhcp6-option.c:145
#1 0x7fe204a59884 in dhcp6_option_parse ../src/libsystemd-network/dhcp6-option.c:165
#2 0x7fe204a4eb9c in test_advertise_option ../src/libsystemd-network/test-dhcp6-client.c:227
#3 0x7fe204a51c58 in main ../src/libsystemd-network/test-dhcp6-client.c:584
#4 0x7fe2031590df in __libc_start_main (/lib64/libc.so.6+0x200df)
#5 0x7fe204a4cc5b (/home/test/systemd/build/test-dhcp6-client+0x25c5b)
0x7fe204aa9148 is located 2 bytes to the right of global variable 'msg_advertise' from '../src/libsystemd-network/test-dhcp6-client.c' (0x7fe204aa9080) of size 198
0x7fe204aa9148 is located 56 bytes to the left of global variable 'msg_reply' from '../src/libsystemd-network/test-dhcp6-client.c' (0x7fe204aa9180) of size 173
SUMMARY: AddressSanitizer: global-buffer-overflow ../src/libsystemd-network/dhcp6-option.c:145 option_parse_hdr
We can't use LZ4_compress_limitedOutput_continue() because in the
worst-case scenario the compressed output can be slightly bigger than
the input block. This generally affects very few blocks and is no reason
to abort the compression process.
I ran into this when I noticed that Chromium core dumps weren't being
compressed. After switching to LZ4_compress_continue() a ~330MB Chromium
core dump gets compressed to ~17M.
Since c6a373a263, we might encounter unit templates via the
'list-units' verb. These aren't restartable (and we throw errors), so
make sure they're filtered out of the completion options.
fixes downstream bug: https://bugs.archlinux.org/task/41719
NTPv4 servers don't reply with unsynchronized status when they lost
synchronization, they only keep increasing the root dispersion and it's
up to the client to decide at which point they no longer consider it
synchronized.
Ignore replies with root distance over 5 seconds.
Zbigniew Jędrzejewski-Szmek