they were always re-downloading every time.
i've basically re-written most of xbmkget.
there was some erroneous conditions under which
it wrongly deleted the cached file, resulting in
it being downloaded again.
Signed-off-by: Leah Rowe <leah@libreboot.org>
split the actual bootstrapping to getvfile()
setvfile only sets the config, but then it will
call getvfile() to act on that config.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i moved out more code to vendor.sh, to reduce the
amount of lbmk-only code on inject.sh
this should reduce the number of merge conflicts
even further, when cherry picking from lbmk to cbmk.
in particular, vendor file insertion is now handled
entirely through the "setvfile" function, instead
of from inject.sh, which seems counterintuitive,
but remember that inject.sh also does MAC addresses.
therefore, the inject.sh script is now primarily for
inserting MAC addresses, and handles vendor downloads
in a slightly more convoluted way, but still easy
enough to understand if you read it a bit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
to the extent feasible, keep lbmk-specific parts on
inject.sh to a minimum. this will later be used to
re-sync cbmk's inject.sh with lbmk's, because cbmk's
one doesn't handle vendor files.
the way this is designed now, with this patch, will
make cherry-picking lbmk to cbmk easier in the future,
when keeping this part of cbmk in sync with lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this matches cbmk, where inject.sh is the file name
this will make future cherry-picks of lbmk->cbmk easier
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk 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 lbmk'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>
the next part checks whether the file is below 512k,
so there's no point checking if it's below 2, because
the lowest a file size can be is zero, and expr will
produce a result of -1 if decrementing from zero.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the combination of x_ with the "e" function enables
for much simpler file-check error handling, which is
a unique innovation of lbmk as it pertains to sh.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it wouldn't exit with error status anyway, since i'm
setting +e here, but if that accidentally changed in
the future, i still wouldn't want this to exit.
the bruteforce me extraction naturally throws a lot of
errors, hence +e, because of how the extraction works,
but the result is checked at the end of the process,
to compensate. hence +e, because otherwise this brute
force extraction would never work.
therefore, this is an extremely theoretical bug fix, the
most quintessential of preemptive bug fixes, to the point
that it is actually rather pedantic.
The ":" in "|| :" will likely *never* be executed, but it
handles the theoretical case where the subshell exits with
non-zero status and +e is set; subshells aren't meant to
behave this way anyway, but who knows what cursed sh
implementation the user is on?
Signed-off-by: Leah Rowe <leah@libreboot.org>
in these if clauses, what follows afterward is exactly
the same: set xchanged and return.
Therefore, these lines are redundant and they can be
removed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This change finally ensures that no insertions will be
attempted, on the basis that readkconfig failed; this
covers the instance whereby vcfg was set, but no scanned
items were indicated e.g. Intel ME files not specified.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This should speed up automated tests. Otherwise, it goes
through all the extra checks that aren't needed, for each
individual type of vendor file, and also errors out when
handling pico serprog images; during automated testing,
on the bin directory, you might try on every tarball, one
of which is the pico tarball and this patch makes lbmk skip
that one too.
In general, we must not perform unnecessary tasks. Doing so
may even cause other bugs that we couldn't easily detect.
Signed-off-by: Leah Rowe <leah@libreboot.org>
x_ cannot be used, where output is redirectod to a file;
only the conventional piping can be used.
same as the last change. this and the other fix were caught
during testing.
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 lbmk runs would
export TMPDIR, it doesn't matter because lbmk 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 lbmk-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 lbmk 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 lbmk.
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>
They may not actually always be binary blobs, at least not
software. I started referring to these as "vendor files" some
time ago, for this reason.
With this terminology, it applies properly to any sort of file
from the vendor. For example, it may be that in the future, we
start inserting the MFS section of an an Intel ME image, into
the Intel ME.
We already do that with deguard for example (set MFS config),
on MEv11 based setup. That is a vendor *file*, and though it
may still actually be a binary blob, it's not software, but
configuration.
The term "blob" normally means compiled software, in most people's
minds, but the term blob is technically accurate for any blob,
not just software; however, we have to keep people's perception
in mind.
Whereas, "vendor file" is also understood by most people to
include code supplied by the vendor.
We haven't done any releases yet with this ROM image file name
prefix, so it's perfectly OK to handle it now, without handling
the old one for backwards compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Users running setmac on an X200 tarball for example, will
now see it being modified, if they didn't specify
setmac keep, so they might think vendor files are being
inserted, which they are not.
Therefore, a confirmation is provided at the end of the output.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe