'c' was missing from the optstring, causing the error:
$ unshare --user -c
unshare: invalid option -- 'c'
Try 'unshare --help' for more information.
Fixes: 4175f29e62 ("unshare: add --map-current-user option")
Signed-off-by: Matthew Harm Bekkema <id@mbekkema.name>
* 'dmverity_options' of https://github.com/bluca/util-linux:
verity: add support for Forward Error Correction options
verity: ensure that hash_device and root_hash[_file] are passed together or not at all
verity: add new verity.roothashfile option
Allow users to point mount to a file to read the roothash, in addition
to passing it inline.
Allows a volume managed by a systemd mount unit to be updated without
changing the mount unit content itself, for easier and more user friendly
servicing.
* 'kill-pidfd' of https://github.com/kerolasa/util-linux:
kill: use pidfd system calls to implement --timeout option
build-sys: add missing NR underscore to UL_CHECK_SYSCALL()
The file is originally from libuuid, this library is under BSD
licence. Unfortunately, I have added LGPL header by accident to the
file (commit 0f23ee0c85).
The file under LGPL was modified (in relevant way) by Sami,
Christopher and me. We all agree with re-licensing back to BSD.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Christopher James Halse Rogers <chris@cooperteam.net>
Signed-off-by: Karel Zak <kzak@redhat.com>
The first line of the adjtime file is made of three numbers (see=20
hwclock.c):
- a drift factor as a decimal float
- the time of last adjust as a decimal integer
- a zero (for compatibility) as a decimal float.
but both man pages (hwclock.8 and adj_time.5) tell that the third
number is a decimal integer.
Of course this is harmless if somebody edits the adjtime file with
"0"=20 as the third number: it will be correctly read by hwclock
anyway. But if for some reason, a program reads the adjtime file and
expects an integer, it will fail, because hwclock writes O.OOOO0O as
the third=20 number.
Signed-off-by:: Pierre Labastie <pierre.labastie@neuf.fr>
Signed-off-by: Karel Zak <kzak@redhat.com>
When the requested shell matches the restricted shell, there is no reason
to issue a warning, since we will be doing precisely as requested.
Signed-off-by: Jouke Witteveen <j.witteveen@gmail.com>
The following new options are added:
verity.hashdevice
verity.roothash
verity.hashoffset
The source path will be used as a dm-verity object, and will be
opened using libcryptsetup APIs.
A new --with-cryptsetup build-time option is added, which adds a
dependency on libcryptsetup. To ease bootstrapping, given libcryptsetup
build-depends on util-linux for libuuid, if --with-cryptsetup=yes but
libcryptsetup is not installed only a warning will be printed at
configure time rather than an error. This way stage0/first stage/ring0
builds can use the same configure options but avoid installing
cryptsetup to get a working base set, and then rebuild util-linux in
the next step of the boostrapping process.
If verity options are selected but cannot be fullfilled due to lack of
dependencies, mounting a volume will fail even if using a loop device
would work as a fallback, to avoid silently skipping integrity checks.
Not sure why, but on travis-ci the shell output is little bit
different, probably depends on shell version, etc.
Signed-off-by: Karel Zak <kzak@redhat.com>
At times there is need in scripts to send multiple signals to a process.
Often these cases require some amount of waiting before follow-up signal
should be sent.
One common case is process termination, where first script tries to kill
process gracefully but if that does not work SIGKILL is sent. Functionality
like that is commonly done by periodically checking if signalled pid exist
or not, and if it does another signal is sent possibly to an unrelated
process that reused pid number. That means polling a pid is prone to a data
race. Also if the first signal immediately kills the process one polling
interval is lost in sleep.
Another example when multiple signal need to be sent is various daemon
process control situations, such as Upgrading Executable on the Fly (see
reference). This happens to be the case that inspired change author to make
sequential signaling a little bit easier.
Reference: http://nginx.org/en/docs/control.html#upgrade
Pull-request: https://github.com/karelzak/util-linux/pull/902
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The file sys-utils/hwclock-parse-date.c is generated from .y and
stored in the build directory and "#include hwclock.h" is interpreted
relatively to the build tree rather than to source tree. We need
explicit -I compiler option to point to $srcdir for hwclock.
Signed-off-by: Karel Zak <kzak@redhat.com>