Despite that dracut has a hard dependency on bash,
its modules doesn't, dracut only has a hard dependency on bash for
module-setup (on a fully usable machine). Inside initramfs, dracut
allows users choose from a list of handful other shells, e.g. bash,
busybox, dash, mkfsh.
In fact, my local machine's initramfs is being built with dash,
and it's functional for a very long time.
Before 64025fa3a (Silence 'make checkbashisms', 2020-08-20), we also
allows our users to have that right, too.
Let's fix the problem 'make checkbashisms' reported and allows our users
to have that right, again.
For 'plymouth' case, let's simply run the command inside the if instead
of checking for the existence of command before running it, because the
status is also failture if plymouth is unavailable.
While we're at it, let's remove an unnecessary fork for grep in
zfs-generator.sh.in and its following complicated 'if elif fi' with
a simple 'case ... esac'.
To support this change, also exclude 90zfs from "make checkbashisms"
because the current CI infrastructure ships an old version of
"checkbashisms", which complains about "command -v", while the current
latest "checkbashisms" thinks it's fine. In the near future, we can
revert that change to "Makefile.am" when CI infrastructure is updated.
Reviewed-by: Gabriel A. Devenyi <gdevenyi@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Closes#11244
Not all systems / distros have a `/bin/bash`, and these scripts are
more difficult to run at development time.
For example, my system is NixOS which doesn't have a /bin/bash. This
is not a problem for NixOS building ZFS as a package: the build
environment automatically replaces these shebangs with corrected
paths.
The problem is much more annoying at development time: either the
scripts don't run, or I correct them for my local machine and deal with
a perpetually dirty work tree.
Before committing this patch I confirmed there are existing scripts
which use `/usr/bin/env` to locate bash, so I am thinking this is a
safe transformation.
There are a handful of other shebangs in this repository which don't
work on my system. This patch is useful on its own specifically for
`commitcheck.sh`, otherwise I can't validate my commits before
submission.
Here are the remaining shebangs which NixOS systems won't have:
1274 #!/bin/ksh -p
91 #!/bin/ksh
89 #! /bin/ksh -p
2 #!/bin/sed -f
1 #!/usr/bin/perl -w
1 #!/usr/bin/ksh
1 #!/bin/nawk -f
plus this which will create an invalid shebang in
`tests/zfs-tests/tests/functional/mv_files/mv_files_common.kshlib`:
echo "#!/bin/ksh" > $TEST_BASE_DIR/exitsZero.ksh
I chose to leave those alone for now, and gauge the interest in this
much smaller patch first.
The fixes for these are easy enough by simply using `/usr/bin/env ksh`:
91 #!/bin/ksh
1 #!/usr/bin/ksh
The fix for the other set is much trickier. Quoting the GNU coreutils
manual:
Most operating systems (e.g. GNU/Linux, BSDs) treat all text after
the first space as a single argument. When using env in a script it
is thus not possible to specify multiple arguments.
and not all `env`'s support arguments.
Mine (GNU Coreutils 8.31) does, though this feature is new since
April 2018, GNU Coreutils 8.30:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=668306ed86c8c79b0af0db8b9c882654ebb66db2
and worse, requires the -S argument:
-S, --split-string=S process and split S into separate arguments;
used to pass multiple arguments on shebang
lines
Example:
$ seq 1 2 | $(nix-build '<nixpkgs>' -A coreutils)/bin/env "sort -nr"
/nix/[...]-coreutils-8.31/bin/env: ‘sort -nr’: No such file or directory
/nix/[...]-coreutils-8.31/bin/env: use -[v]S to pass options in shebang lines
$ seq 1 2 | $(nix-build '<nixpkgs>' -A coreutils)/bin/env "-S sort -nr"
2
1
GNU Coreutils says FreeBSD's `env` does, though I wonder if FreeBSD's
would be unhappy with the `-S`:
https://www.gnu.org/software/coreutils/manual/html_node/env-invocation.html#env-invocation
BusyBox v1.30.1 does not, and does not have a `-S`-like option:
$ seq 1 2 | $(nix-build '<nixpkgs>' -A busybox)/bin/env "sort -nr"
env: can't execute 'sort -nr': No such file or directory
Toybox 0.8.1 also does not, and also does not have a `-S` option:
$ seq 1 2 | $(nix-build '<nixpkgs>' -A toybox)/bin/env "sort -nr"
env: exec sort -nr: No such file or directory
---
At any rate, if this patch merges and the remaining ~1,500 are updated,
the much larger patch should probably include a checkstyle-like test
asserting all new shebangs use `/usr/bin/env`. I also don't mind
dealing with NixOS weirdness if the project would prefer that.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by: Graham Christensen <graham@grahamc.com>
Closes#9893
The new zfs-import.target should be used in place of the
zfs-import-*.service units.
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes#6964
'zfs load-key -a' will only be called if needed. If a dataset not
needed for boot does not have its key loaded (home directories for
example) boot can still continue.
zfs:AUTO was not working via dracut, so we still need the generator
script to do its thing.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: loli10K <ezomori.nozomu@gmail.com>
Signed-off-by: Matthew Thode <mthode@mthode.org>
Closes#6982Closes#7004
The behavior of the Dracut module was very wrong before.
The correct behavior: initramfs should not run `zfs-mount` to completion
if the two generator files exist. If, however, one of them is missing,
it indicates one of three cases:
* The kernel command line did not specify a root ZFS file system, and
another Dracut module is already handling root mount (via systemd).
`mount-zfs` can run, but it will do nothing.
* There is no systemd to run `sysroot.mount` to begin with.
`mount-zfs` must run.
* The root parameter is zfs:AUTO, which cannot be run in sysroot.mount.
`mount-zfs` must run.
In any of these three cases, it is safe to run `zfs-mount` to completion.
`zfs-mount` must also delete itself if it determines it should not run,
or else Dracut will do the insane thing of running it over and over again.
Literally, the definition of insanity, doing the same thing that did not
work before, expecting different results. Doing that may have had a great
result before, when we had a race between devices appearing and pools
being mounted, and `mount-zfs` was tasked with the full responsibility
of importing the needed pool, but nowadays it is wrong behavior and
should be suppressed.
I deduced that self-deletion was the correct thing to do by looking at
other Dracut code, because (as we all are very fully aware of) Dracut
is entirely, ahem, "implementation-defined".
Tested-by: @wphilips
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Closes#5157Closes#5204
- In older systems without sysroot.mount, import before dracut-mount,
and re-enable old dracut mount hook
- rootflags MUST be present even if the administrator neglected to
specify it explicitly
- Check that mount.zfs exists in sbindir
- Remove awk and head as (now unused) requirements, add grep, and
install the right mount.zfs
- Eliminate one use of grep in Dracut
- Use a more accurate grepping statement to identify zfsutil in rootflags
- Ensure that pooldev is nonempty
- Properly handle /dev/sd* devices and more
- Use new -P to get list of zpool devices
- Bail out of the generator when zfs:AUTO is on the root command line
- Ignore errors from systemctl trying to load sysroot.mount, we only
care about the output
- Determine which one is the correct initqueuedir at run time.
- Add a compatibility getargbool for our detection / setup script.
- Update dracut .gitignore files
Signed-off-by: <Matthew Thode mthode@mthode.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes#4558Closes#4562
Dracut and Systemd updated how they integrate with each other, because
of this our current integrations stopped working (around the time
4.1.13 came out). This patch addresses that issue and gets us booting
again.
Thanks to @Rudd-O for doing the work to get dracut working again and
letting me submit this on his behalf.
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Signed-off-by: Matthew Thode <mthode@mthode.org>
Closes#3605Closes#4478
