The bug has been introduced during column(1) rewrite. The function
read_input() need to skip leading space only temporary to detect empty
lines, but the rest of the code has to use the original buffer (line).

Addresses: https://github.com/karelzak/util-linux/issues/575
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1560283


Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Addresses: https://github.com/karelzak/util-linux/issues/512


Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Vaclav Dolezal <vdolezal@redhat.com>

Fixes one leak and one unchecked allocation error.

[kzak@redhat.com: - don't call fdisk_ask_menu_get_result()
                    after failed fdisk_do_ask()]

Signed-off-by: Vaclav Dolezal <vdolezal@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

If partition does not require alignment, then don't call LBA align
function and don't use size-=1 (fdisk_align_lba_in_range() returns
unmodified size and we call size=-1 more than once for the same size).

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Reported-by: Laszlo Varkonyi <vlsoftsystems@gmail.com>
Signed-off-by: Karel Zak <kzak@redhat.com>

The MBR partition pseudo-UUID is generated from table ID and partition
partno. The final UUID size limit is 37 bytes. The table ID has to be
restricted to keep compiler happy (for MBR the table ID is 8 bytes
as string).

Signed-off-by: Karel Zak <kzak@redhat.com>

Addresses: https://github.com/karelzak/util-linux/issues/499


Signed-off-by: Karel Zak <kzak@redhat.com>

Addresses: https://github.com/karelzak/util-linux/issues/498


Signed-off-by: Karel Zak <kzak@redhat.com>

It's probaly good idea to reset lose counter when we fallback from
getrandom() to /dev/urandom.

Signed-off-by: Karel Zak <kzak@redhat.com>

The getrandom() does not have to return all requested bytes (missing
entropy or when interrupted by signal). The current implementation in
util-linux stupidly asks for all random data again, rather than only
for missing bytes.

The current code also does not care if we repeat our requests for
ever; that's bad.

This patch uses the same way as we already use for reading from
/dev/urandom. It means:

 * repeat getrandom() for only missing bytes
 * limit number of unsuccessful request (16 times)
 * fallback to /dev/urandom on ENOSYS (old kernel or so...)

Addresses: https://github.com/karelzak/util-linux/issues/496


Signed-off-by: Karel Zak <kzak@redhat.com>

If getrandom() is called with nbytes ≥ 256 then it can return with less than the requested
bytes filled.

In this case we *could* adjust the buffer by the number of bytes actually read, but it's
simpler to just redo the call.

The 3.16 kernel is supported until 2020, and various distros have kernels of the same
vintage. It's entirely possible for code built against newer headers to be run against
these kernels, so fall-back to the old “read /dev/{u,}random” method if the kernel doesn'
support getrandom()

Someone requested explicitly mentioning how tabs are escaped,
in addition to the already existing spaces example.

Addresses: https://bugs.debian.org/580047


Signed-off-by: Andreas Henriksson <andreas@fatal.se>

This removes bogus write failed warning.

$ wdctl
wdctl: write failed: Invalid argument
Device:        /dev/watchdog
[...]

Signed-off-by: Sami Kerola <kerolasa@iki.fi>

Signed-off-by: Karel Zak <kzak@redhat.com>

It seems that on some systems (e.g. RHEL7) the libc function
getaddrinfo() is not able to translate ::ffff: address to IPv4. The
result is 0.0.0.0 host address in the last(1) and utmpdump(1) output.

 /sbin/login -h "::ffff:192.168.1.7"

utmpdump:

  [7] [03926] [1   ] [user1   ] [pts/1       ] [::ffff:192.168.1.7  ] [0.0.0.0        ] [Thu May 12 17:49:50 2016    ]

Not sure if this is about order of the getaddrinfo() results, system
configuration or libc version. It's irrelevant for login(1). We have
to be robust enough to write usable address to log files everywhere.

The solution is to detect IPv4-mapping-to-IPv6 and use IPv4 for utmp.

Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1296233


Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Signed-off-by: Karel Zak <kzak@redhat.com>

Commit 4762ae9d removed mtsafe_strtok() but left behind calls to wcstok
and wcspbrk. This leads to build failures when libc does not have the
wide-character functions, like some uClibc builds.

Solve the problem by using strtok_r and strpbrk when HAVE_WIDECHAR is
not defined.

Fixes:
  http://autobuild.buildroot.net/results/fd8a1a8e0cef3aeed9588540e8e663664f6b43aa
  http://autobuild.buildroot.net/results/5ad73ea8b471321988c50d80a5e50d4504151dd6
  http://autobuild.buildroot.net/results/04411b7280dc51ecd51236967981a42352bbeb3e



Signed-off-by: Carlos Santos <casantos@datacom.ind.br>

Signed-off-by: Karel Zak <kzak@redhat.com>

Assume that /proc is not mounted instead of returning an error when we
are unable to open the mounts and mountinfo files in /proc. Also set
cxt->mtab back to NULL so that it gets properly parsed when we check if
the next filesystem is mounted.

The goal is to have mount -a work when /proc is not mounted, typically
with /proc on the first line of fstab.

Signed-off-by: Ivan Delalande <colona@arista.com>

For some reason kernel commit e980f62353c697cbf0c4325e43df6e44399aeb64
add extra warning when the ioctl is used for DM devices. It seems we
can avoid this ioctl when the device has dm/uuid.

Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1469532


Signed-off-by: Karel Zak <kzak@redhat.com>

The commit 8ffa3b65

 has fixed PMBR
CHS addresses initialization to be more close to UEFI standard.

-000001c0  01 00 ee fe ff ff 01 00  00 00 ff 8f 01 00 00 00
+000001c0  02 00 ee ff ff ff 01 00  00 00 ff 8f 01 00 00 00

Signed-off-by: Karel Zak <kzak@redhat.com>