if the user ran this on an x60 tarball, the no-gbe
warning seems confusing since that one has intel gbe,
but pre-ifd, so no gbe region in the flash; on pre-ifd
systems e.g. ich7 southbridge, the mac address was baked
into a separate gbe nvm on mask rom, inaccessible to users
Signed-off-by: Leah Rowe <leah@libreboot.org>
We already have code to handle this, but it's possible
that I might break it in the future, due to the complex
logic of this script.
So, I've implemented this catch-all check at the end of
the process. It still relies on the actual setting of
the variables, upon which this check is based, to be set
correctly.
This condition will most certainly never be met, unless
I break some other part of the code in the future. That
is precisely what this overly pedantic check is for.
Example scenarios:
I forget to set xchanged=y, on a new modification.
I set has_hashes erroneously.
The variables are re-used between runs, and not properly
reset; at present, a given run of ./mk inject only
operates on a single target, but this latter fact could
change in the future.
need_files is set erroneously; vendorfiles detected as
being required, when they aren't.
These are just a few examples. As such, this is a preventative
bug fix, because it's preventing a bug.
The main reason I want this i n here is because I need to ensure
that vendor files are properly deleted, for a given release.
If I accidentally includes ones that I'm not supposed to,
inside ROM images, that could be a big problem.
Signed-off-by: Leah Rowe <leah@libreboot.org>
where the nuke command is used, we need the files to be
there; if they're not, it will try to nuke them, which will result
in an error in most cases, but there may be some cases where that
isn't true, for instance if only the Intel ME is needed; it'll be
writing zeroes over zeroes.
we want to only allow technically correct behaviour, because
technically correct is the best kind of correct.
it is theoretically possible that a double-nuke might affect
certain behaviours unpredictably. for example, if vendor.sh
later integrates another tool that works whereby the same command
inserts or nukes depending on a certain condition, but with the
same command, and where that command would return zero in both
cases.
this is a preventative bug fix, because it fixes an issue that
does not yet actually occur in practise.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the user must be well-informed as to the next step, which
this script directly influences
guide the user accordingly
Signed-off-by: Leah Rowe <leah@libreboot.org>
The message at the end that states a file was
not modified, is not currently printed when vendor
files are not needed, and setmac is not used.
This patch fixes that, so the user now sees a
confirmation of such change, or lack thereof.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is because the user may have specified setmac.
I tried without this change, on a fresh lbmk, setting
the MAC address on an X200 tarball, and it produced an
error that ifdtool was unavailable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Observe the following prior patch:
commit 818f3d630c
Author: Leah Rowe <leah@libreboot.org>
Date: Fri Jan 3 17:06:14 2025 +0000
vendor.sh: Don't error if vcfg is unset
Now:
This patch made vendor inject more robust, and speeds
up the processing of images where no vendor files are
needed, but it broke setmac on such tar archives.
This new patch works around it. For example, I was
able to run ./mk inject on an X200 tarball to change
the MAC address; no vendorfiles are inserted, because
it's not needed.
The further check for whether a board uses Intel GbE
still protects against accidental modification.
Signed-off-by: Leah Rowe <leah@libreboot.org>
probably not actually needed, but it annoys me that it doesn't
come installed by default, and it's needed for certain git
operations
Signed-off-by: Leah Rowe <leah@libreboot.org>
It should return 1 instead, in readcfg(), because this
is not an error condition; vcfg not being set means
that the board doesn't use vendor files, which is
perfectly normal and should not yield an error.
This fixes a build error under certain conditions,
found during release-build testing.
This bug was exposed when I fixed double quoting issues
as per shellcheck tests.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it should fix more build errors that might have appeared
in the aforementioned revision, mentioned in the previous
commit message
Signed-off-by: Leah Rowe <leah@libreboot.org>
the bug was actually caused by chkvars
add an escape for the quotes and bam. fixed.
without this, i got the following e.g.
For command: ./mk dependencies debian
Output:
./mk: 1: [: apt-get: unexpected operator
ERROR ./mk: pkg_add unset
Someone reported a similar issue with the Arch one,
which is also now fixed. This regression was caused
by the previous commit:
commit 0cf58c2273
Author: Leah Rowe <leah@libreboot.org>
Date: Thu Jan 2 23:52:45 2025 +0000
fix lbmk shellcheck errors
I forgot to escape the double quotes in an eval.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This check is a good idea, but not viable here,
because the modules naturally aren't set in all
circumstances, so it just causes a build error.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the gnu.org mirror is always slow for some reason, but only
for gnulib. it may only be for me, because routing in other
countries/networks may differ.
when i'm freshly cloning lbmk modules, gnulib is always really
slow, like 300KB/s (bytes, not bits)
i have 1gbps internet and wish to not have 2005-era speeds,
thank you kindly!
Signed-off-by: Leah Rowe <leah@libreboot.org>
Mention Riku's copyright in the COPYING file, and update
my years in that file. Add Riku to the AUTHORS file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The user might wish to uninstall, but not remove the
build that they just did.
The user can still do make clean if they wish.
Signed-off-by: Leah Rowe <leah@libreboot.org>
DESTDIR is the root directory where it goes, which
is normally an empty string; PREFIX is where the
bin directory is located, relative to DESTDIR
Default to /usr/local for PREFIX, not /usr, because
/usr/bin is for system utilities.
nvmutil is a local utility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We don't want to clobber anything that the user set themselves.
Instead, we should respect the user's choice.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This makes the code easier to understand.
All 2-byte words, stored in little endian order within
the 128-byte GbE NVM area, must add up to 0xBABA.
If it doesn't, then software is supposed to reject that
GbE config. The nvmutil software works on that basis.
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it look like hexdump -C, where individual bytes are
spaced, and there is an additional space after 8 bytes,
per row.
i won't bother with a character display, since that is
meaningless on gbe nvm words.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i also removed that printf, because the path it prints is
actually wrong sometimes; in the recent re-write of vendor.sh,
it prints the correct path instead
Signed-off-by: Leah Rowe <leah@libreboot.org>
There was also a condition in run_make_command that is now
an OR, where it was an AND, on script/trees, to fix the use
of mixed (and erroneous) OR/AND operators.
I'm planning a much more invasive audit than this. These are
light fixes, intended for Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Must not exceed 79 lines. Some variables and functions have
been renamed, and there has been some minor re-factoring.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I don't like using SPDX for actual copyright declarations.
I only want it to be used for the license identifier.
Also:
I made a *single* change to nvmutil.c in 2024, which means
that I have copyright in all years since and including 2022;
the file said 2022, 2023, 2025, but it's actually 2022-2025.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I believed that the compressed nature of refcode was the only
non-reproducible thing, but turns out you also need to run
rmodtool on the refcode to make the binary relocatable in
cbfs. This is based on my reading of the coreboot Makefile.
With this change, I can now provide release binaries for
the HP EliteBook 820 G2.
Signed-off-by: Leah Rowe <leah@libreboot.org>
dnf reinstall package
or
dnf install package
for reinstall, do this:
./mk dependencies fedora41 re
this is an example command
the 4th argument prefixes "install" in dnf install
a bit hacky but it should work
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe