- verify that the new partition fits to the area if the size of the
has not been modified
- fix remaining space calculation (yes, brown-paper-bag bug..)
- offer also space before first partition as free space
Signed-off-by: Karel Zak <kzak@redhat.com>
The monitor supports utab only (as documented). It's application
responsibility to use libmount in the right way. It's overkill to
check for valid environment during monitor initialization.
For example systemd checks for regular mtab during boot, it's better
than try to be smart later in libmount monitor when system is already
running.
Signed-off-by: Karel Zak <kzak@redhat.com>
The example use of logger --journald in the man page has a couple of flaws:
- It's missing a "MESSAGE=" field. This is supposed to be the primary
human readable text. Without it the log entry is invisible in a
plain "journalctl" output.
- The MESSAGE_ID is supposed to be a 128-bit hexadecimal string that
globally uniquely identifies the message type.
One can generate such an id with "journalctl --new-id".
This patches fixes the above and also changes the example to use a
here-document instead of printf. In my opinion it makes the expected
multi-line data format more obvious.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
The requirement for gettext 0.18 was introduced by commit e3e16717
to pass --no-wrap option to msgmerge tool, which I guess improves
the process of updating po files for translators. At the same time,
unfortunately, it makes building from git fail on a RHEL/CentOS 6
system, as it comes with gettext 0.17.
Use the existing hack in autogen.sh to allow building with gettext 0.17,
with an appropriate warning so that the user is aware:
warning: forcing autopoint to use old gettext 0.17
The only negative side effect of this patch I am aware of is
if gettext-0.17 is used, then --no-wrap is not being passed
to msgmerge (although msgmerge 1.17 already supports it), because
Makefile.in.in that comes with gettext 0.17 doesn't have MSGMERGE_OPTIONS.
From my POV, this is way better than to not being able to build.
NOTE if gettext 0.18.3 is installed, it is used and this patch
doesn't change anything; it only allows gettext 1.17 to be used
if this is all we have.
Cc: Benno Schulenberg <bensberg@justemail.net>
Cc: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Since commit 50d096a macro m4_ifblank is used, but as it is only
available in autoconf-2.64, on CentOS 6 system we end up with:
> $ ./autogen.sh
> configure:25396: error: possibly undefined macro: m4_ifblank
> If this token and others are legitimate, please use
> m4_pattern_allow.
> See the Autoconf documentation.
> [root@kir-ovz2 util-linux]# autoconf --version
> autoconf (GNU Autoconf) 2.63
So, the obvious thing to do would be to raise AC_PREREQ to 2.64
in configure.ac. But, given the facts that
- autoconf 2.64 is not available for RHEL/CentOS 6,
- the only need is one small macro,
it's better to just add the missing macro.
While at it, add the m4_ifnblank, too.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
We care about /proc/device-tree/compatible content...
The patch also removes unnecessary path_exist(), it seems good enough
to call open() rather than access() + open().
Addresses: https://github.com/karelzak/util-linux/issues/218
Signed-off-by: Karel Zak <kzak@redhat.com>
configure should include errno.h instead of argp.h when
checking for presence of program_invocation_short_name
uclibc defines this to be const char* unlike util-linux-ng
which defines this to be char* so this error goes unnoticed
on glibc/eglibc systems.
here is the error it fixes
in file included from mountP.h:14:0,
from cache.c:29:
/home/kraj/work/slugos/build/tmp-slugos-uclibc/sysroots/nslu2le/usr/include/errno.h:55:46: error: conflicting types for '__progname'
../../../include/c.h:118:14: note: previous declaration of '__progname' was here
make[3]: *** [cache.lo] Error 1
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Jonathan Liu <net147@gmail.com>
This allows Sunday based week 54 be highlighted, and deny week 54 for
Monday based weeks when year has only 52 weeks.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Jan 1 is always First week, and year always has 53 weeks. The week 53
may be cut short, e.g., it may and often has fewer than 7 days. Every
year 28 year intervals US week numbering continues all the way to 54th
week, such as 1972, 2000, and 2028.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1249486
Reported-by: Michal Toth
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Very long mount lines from the kernel (either from escaping or from giant
option lists) could exceed BUFSIZ, leading to parsing failures. This
adds a test for the condition.
Signed-off-by: Kees Cook <keescook@chromium.org>
Based on patch from Kees Cook, he wrote:
> The kernel's maximum path length is PATH_MAX (4096). The use of BUFSIZ
> (8192) would seem sufficient for reading mountinfo files, but it's
> not. Paths may contain escaped characters (requiring 4x as many bytes
> to read), and filesystem options are of unknown length. To avoid
> mounts being either intentionally or unintentionally hidden from
> libmount and its users, we must accept arbitrary length lines when
> parsing.
>
> Long valid entries are currently ignored, with warnings like this:
> mount: /proc/self/mountinfo: parse error: ignore entry at line 11.
> mount: /proc/self/mountinfo: parse error: ignore entry at line 12.
>
> Instead of using a malloc on every line parsed from mount files, do it
> once per mount file context, growing it as needed. The general case
> will never grow it.
I have moved the parser stuff to the new struct libmnt_parser, maybe
we can move more things (e.g. libmnt_table->fmt) to this struct later.
Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Karel Zak <kzak@redhat.com>