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>
Print a warning (instead of header) if --limits fails, like we did
it in past (2.20.1) and like we are still doing for --summary. Note
in past we were printing the same message like for --summary
"kernel not configured for ...", but actually this message is not
really correct.
This patch simply consolidates the current behavior. Probably we
should refactor it regarding warnings (stderr) and exit codes.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
This happens on Debian kFreeBSD and probably on Hurd too since
cde7699c. One should review this issue to fix it properly.
CC: Werner Fink <werner@suse.de>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Re-add backward compatibility which got lost in 058e8154.
Initializing unknown struct members to 0xdead is similar to
the fallback.
For upward compatibility ignore columns > 16 but not the whole
line (in case the kernel would add more columns in future).
Reported-by: Benno Schulenberg <bensberg@justemail.net>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
We want to parse 16 columns _per_row_ without mixing them up. The
existing code is unsafe for more or less columns and could even
run into endless loops. This patch assures that we parse row-wise
and really skip lines with columns != 16.
Probably somehow we could have also done this with fscanf() only.
Using fgets() additionally makes the code more easy to read and
to improve later.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
The old version has been pretty broken... the most important is to
keep swap options specified on command line as read-only template.
For example if we call "swapon --all" then we cannot modify the global
options for each fstab swap entry.
The another story has been control struct modification due to device
reinitialization etc.
This patch splits all to:
* struct swapon_control; top-level struct with command line options
* struct swap_device; this is device specific and never globally
maintained by swapon_control.
* struct swap_prop; used as global read-only template swap options
and per device swap options (when parse fstab).
Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818252
Signed-off-by: Karel Zak <kzak@redhat.com>
Now the first one of certain ambiguous tags wins. Alternatively to
this patch we could have called free() before xstrdup().
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Avoid ifdef which does not work with --sysroot. Our existing test
dumps produce even better output now for ppc and sparc.
The logic moved to the printing section.
CC: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
New BDS test based on hexdump, this commit provides:
bsd_0_64.BE - generated on ppc64
bsd_0_64.LE - generated on ppc64le
bsd_1_0.LE - generated on x86_64
bsd_1_0.BE - generated on s390
the last missing is Alpha where all is different :-)
Signed-off-by: Karel Zak <kzak@redhat.com>
It seems better to use hexdump rather than md5sum, but it means that
we have to gather hexdumps of the all possible BSD variants. For this
purpose will be introduced a new bsd fdisk test and to verify the
new hexdumps we can use this old test as both tests are exactly the
same.
Signed-off-by: Karel Zak <kzak@redhat.com>