# whereis -m cal -M /usr/share/man/man1/ -f ls
cal: /usr/share/man/man1/cal.1.gz /usr/share/man/man1p/cal.1p.gz
ls: /usr/bin/ls /usr/share/man/man1/ls.1.gz
the -M also resets the search mask, so for 'ls' it returns also
binaries. That's bug. Expected result is:
# ./whereis -m cal -M /usr/share/man/man1/ -f ls
cal: /usr/share/man/man1/cal.1.gz /usr/share/man/man1p/cal.1p.gz
ls: /usr/share/man/man1/ls.1.gz
the search mask has to be sensitive only to -b -m -s options,
otherwise the semantic is pretty messy.
Signed-off-by: Karel Zak <kzak@redhat.com>
* use debug stuff from include/debug.h and make whereis(1) sensitive
to WHEREIS_DEBUG=0xffff mask
* fix problem with argv[] usage
# whereis -b -m -M /usr/share/man/man1 -B /usr/bin -f gcc
bin: /usr/local/bin
gcc: /usr/bin/gcc /usr/lib/gcc /usr/libexec/gcc /usr/share/man/man1/gcc.1.gz
the code ignores "-B" and /usr/bin is interpreted as search pattern,
expected result is:
# whereis -b -m -M /usr/share/man/man1 -B /usr/bin -f gcc
gcc: /usr/share/man/man1/gcc.1.gz /usr/bin/gcc
Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765306
Signed-off-by: Karel Zak <kzak@redhat.com>
To facilitate the calculation of 'cold' vs 'warm' Hardware Clock drift
factor the limit on the update period needs to be less than 8 hours.
4 hours should be enough drift to allow calculations that are not
grossly out of range.
For example, with a workstation that is shutdown every night the cold
drift factor can be significantly different than a drift factor based on
a 24 hour period.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
The new option allows to specify swap options by fstab compatible
string. The concept is the same as for mount(8).
swapon -o pri=1,discard=pages,nofail /dev/sda2
The advantage is that tools (like systmed) that parses fstab can call
swapon without translation from fstab options to swapon(8) command
line options.
Signed-off-by: Karel Zak <kzak@redhat.com>
There are cases where we need to refresh the
timestamps in the adjtime file without updating the
drift factor.
For example, with ntpd and an Eleven Minute Mode
kernel, we need to call systohc at shutdown to
facilitate drift correction. With the current
behavior hwclock will clobber the drift factor to
near zero, because the Hardware Clock and System
Clock are synced by Eleven Minute Mode. What
actually needs to be done is refresh the adjtime
file timestamps and not calculate a new drift
factor.
Because it is a manual process to craft a good
Hardware Clock drift factor, that is, there is no
automated method that will produce a good drift
factor, this patch changes the default drift
calculation behavior to off, and it is turned on
by using the --update-drift option. Once we have a good
drift factor for a given machine we do not want
anything clobbering it, including an administrator
forgetting to turn off recalculation. A system
administrator should make a concious effort in
telling hwclock with the --update-drift option that
(s)he wants to recalculate the drift factor.
Without using the --update-drift option with calibrate
operations only the timestamps are refreshed in
the adjtime file. With the --update-drift option the old
default behavior of refreshing the timestamps and
updating the drift factor is performed.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
When hctosys is used at boot time, making it the
first caller of settimeofday, the responsibility
of setting persistent_clock_is_local is thrust
upon it. Currently hctosys always leaves this
variable uninitialized. This causes a Hardware
Clock configured to use the local timescale to be
clobbered with the UTC timescale by the kernel's
NTP eleven minute mode.
This patch fixes this hctosys bug, by having it
properly set persistent_clock_is_local according
to the time scale configured for the Hardware
Clock.
It does this via the kernel warp_clock function
but this in inconsequential, because we set the
system time immediately afterward.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Allowing hctosys to drift compensate facilitates:
More precise setting of the System Clock early in
the boot process when --adjust cannot be used
because the file system is not writeable.
Applies sub second drift corrections immediately,
where as --adjust cannot.
Reduces boot time by not calling hwclock multiple
times, e.g., --hctosys early before fsck when the
file system is read-only, then --adjust later when
the file system is read-write and --hctosys again
for drift correction.
Use of --adjust elsewhere may no longer be
necessary.
Part II
After the original submission of this patch I
realized that now all operations except --systz
require drift corrected Hardware Clock time.
Therefore, it should be done only once early in
the process. Upon implementation of that premise
many improvements were facilitated:
* Adds drift correction to --hctosys.
* Adds setting system time with sub-second precision.
* Adds --get, a drift corrected 'show' operation.
* Improves drift factor calculation precision while
greatly simplifying its algorithm.
* Fixes --show bug, printing integer sub-seconds, and
now uses a more intuitive positive value.
* Fixes --predict bug, drift correction must be
negated to predict future RTC time.
* Reduces the number of function arguments and
lines of code.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
The zero may be valid size and start of the partition. This patch
introduces:
fdisk_partition_has_start()
fdisk_partition_has_size()
fdisk_partition_unset_size()
fdisk_partition_unset_start()
to make it possible to work with zero. The feature is internally
implemented by magic constant ((type) -1) for undefined sizes and
offsets.
Signed-off-by: Karel Zak <kzak@redhat.com>
If offset (range[0]) is greater than device size (blksize), the variable 'end'
will be greater than blksize, and range[1] (length) will be recalculated.
The underflow happens when subtracting range[0] (offset) from blksize, thus
range[1] will be the result of an underflow. The bug leads to unwanted behavior
from the program, where range[1] is likely to be a high number and then will
discard a considerable amount of blocks from the device. The fix consists of
exitting the program with an error message when the condition stated above is
true. Spotted while auditing the code.
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
The system libtool program has architecture dependent behaviour. It is
therefore unavailable in cross build environments. The only place it was
used in util-linux is autogen.sh to determine the availability of
libtool. All other places correctly use libtoolize or
$(top_builddir)/libtool.
Signed-off-by: Helmut Grohne <helmut@subdivi.de>
Federico Simoncelli
Karel Zak
J William Piggott
Sami Kerola
Andreas Henriksson
Raphael S. Carvalho
Helmut Grohne
Benno Schulenberg