Now we are able to disable all programs which have systemd/journald
support. This feature is needed by openSUSE packagers who are building
util-linux in 2 stages to avoid build cycles.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Add couple missing options, and make the completion overall work better.
That said completion is still incomplete, pardon the pun. After user has
specified policy then giving a hint what priority needs to be specified is
theoretically possible, but such hint is not given. There does not seem to
be easy way to know when user wants stops specifying options and move to
defining priority in: chrt [options] [prio] [command|pid].
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The function mnt_table_get_fs_root() should be robust enough to accept
NULL as mountinfo -- the right behaviour is to default to '/'.
The set_fs_root() (tab_update.c) has to understand when mountinfo is
necessary (for bind mounts and btrfs).
Reported-by: Stanislav Brabec <sbrabec@suse.cz>
Signed-off-by: Karel Zak <kzak@redhat.com>
The implementation has not been ready for I/O errors and it seems that
there is no elegant way how to resolve this issue. Linux returns
SIGBUS on mmap errors and play with signals (or longjumps) in shared
library is really bad idea.
It also seems that mmaped devices have some unexpected side-effects
with page-cache where for example dd returns old data for already
modified device etc.
Signed-off-by: Karel Zak <kzak@redhat.com>
Add some more tests:
* error handling "unknown arch" and "unknown command"
* "noop" test with host arch and no other options
* all options except --uname-2.6
* --uname-2.6 whithout any other options but handle fatal
glibc error "kernel too old" (with debug output)
* add a "real" --uname-2.6 test which validates uname(1)
output
Note the "kernel too old" cases are systems where glibc was
configured to support only kernels > 3.0. On some archs
(e.g. x86) --uname-2.6 still works with such glibc because
2.6.39 had all needed features on board (e.g. vdso).
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806911
Some people reported segfaults (after execvp) but I can only
reproduce it on arm* and aarch64 qemu-user-space builds. We
don't need to fix our tests for such broken systems where
also many other tests fail currently.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
There is a segfault in do_shm_global() when ipc_shm_get_info() return 0 and
ipc_shm_free_info() is called.
When no shm id is found, the memory allocated in shmds by ipc_shm_get_info() is
already free when ipc_shm_free_info() is called.
Move ipc_shm_free_info(shmds) inside the if statement where at least one shm id
is found.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Later version of bcache add different checksum types, and allow for superblocks
greater than 4k - skipping the checksum check (as in most other probes) is the
easiest solution.
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
If the root account is locked and no password was provided then the terminal
line is not set back to do echo of the input. This correct a small overlook
in commit 7ff1162e67
Signed-off-by: Werner Fink <werner@suse.de>
Nowadays, most Intel CPUs have "cpuid faulting" available which could trap
the execution of "cpuid" instruction when CPL>0 with GP fault. Thus,
"cpuid" instruction could trap to Xen hypervisor on the paravirtualized PV
guest on most servers today, except on old CPUs prior to 2011. On CPU after
2011, Xen will put "XenVMMXenVMM" on both HVM and PV guests, which could
have lscpu command erroneously classify the guest as type "full". The
current lscpu command, which is based on "cpuid" instruction, still assumes
that it will not cause the trap to Xen hypervisor on Xen PV guest and uses
/proc/xen to identify whether it's running on PV DomU or not. To identify
this kind of information under the help of
/sys/hypervisor/properties/features would be more accurate for the CPU
nowadays. The bit 5 (XENFEAT_mmu_pt_update_preserve_ad) of the features
will be set only when it's running on Xen PV domain. The combo of bit 3 and
8 (XENFEAT_supervisor_mode_kernel and XENFEAT_hvm_callback_vector) will be
set simultaneously only when it's running on Xen PVH domain.
[kzak@redhat.com: - add path_exist()]
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The patch has been planned for weeks and now the kernel part is
already in Linus' tree. It's a new feature, but it's probably better
to merge the userspace stuff now (v2.28 rc1) than wait next 6 months
for the next util-linux release.
Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak
Yuri Chornoivan
Sebastian Rasmussen
Rafael Fontenelle
Jakub Bogusz
Benno Schulenberg
Takeshi Hamasaki
Antonio Ceballos Roa
Philipp Thomas
Petr Písař
Mike Frysinger
Ruediger Meier
Kaligule
Sami Kerola
Romain Naour
Kent Overstreet
Werner Fink
Dongli Zhang