summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
20 hourslib.sh mktarball: stricter tar error handlingHEADmasterLeah Rowe
There was no error handling, *at all*, on the actual tar command, due to the lack of set -o pipefail, which we cannot rely on in sh. The x_ wrapper can be used in this case, as a mitigation. Signed-off-by: Leah Rowe <leah@libreboot.org>
3 daysvendor.sh: don't err on bruteforce me extractLeah Rowe
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>
3 daysvendor.sh: remove unnecessary xchanged="y"Leah Rowe
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>
3 daysvendor.sh: set need_files="n" if skipping patchLeah Rowe
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>
3 daysvendor.sh: Don't handle vendor files if not neededLeah Rowe
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>
4 daysRevert "lib.sh: use eval for the command in x_"Leah Rowe
This reverts commit 3bfdecdc75bbc77f795736ac282f858f2eb7ab94. The commit that this reverses, caused sch5545 ec firmware downloads to fail, due to globbing.
4 dayslib.sh: fix bad eval writing resized fileLeah Rowe
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>
4 dayslib.sh: fix bad eval writing version/versiondateLeah Rowe
x_ cannot be used, where output is redirected to a file; only the convention piping can be used, for errors. relying on x_ in these cases will cause unpredictable bugs. Signed-off-by: Leah Rowe <leah@libreboot.org>
4 dayslib.sh: use eval for the command in x_Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 dayslib.sh: tidy up the error handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysrom.sh: tidy up error handlingLeah Rowe
same as the last change Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up error handlingLeah Rowe
x_ can be used nowadays on any function, because it properly handles globbing. Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up decat_fspfd()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysgit.sh: clean up fetch_project()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: properly call err_ in fail_injectLeah Rowe
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>
4 daysremove xbmk_parent, handle forking in lib.shLeah Rowe
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>
4 dayslib.sh: define x_ right after err_Leah Rowe
because the top-down function order isn't as reliable in lib.sh, since this is what first runs, included in every other script Signed-off-by: Leah Rowe <leah@libreboot.org>
4 dayslib.sh: minor cleanupLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysmrc.sh: minor cleanupLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysrom.sh: minor cleanupLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up check_release()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up vendor_inject()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up readcfg()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up patch_release_roms()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up process_release_roms()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up patch_rom()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up inject()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 daysvendor.sh: tidy up modify_mac_addresses()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
4 dayslib.sh: write version/versiondate to dotfilesLeah Rowe
write to .version and .versiondate, instead of version and versiondate. this will hide them to avoid visual clutter while analysing files within lbmk. Signed-off-by: Leah Rowe <leah@libreboot.org>
4 dayslib.sh: hardcode projectname/projectsiteLeah Rowe
remove the corresponding files, containing these strings Signed-off-by: Leah Rowe <leah@libreboot.org>
5 daysvendor.sh: simplified readkconfig()Leah Rowe
So much bloat Signed-off-by: Leah Rowe <leah@libreboot.org>
5 dayslib.sh: double-quote pwd to prevent globbingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
5 dayslbmk: unified PWD handling (work directory)Leah Rowe
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>
5 dayslib.sh: initialise PATH if it's unsetLeah Rowe
it's incorrect for PATH not to be set, but some users may foolishly blank it out before running lbmk. prevent such issues, by initialising it. Signed-off-by: Leah Rowe <leah@libreboot.org>
5 daysmove XBMKPATH to include/lib.shLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
5 dayslbmk: use pwd util, not PWD environmental variableLeah Rowe
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>
5 daysclean up a few semicolons in the build systemLeah Rowe
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>
10 dayslbmk: minor code formatting cleanupLeah Rowe
some lines were needlessly condensed, and less readable Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-27vendor.sh: don't error if grep -v failsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-27vendor.sh: Don't show gbe filename on injectLeah Rowe
it's a temporary file, so printing it may confuse the user. hide it from the output. Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-06rom.sh: don't run mkpicotool on dry buildsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-06pico-sdk: Import picotool as a dependencyLeah Rowe
We were previously not handling picotool at all, and pico-sdk would download picotool itself, at build time. This means that the source archive, if created, would not contain picotool. While not strictly required, for complete corresponding source, since it's a toolchain and not the actual pico-serprog firmware, it is my policy that releases must include full corresponding source code, when it is feasible to do so. I must say, I intensely dislike cmake, with such burning passion; I am thoroughly displeased by how hacky this is, but it works and now nothing is in my way for a Libreboot 20241206 rev8 release! Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-06lib.sh: Much safer python version checkLeah Rowe
See: https://docs.python.org/3/library/sys.html#sys.version_info The sys.version_info tuple is a more reliable way to get the version. Our previous logic assumed that Python would always output "Python versionnumber", but this may not always be how it works. We've seen this for example where Debian modifies some GNU toolchains to include Debian something in the output. Python has a standard method built in for outputting exact the information we need. In my system, what I got was this: (3, 11, 2, 'final', 0) That output was from running this command: python -c 'import sys; print(sys.version_info[:])' This is much more robust, so use this instead. Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-05set up python in PATH, ensuring that it is python3Leah Rowe
we already check the python version, and set a variable for it, so that we can reliably use python3, even if python in PATH doesn't correspond to python3. for example if a system has python as python2 and python3 as python3 well, we use that when running deguard for example, but various upstream projects that we use may need python, and all of them use python3, not 2 so, re-use the python variable set up by lbmk, and set it up in PATH accordingly. this now makes the note about python3 obsolete, on docs/build.md in lbwww.git Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-05vendor.sh: Proper semantics on prefix file namesLeah Rowe
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>
2025-01-05vendor.sh: Confirm if need_files=nLeah Rowe
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>
2025-01-05vendor.sh: Allow restoring the default GbE fileLeah Rowe
./mk inject libreboot-YYYYMMDD_board.tar.xz setmac restore This does the same thing as a normal setmac command, except that it does not alter the MAC address; it is also not the same as "keep", which skips *writing* the GbE region in-ROM. The *restore* argument writes the default, unmodified GbE file kept by lbmk, unmodified because nvmutil is skipped when the user specifies this argument. This option is useful for debugging purposes, because it can be used to verify whether anything else is being wrongly modified by the script; the "nuke" command can be executed afterward, and the hash file inspected versus release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-05vendor.sh: set random MAC address *by default*Leah Rowe
MAC addresses are generic, inside Libreboot images where an Intel GbE region is specified. We commonly get users flashing multiple systems for their own use, and sometimes they complain that they networking broke, because they don't know that the MAC address is identical on each machine. This still doesn't work around the case where the same machine is used, e.g. multiple T440p thinkpads, but if they have one of each model, it can work nicely, because we do in fact change it for various platforms. This change will also reduce the number of people at conferences in the future, where there are multiple Libreboot users, having MAC address conflicts. Changing the MAC address is a good practise, so we enforce good practise. The user can still retain the old behaviour by using this command: ./mk inject libreboot-YYYYMMDD_boardname.tar.xz setmac keep The "keep" argument clears new_mac, which will then skip changing the MAC address. They can also still set an arbitrary MAC address as an argument for setmac, e.g.: ./mk inject libreboot-YYYYMMDD_boardname.tar.xz setmac 00:de:ad:c0:ff:ee This change will be covered in the documentation. Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-05vendor.sh: add clarification to nogbe warningLeah Rowe
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>
2025-01-04vendor.sh: check that the vcfg file existsLeah Rowe
setcfg already checks it, but it's good to check anyway Signed-off-by: Leah Rowe <leah@libreboot.org>