IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When using pkg-config to determine the include flags for blkid the
flags are returned as:
$ pkg-config blkid --cflags
-I/usr/include/blkid -I/usr/include/uuid
We use the <blkid/blkid.h> include which would be correct when using
the default compiler /usr/include header search path. However, when
cross-compiling the blkid.h will not be installed at /usr/include and
highly likely in a temporary system root. It is futher compounded if
the cross-compile packages are split up and the blkid package is not
available in the same sysroot as the compiler.
Regardless of the compilation setup, the correct include path should be
<blkid.h> if using the pkg-config returned CFLAGS.
Due to ARM not having an EFI capable objcopy we need to use the binary
output argument. This is correctly set up for AArch64 but is missed
when building for ARM32. This patch adds the ARCH_ARM automake define
which can then be used in the makefile to determine if to use the
correct linker flags.
The addition of the ARM32 flags is a copy and paste from the AArch64 to
create a logical OR for the ARCH_AARCH64 and ARCH_ARM variables. I
couldn't figure out a better way to create the conditional with basic
Make language constructs.
When the user provides the --with-efi-includedir we incorrectly search
for the header at /usr/include not the provided location. This patch
changes the check to use the provided value so that non-standard header
locations are supported.
This situation occurs commonly when cross-compiling systemd because the
GNU EFI headers and library will not be installed into the root
locations but highly likely a temporary system root.
This doesn't add anything major, but moves some stuff around.
In particular changes which might require updates to the build
environment (new kernel requirements, cgroup stuff, dbus, etc)
are moved to the top, where it's most likely that people will
read them. In particular cgroup hierarchy changes are moved to the
top because they're most likely to be problematic.
Various items are grouped by subject where it's easy.
The description of list-jobs --after/--before was reversed.
The builtin path id for virtio block devices has been changed
to use the bus id without a prefix "virtio-pci" to be
compatible with all virtio transport types.
In order to not break existing setups, the by-path symlinks for
virtio block devices on the PCI bus are reintroduced by udev rules.
The virtio-pci symlinks are considered to be deprecated and
should be replaced by the native PCI symlinks.
Example output for a virtio disk in PCI slot 7:
$ ls /dev/disk/by-path
pci-0000:00:07.0
pci-0000:00:07.0-part1
virtio-pci-0000:00:07.0
virtio-pci-0000:00:07.0-part1
See also
[1] https://lists.freedesktop.org/archives/systemd-devel/2017-February/038326.html
[2] https://lists.freedesktop.org/archives/systemd-devel/2017-March/038397.html
This reverts f073b1b but keeps the same symlinks for compatibility.
This reverts commit 295ee9845c.
Let'd revert this for now, see #5446 for discussions.
We want systemd-detect-virt --chroot to return true for all chroot-like stuff, for
example mock environments which have use a mount namespace. The downside
of this revert that systemctl will not work from our own namespaced services, anything
with RootDirectory=/RootImage= set.
I think it would be a good idea to move such fixed, picked values out of
the main sources into the head of a file, to make sure they are
ultimately tunables.
We check these a number of times, hence let's unify these checks here.
This also allows us to make the PID 1 check more elaborate as we can
check both the PID and the cgroup. Checking the PID has the benefit that
we'll also cover cases where PID 1 might still be in the root cgroup, and
the cgroup check has the benefit that we also cover crashes in forked
off crasher processes (the way we actually do it in systemd)
Given that this is a field primarily processed by computers, and not so
much by humans, assign "1" instead of "yes". Also, use parse_boolean()
as we usually do for parsing it again.
This makes things more alike udev options (as one example), such as
SYSTEMD_READY where we also spit out "1" and "0", and parse with
parse_boolean().
Container managers frequently block name_to_handle_at(), returning
EACCES or EPERM when this is issued. Accept that, and simply fall back
to to fdinfo-based checks.
Note that we accept either EACCES or EPERM here, as container managers
can choose the error code and aren't very good on agreeing on just one.
(note that this is a non-issue with nspawn, as we permit
name_to_handle_at() there, only block open_by_handle_at(), which should
be sufficiently safe).
If the unit's SourcePath is below /proc then it's a unit genreated from
a kernel resource (such as a .mount or .swap unit). And those we watch
anyway, and hence should never be out-of-date.
Fixes: #5461
Otherwise we'll hit an assert sooner or later.
This requires us to initialize ->where even if we come back in "masked"
mode, as otherwise we don't know how to operate on the automount and
detach it.
Fixes: #5441
[guest@fedora ~]$ coredumpctl
No coredumps found.
[guest@fedora ~]$ ./coredumpctl
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal', 'wheel' can see all messages.
Pass -q to turn off this notice.
No coredumps found.
Fixes#1733.
The only functional change is that log_notice("No journal files were found.")
is not printed any more with --quiet. log_error("No journal files were opened
due to insufficient permissions.") is still printed.
I wasn't quite sure where to put this function, but shared/ seems to be the
right place and none of the existing files seem to fit too well.
v2: rename journal_access_check to journal_access_check_and_warn.
We would only log a terse message when pid1 or systemd-journald crashed.
It seems better to reuse the normal code paths as much as possible,
with the following differences:
- if pid1 crashes, we cannot launch the helper, so we don't analyze the
coredump, just write it to file directly from the helper invoked by the
kernel;
- if journald crashes, we can produce the backtrace, but we don't log full
structured messages.
With comparison to previous code, advantages are:
- we go through most of the steps, so for example vacuuming is performed,
- we gather and log more data. In particular for journald and pid1 crashes we
generate a backtrace, and for pid1 crashes we record the metadata (fdinfo,
maps, etc.),
- coredumpctl shows pid1 crashes.
A disavantage (inefficiency) is that we gather metadata for journald crashes
which is then ignored because _TRANSPORT=kernel does not support structued
messages.
Messages for the systemd-journald "crash" have _TRANSPORT=kernel, and
_TRANSPORT=journal for the pid1 "crash".
Feb 26 16:27:55 systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=11/SEGV
Feb 26 16:27:55 systemd[1]: systemd-journald.service: Unit entered failed state.
Feb 26 16:37:54 systemd-coredump[18801]: Process 18729 (systemd-journal) of user 0 dumped core.
Feb 26 16:37:54 systemd-coredump[18801]: Coredump diverted to /var/lib/systemd/coredump/core.systemd-journal.0.36c14bf3c6ce4c38914f441038990979.18729.1488145074000000.lz4
Feb 26 16:37:54 systemd-coredump[18801]: Stack trace of thread 18729:
Feb 26 16:37:54 systemd-coredump[18801]: #0 0x00007f46d6a06b8d fsync (libpthread.so.0)
Feb 26 16:37:54 systemd-coredump[18801]: #1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #5 0x00005577688cf056 write_to_journal (systemd-journald)
Feb 26 16:37:54 systemd-coredump[18801]: #6 0x00005577688d2e98 dispatch_message_real (systemd-journald)
Feb 26 16:37:54 kernel: systemd-coredum: 9 output lines suppressed due to ratelimiting
Feb 26 16:37:54 systemd-journald[18810]: Journal started
Feb 26 16:50:59 systemd-coredump[19229]: Due to PID 1 having crashed coredump collection will now be turned off.
Feb 26 16:51:00 systemd[1]: Caught <SEGV>, dumped core as pid 19228.
Feb 26 16:51:00 systemd[1]: Freezing execution.
Feb 26 16:51:00 systemd-coredump[19229]: Process 19228 (systemd) of user 0 dumped core.
Stack trace of thread 19228:
#0 0x00007fab82075c47 kill (libc.so.6)
#1 0x000055fdf7c38b6b crash (systemd)
#2 0x00007fab824175c0 __restore_rt (libpthread.so.0)
#3 0x00007fab82148573 epoll_wait (libc.so.6)
#4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so)
#5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so)
#6 0x000055fdf7c4a380 manager_loop (systemd)
#7 0x000055fdf7c402c2 main (systemd)
#8 0x00007fab82060401 __libc_start_main (libc.so.6)
#9 0x000055fdf7c3818a _start (systemd)
Poor machine ;)
Detect the 'Detachable' dmi chassis type properly. Use the new
'convertible' chassis class of hostnamed, instead of returning the
generic 'computer' chassis class.
If the cryptsetup service unit and swap unit for a swap device
are not strictly ordered, it might happen that the swap unit
activates/mounts the swap device before its cryptsetup service unit
has a chance to run the 'mkswap' command (that it is programmed to).
This leads to the following error:
Starting Cryptography Setup for sda3_crypt...
[ OK ] Found device /dev/mapper/sda3_crypt.
Activating swap /dev/mapper/sda3_crypt...
[ OK ] Activated swap /dev/mapper/sda3_crypt.
[ OK ] Reached target Swap.
[FAILED] Failed to start Cryptography Setup for sda3_crypt.
See 'systemctl status systemd-cryptsetup@sda3_crypt.service' for
details.
[DEPEND] Dependency failed for Encrypted Volumes.
Which happens because the swap device is already mounted:
# systemctl status systemd-cryptsetup@sda3_crypt.service
<...>
Active: failed (Result: exit-code) since Mon 2017-02-27 14:21:43 CST;
54s ago
<...>
<...> systemd[1]: Starting Cryptography Setup for sda3_crypt...
<...> mkswap[2420]: mkswap: error: /dev/mapper/sda3_crypt is mounted;
will not make swapspace
<...>
So, modify cryptsetup-generator to include a 'Before=' option for the
respective 'dev-mapper-%i.swap' device in the cryptsetup service unit.
Now, correct ordering is ensured, and the error no longer occurs:
Starting Cryptography Setup for sda3_crypt...
[ OK ] Found device /dev/mapper/sda3_crypt.
[ OK ] Started Cryptography Setup for sda3_crypt.
Activating swap /dev/mapper/sda3_crypt...
[ OK ] Reached target Encrypted Volumes.
[ OK ] Activated swap /dev/mapper/sda3_crypt.
[ OK ] Reached target Swap.
Its necessary to specify the KVM PTP device name in userspace.
In case a network card with PTP device is assigned to the guest,
it might be the case that KVM PTP gets /dev/ptp0 instead of /dev/ptp1.
Fix a device name for the KVM PTP device.
Since 95f1d6bfec we'll subscribe to unit
signals to figure out when to disconnect the pty. But that can only work
correctly if we actually subscribe to the unit's signals. Hence,
explicitly pin (and thus subscribe to) the unit we just created not only
in --wait mode but also in --pty mode.
Or to say this differently: we need to pin the unit in the same cases as
we install the signal match. 95f1d6bfec
forgot to do that.
This is relevant to make sure systemd-run works correctly in --user
mode, and correctly exits when the spawned service dies. To test:
systemd-run --user -t /bin/bash
And then press ^D. This will hang before this change, but exit cleanly
after it.
If a client pins a unit, then it makes sense to also implicitly make it
a subscriber. This is useful for clients that just want to watch one
specific unit: they can pin it and receive its messages.
Detect the 'Convertible' dmi chassis type properly. Use the new
'convertible' chassis class of hostnamed, instead of returning the
generic 'computer' chassis class.
Based on a patch by Jani Nikula <jani.nikula@intel.com>.
Add the 'convertible' type to the set of allowed chassis. This applies
to all devices that can be transformed by the user from laptop style to
tablet style.
This does not add any auto-detection, yet. It only makes 'set-chassis'
accept 'convertible' as valid input.
* Fix MIPS N64 and N32 LIB_ARCH_TUPLE
For mips, we have 3 major ABIs, they are N64, N32 and O32.
Both N32 and N64 defined __mips64__, and only N64 defined __LP64__.
GRE6 and IP6TNL address should be a IPv6.
fix :
```
Assertion 't->family == AF_INET6' failed at src/network/netdev/tunnel.c:170,
function netdev_ip6gre_fill_message_create(). Aborting.
```
