Sorry detail-oriented people tend to wipe these out if they notice them.
Add in automated tools and lots of excess end-of-line spaces get wiped
out.
Addresses: https://github.com/karelzak/util-linux/pull/849
Signed-off-by: Karel Zak <kzak@redhat.com>
The ISO format specifically leaves the first 32kb blank so that it
can be used for other purposes, such as adding a partition table.
This is commonly used (e.g. by Endless and Fedora installation media) to
have partition 0 starting at sector 0 as a mountable iso9660 filesystem,
followed by more partitions (e.g. an EFI system partition).
Such layouts can be easily created by tools such as xorriso.
When plugging in a USB disk flashed with this type of ISO, blkid presents
a somewhat confusing view of the block devices. Taking the example of
a 'sda' disk with two partitions:
1. The "iso partition"
2. An unformatted partition
In such a setup, before the changes here, blkid will currently report the
ISO metadata attributes ID_FS_PUBLISHER_ID, ID_FS_UUID, ID_FS_LABEL, and
ID_FS_TYPE=iso9660 on both sda *and* sda1.
Since sda2 is unformatted, it won't have any ID_FS_ attributes of it's
own. And due to the following standard udev rule:
# for partitions import parent information
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
sda2 will actually import all of the ID_FS_ stuff from the parent device
sda.
The result at this point is that three udev devices all have the same
ID_FS_ attribute values, leading to strange results such as three
devices all racing to own the link in /dev/disk/by-uuid, so you can't
reliably do a mount-by-UUID.
Clean up this situation by detecting such partitioned ISO disks
in the superblock probing setup. If files of this kind are detected,
we now only expose the ISO metadata attributes on the specific partition
that points to the ISO data (and not the parent disk).
Signed-off-by: Daniel Drake <drake@endlessm.com>
sparc64 is reporting 128 as a total, but only 32 is online. So use only
online cpus for tests parallel runs.
$ nproc
32
$ nproc --all
128
$ lscpu
Architecture: sparc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 1
Model name: UltraSparc T5 (Niagara5)
Flags: sun4v
Signed-off-by: Anatoly Pugachev <matorola@gmail.com>
Old xfs.img cannot be used with current version (5.0) of xfsprogs, so create
a new version of xfs-v5.img.
Since I wasn't able to find logs on how was created old xfs.img, saving
create log with this commit message:
$ fallocate -l 16M xfs-v5.img
$ mkfs.xfs -L test-xfs-v5 xfs-v5.img
$ ./blkid -p -o udev xfs-v5.img | sort -V > tests/expected/blkid/low-probe-xfs-v5
$ xz -c xfs-v5.img > tests/ts/blkid/images-fs/xfs-v5.img.xz
Signed-off-by: Anatoly Pugachev <matorola@gmail.com>
* add $TS_ERRLOG for script stderr output
* add optional $TS_EXPECTED_ERR which points to expected/*/*.err
This change allows to keep track about stderr output from our commands
(already found bug in sfdisk...).
We do not have to depend on fragile stdout vs. stderr order (due to
different buffering semantic in different libc, etc.).
Signed-off-by: Karel Zak <kzak@redhat.com>
Triggered by commit f612c4c67 (tests: fix --unbuffered mode with
ASAN, 2019-08-27), which says:
Well, this patch sucks. It would be nice to have things in
the way how it has been original expected by Patrick's patch,
but ...
So this commit here effectively reverts it and instead tries to
improve the shortcomings of the original patch. First, it uses
env(1) to set ASAN_OPTIONS instead of directly adding it to the
args array to fix execution of "${args[@]}" "$@".
Second, it now supports both unbuffer(1) and stdbuf(1). The
latter uses LD_PRELOAD tricks, which doesn't play nicely with
ASAN, so it will not be used if ASAN has been requested. It's
still valuable to have support for both, as many more systems
will have stdbuf(1) from coreutils installed but not unbuffer(1)
from expect.
Signed-off-by: Karel Zak <kzak@redhat.com>
* remove obsolete stdbuf check
* check for unbuffer command in ts_run() than skip all test
Reported-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Karel Zak <kzak@redhat.com>
The test fdisk/oddinput hardcodes strings returned by strerror(3P) for
both the errors ENOENT and ENOTTY. As these strings are unportable,
convert the tests to use the test_strerror helper instead to convert
them with sed(1).
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Unfortunately, ASAN is pretty sensitive to LD_PRELOAD, but stdbuf from
coreutils is based on LD_PRELOAD. So, I have replaced stdbuf with
unbuffer (from expect pkg).
The another problem is "${args[@]}" "$@" which does not work as expected.
Well, this patch sucks. It would be nice to have things in the way
how it has been original expected by Patrick's patch, but ...
Signed-off-by: Karel Zak <kzak@redhat.com>
The col/multibyte test has a hardcoded error string as part of its
expected output that is returned by glibc's strerror(3P) function. Even
though many of these strings are the same across libc implementations,
they are not standardiced and some are certainly different. One example
is the string for EILSEQ on musl libc.
To fix this, we introduce a new test helper "test_strerror". The helper
can be invoked with an error code like "EILSEQ", which will cause it to
print out the the respective error message for that code. Note that
"test_strerror" cannot act on the error's value (e.g. 84 for EILSEQ), as
these aren't standardized either. Instead, we thus need to have an array
of the error's string representation ("EILSEQ") to its respective error
code (the define EILSEQ). The array can trivially be extended as
required, thus it is only sparsely populated with EILSEQ right now.
To fix the col/multibyte test, we introduce a call to sed(1) to replace
the strerror(3P) message from EILSEQ with "EILSEQ". Furthermore, as
we're running tests with the POSIX locale by default which treats all
bytes as valid multibyte sequences, we have to change to the C.UTF-8
locale instead to actually get an error.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
If reading an invalid multibyte sequence, column(1) will encode the byte
as "\x<hex>" instead. The tests try to verify that by piping "£" into
column(1). As the tests run with LC_ALL=POSIX by default, though, libc
implementations strictly adhering to the POSIX standard will treat all
characters as valid multibyte characters. As a consequence, no EILSEQ is
raised by mbtowc(3P) and the character is not encoded as hex, breaking
the test.
Fix this by setting LC_ALL=C.UTF-8. As "£" is a valid UTF-8 character,
we also change the test to use a proper illegal multibyte sequence.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
The input file "crash1" in the colcrt/regressions test contains the
illegal byte sequence "\x94\x7e". While "\x7e" is '~', "\x94" is not a
valid character. Thus, the test assumes that getwc(3P) will return
`WEOF` and set `errno=EILSEQ`, causing colcrt(1) to abort reading the
stream and thus not print the trailing '~'.
This assumption holds just fine for glibc as it will dutifully report
EILSEQ, but musl libc will happily read the complete stream without
complaining about the illegal character. But in fact, as tests run with
LC_ALL=POSIX by default, glibc's behaviour is wrong while musl is right.
Quoting mbrtowc(3P) from POSIX.1-2017:
[EILSEQ] An invalid character sequence is detected. In the POSIX locale an
[EILSEQ] error cannot occur since all byte values are valid
characters.
Fix the issue by running the colcrt tests with C.UTF8 locale.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
The tests in libfdisk/mkpart-full all rely on the buffering behaviour of
standard output and standard error streams, most importantly that stderr
is non-buffering and stdout is buffering. This doesn't hold on all libc
implementations when redirecting to a file, breaking the test suite on
such platforms.
Use `ts_run --unbuffered` to stop buffering of the standard output
stream to fix this.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
In the test cases "rename::exit_codes" and "rename::exit_codes", we rely
on the flushing behaviour of stderr and stdout streams relative to each
other. Streams in glibc will not flush on newlines if stdout is pointing
to a non-TTY file descriptor, but relying on this is fragile and may
break on systems with a different behaviour like musl libc.
Fix this by introducing a new parameter "--unbuffered" to `ts_run`. If
this parameter is passed and stdbuf(1) from coreutils is available, then
it will use it to disable buffering of standard output completely. Like
this, we can selectively run tests with this if ordering of messages
from stdout and stderr is being checked.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
x
The commit ab025087f9 has disabled error
message, but unfortunately it keeps wrong return code. This has been fixed
by commit 53ae7d60cf.
This commit add hit about it to docs and fix regression test too.
Signed-off-by: Karel Zak <kzak@redhat.com>
The test has been originally designed as usable on sparc, but now we
use it for many features which are MBR specific.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Co-Author: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The no follow option will allow user to distinct mount points from symbolic
links pointing to them. Arguably this is pretty pedantic option, mounting a
device or bind mount to a directory via symlink does not have or cause any
issues.
Addresses: https://github.com/karelzak/util-linux/issues/832
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The following commands manifests the problem. In old versions before
commit 4762ae9d60 ("column: use libsmartcols for --table"), both of them
should output with 2 "|"
echo '||' | column -o '|' -s '|' -t
echo '|| ' | column -o '|' -s '|' -t
Fixes: 4762ae9d60 ("column: use libsmartcols for --table")
Signed-off-by: Yousong Zhou <zhouyousong@yunionyun.com>
Reviewed-by: Sami Kerola <kerolasa@iki.fi>
As the title tells this change indeed fixes floating point exception, but
post processing as value overwrite feels a wrong. Possibly something in
input is making cpu set count to go wrong, but I could not get my head
around what could it be. Anyway avoiding division by zero seems better than
crashing so lets do this atleast for now.
Caused-by: e5f721132e
Addresses: https://github.com/karelzak/util-linux/issues/788
Reported-by: Lars Wendler <polynomial-c@gentoo.org>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The extra space was more obvious in json output. But as the expected test
output displays also the standard output can be effected by this change.
$ lscpu --json | jq '.lscpu | .[].field' | grep ': '
"L1d cache: "
"L1i cache: "
"L2 cache: "
"L3 cache: "
"Vulnerability L1tf: "
"Vulnerability Mds: "
"Vulnerability Meltdown: "
"Vulnerability Spec store bypass: "
"Vulnerability Spectre v1: "
"Vulnerability Spectre v2: "
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
From the test input string ':' characters are removed:
cat x86_64-epyc_7451/sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
* libblkid does not depend on libuuid anymore
* libncurses depends on libdl due to
$ ncursesw6-config --libs
-lncursesw -ltinfo -ldl
* new command hardlink (with dependence on libpcre2-8
* hwclock needs librt
Signed-off-by: Karel Zak <kzak@redhat.com>
Let's detect ASAN LDFLAGS in top level Makefile to make sure we call
tests with --memcheck-asan if build-system has been configured with
--enable-asan.
Signed-off-by: Karel Zak <kzak@redhat.com>
Elliott Mitchell
Karel Zak
Daniel Drake
Anatoly Pugachev
Radka Skvarilova
Sami Kerola
Patrick Steinhardt
Yousong Zhou