On Sun, May 12, 2019 at 10:25:34PM +0200, Thomas Trepl via lfs-dev wrote:
> Hi all,
>
> i just started a build of a new system. To my surprise, it failed in
> chap6 at e2fsprogs where it never stopped before.
> The reason for stopping is
>
> <snip>
> ake[1]: Leaving directory '/autolfs/sources/e2fsprogs-1.45.0/build/po'
> making install in scrub
> make[1]: Entering directory '/autolfs/sources/e2fsprogs-
> 1.45.0/build/scrub'
> MKDIR_P /usr/lib/e2fsprogs
> MKDIR_P yes
> INSTALL yes/e2scrub_all
> /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No
> such file or directory
> make[1]: *** [Makefile:447: install-crond] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory '/autolfs/sources/e2fsprogs-
> 1.45.0/build/scrub'
> make: *** [Makefile:434: install-progs-recursive] Error 1
> make: *** Waiting for unfinished jobs....
> make[1]: Leaving directory '/autolfs/sources/e2fsprogs-
> 1.45.0/build/lib/et'
> making install-shlibs in lib/ss
> make[1]: Entering directory '/autolfs/sources/e2fsprogs-
> 1.45.0/build/lib/ss'
> </snip>
>
> A look to the build/Makefile showed
>
> <snip>
> HAVE_UDEV = no
> UDEV_RULES_DIR =
> HAVE_CROND = yes
> CROND_DIR = yes
> HAVE_SYSTEMD = no
> SYSTEMD_SYSTEM_UNIT_DIR =
> </snip>
>
> Note the setting of CROND_DIR. I checked the configure script and
> found in line ~14500 a check on option $with_crond_dir=[yes,no]. If
> not set, yes is assumed. Later on, in case $with_crond_dir == yes, the
> test if /etc/cron.d exists and set with_crond_dir to /etc/cron.d if
> the directory is there. It remains "yes" if that directory does not
> exist. I assume that is the reason why CROND_DIR set to "yes" in the
> Makefile.
>
> What i really do not understand is why that happens now and never
> before? We have e2fsprogs-1.45.0 a good amount of time in the book,
> there is nothing new but if my reading of the configure script is
> correct, there is a fulminant logical error in it. Wonder why that
> never came up before.
>
> What do you think, am i right in interpreting the section in the
> configure script that there is a logical bug in it? If so, i do not
> get it why it comes up now and not at all the previous builds too...
>
> Btw, i specified --with-crond-dir=no and compilation/installation of
> e2fsprogs went fine.
>
I've just looked at my build from a couple of days ago -
checking for udev... no
checking for udev rules dir... no
checking for system crontab dir... yes
checking for systemd... no
make[2]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub'
../util/subst -t -f ../util/subst.conf ../../scrub/e2scrub_all.cron.in
e2scrub_all.cron
make[2]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub'
make[2]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub'
../util/subst -t -f ../util/subst.conf ../../scrub/e2scrub_all_cron.in
e2scrub_all_cron
chmod a+x e2scrub_all_cron
make[2]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub'
make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub'
MKDIR_P yes
make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub'
make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub'
MKDIR_P /usr/lib/e2fsprogs
make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub'
make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub'
INSTALL yes/e2scrub_all
make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub'
make[1]: Entering directory '/building/e2fsprog
INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron
make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub'
From that, I would expect to have a directory called 'yes'.
Fortunately, it was not *that* broken.
From my log of what got installed:
/usr/lib/e2fsprogs/e2scrub_all_cron
But since you disabled it to get the install to complete (and no,
I've no idea why the test has passed on all of my builds so far),
let's look at the script it installs:
#!/bin/bash
# Copyright (C) 2018 Oracle. All Rights Reserved.
#
# Author: Darrick J. Wong <[email protected]>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it would be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write the Free Software Foundation,
# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
# Run e2scrub_all from a cronjob if we don't have systemd and we're not
# running on AC power.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So, the cron job doesn't get run on systemd, and it only gets run if on
battery power. So my desktop systems where it has been installed,
but not referenced by my cron scripts, will not run it (see the rest
of the script, below).
on_ac_power() {
local any_known=no
# try sysfs power class first
if [ -d /sys/class/power_supply ]; then
for psu in /sys/class/power_supply/*; do
if [ -r "$psu/type" ]; then
type=$(cat "$psu/type")
# ignore batteries
[ "$type" = "Battery" ] && continue
online=$(cat "$psu/online")
[ "$online" = 1 ] && return 0
[ "$online" = 0 ] && any_known=yes
fi
done
[ "$any_known" = "yes" ] && return 1
fi
# else fall back to AC adapters in /proc
if [ -d /proc/acpi/ac_adapter ]; then
for ac in /proc/acpi/ac_adapter/*; do
if [ -r "$ac/state" ]; then
grep -q on-line "$ac/state" && return 0
grep -q off-line "$ac/state" && any_known=yes
elif [ -r "$ac/status" ]; then
grep -q on-line "$ac/status" && return 0
grep -q off-line "$ac/status" && any_known=yes
fi
done
[ "$any_known" = "yes" ] && return 1
fi
# Can't tell, just assume we're on AC.
return 0
}
test -e /run/systemd/system && exit 0
on_ac_power || exit 0
exec /sbin/e2scrub_all
Hmm, some of that looks as if it runs IFF on ac power (which in my
opinion would seem more sensible - running something which uses the
disk(s) when on battery sounds like a recipe for draining the
battery).
HOWEVER, when I look at e2scrub_all (a script, to remove snapshots)
I see that it seems to be run automatically from systemd.
Until now, I've relied on e2fsprogs, but this makes me start to
question that. It all sounds VERY weird.
ĸen
--
Before the universe began, there was a sound. It went: "One, two, ONE,
two, three, four" [...] The cataclysmic power chord that followed was
the creation of time and space and matter and it does Not Fade Away.
- wiki.lspace.org/mediawiki/Music_With_Rocks_In
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
