right now, we assume "find", but it adds any number of
arguments next to that.
change it instead to support any command, where the
assumption is that it would generate a list of files
and directories.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Use fe_ with a new function, scankconfig, to do the
same thing. Not only is this simpler, it now also
operates on all coreboot configs for a given target,
whereas it previously only operated on the first one.
This is useful for cases where one config might use a
file that the other one does not; in practise, we don't
do this yet, but it's a theoretical possibility
Also: don't use the function check_defconfig, which is
now redundant and has been removed.
That function also conflicted with another function by
the same name in mk, but fortunately didn't cause an
issue in practise, due to how sh works; when vendor.sh
was used, it was without running the tree commands,
except under a separate lbmk instance.
So this is a simplification, a feature enhancement and
even a bug fix, all wrapped into one!
Signed-off-by: Leah Rowe <leah@libreboot.org>
Don't directly call a variable. Call a function that
checks the variable instead.
The new err function also checks whether an exit was
actually done, and exits 1 if not.
If an exit was done by the given function, but the exit
was zero, this is also corrected to perform an exit 1.
This fixes a longstanding design flaw of lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's not a lot of code, and takes less than a second.
the previous change uses x instead of ?, but this would
cause an error if the nvmutil was already built, because
the makefile might cause a build to be skipped.
therefore, force a re-build to mitigate the error.
Signed-off-by: Leah Rowe <leah@libreboot.org>
A user reported that '?' causes an error on zsh. See:
https://codeberg.org/libreboot/lbmk/issues/261
For example:
./mk inject libreboot-XXXXXX.tar.xz setmac ??:??:??:??:??:??
The user got:
zsh: no matches found: ??:??:??:??:??:??
The mitigation here is to double-quote, e.g.:
./mk inject libreboot-XXXXXX.tar.xz setmac "??:??:??:??:??:??"
However, a lot of people won't do that. Therefore, I will
retain the current behaviour but support x/X for randomness.
Now lbmk uses x by default, instead. I will now update the
documentation, accordingly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
not to be confused with /tmp
we use ./tmp inside the lbmk work directory, for large files,
because /tmp might not be very big, or might be a tmpfs
Signed-off-by: Leah Rowe <leah@libreboot.org>
In the mk script, we need fx_ to not return errors on the
find command, since it's searching a bunch of directories
where some of them may not exist.
All other instances where fx_ is used, must return an error
if the directory being searched doesn't exist.
For this, fe_() is introduced, which does the same as fx_
but with this much stricter check.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We have a lot of places in lbmk where the output of find is
used, and then some function is executed on the result.
This is messy, and bloats several of these functions.
Now this is unified, into a new function: fx_
What fx_ does is execute a given function, for each result
found, with the arguments for a find command appended.
For example:
find -name ".git"
If you wanted to do: foo "$arg"
Where "arg" is a search result from find, and you wanted
to execute "foo" on each one, you would do:
fx_ foo -name ".git"
The find utility does have an -exec feature, but I've found
that it only works for executables, not functions.
fx_ does not return errors, so "foo" in this example
would have to do its own error handling.
Signed-off-by: Leah Rowe <leah@libreboot.org>
cbmk creates TMPDIR as /tmp/xbmk_*, but it's theoretically
possible that something could re-export it by mistake.
this change retains the same initialisation, but further
use is now via a new variable "xbmktmp", that stores the
value of TMPDIR upon cbmk's initialisation of it.
this reduces the chance of such a bug in the future, as
described above, so it is a preemptive/preventative fix.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i can't call $err (variable), because it's set
to fail_inject. fix this infinite loop, which
was an oversight in the previous commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I was using a complicated method of knowing whether
the current instance was parent or a child, to know
whether the lock file and TMPDIR needed to be purged.
It was quite error-prone too. Instead, I'm now handling
it directly from within the if statement that previously
initialised xbmk_parent=y, forking ./mk from there.
The forked instance would not trigger that if clause
again, since then TMPDIR is created, thus avoiding
recursion.
This is an improvement because it doesn't rely on how
the parent handles exit statuses, and it ensures that
the lock/tmp files are never accidentally deleted.
Even if a given program/script that cbmk runs would
export TMPDIR, it doesn't matter because cbmk doesn't,
so it would be unaffected.
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of running pwd all the time, run it once in lib.sh,
and export PWD.
for cbmk-specific use of PWD, use xbmkpwd, which contains
the value of PWD as was set by the pwd utility in lib.sh.
many parts of cbmk rely on pwd, and it *must* be correct.
this change adds basic error handling, since pwd can in
fact return errors in some cases.
Signed-off-by: Leah Rowe <leah@libreboot.org>
PWD could be anything, if the user manually exported
it before running cbmk.
always run pwd instead, to get the real string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
several code lines were condensed together, which
make them less readable. make the code more readable
by having separate commands on separate lines.
i previously did this during my manic build system
audits of 2023 and 2024; condensing lines like this
is overly pedantic and serves no real purpose.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is based on include/vendor.sh from this lbmk
revision:
3c9f4be76f61c80060b4238eff96ef268272cffb
This version doesn't support downloading/injecting
vendor files such as Intel ME; that's what the lbmk
version is for.
If you try to run this on a Libreboot archive that
uses vendor files, the script will see that there is
a hash file present, and not inject a new MAC.
HOWEVER: if the hash file is not present, it will
work just fine, but again only change the MAC. That
way, you can use the "./mk inject" command from lbmk,
to insert files such as Intel ME. In practise, due to
the design checking out a specific cbfstool version
based on the board config, you can only use a config
in this way that's present on both Libreboot and
Canoeboot, such as the E6400 images; the E6400 images
on Libreboot insert an Nvidia GPU ROM, but Canoeboot
does not.
You don't need to run this on Libreboot tarballs, because
the Libreboot version can be used anyway. Canoeboot is
mostly a pointless project, but I maintain it for fun. I
make it adhere to GNU FSDG for fun, even though I disagree
with it; Libreboot's binary blob reduction policy is better.
The reason for this design is because of GNU FSDG,
which Canoeboot complies with to the letter. It states
that any such project must not distribute, promote or
otherwise boost proprietary software in any way; it must
steer the user only towards entirely free software.
It also doesn't support nuking. It only sets MAC
addresses; the "setmac keep" command is not present,
because it's pointless, but these work, e.g.:
./mk inject tarball.tar.xz
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac restore
./mk inject tarball.tar.xz MACADDRESS
./mk inject tarball.tar.xz ??:aa:bb:??:22:01
etc
Same command structure as setmac for lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe