A bug has been introduced in
a202dce646
("images: remove 'libgfxinit' from the image names.")
where we simplified images names without taking care of renaming the filename
used as the SeaBIOS build target.
This error was visible during the generation of the images:
Creating new ROM image: bin/[...]/seabios_kgpe-d16-[...].rom
payload/seabios/seabios.elf: No such file or directory
E: Could not load file 'payload/seabios/seabios.elf'.
E: Failed while operating on 'COREBOOT' region!
E: The image will be left unmodified.
The resulting image was then missing a payload entry and was then
non-functional (people would then just get a black screen without any OS loaded
from the disk).
GNUtoo confirmed by bisecting that the commit cited above was indeed responsible
of the bug and also that the error message above was specific to this issue.
This commit fixes this bug by setting variables to hold the actual payload
location (making future changes easier), in the relevant files.
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: Added "Created new ROM image" log, made it fit,
improved source code comment.
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit removes the generation of the unused seabios_vgarom.elf image.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: Removed speculations from the commit message
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The GNU Coding Standards has the following in the chapter "4.8.1
--version"[1]:
The program’s name should be a constant string; don’t compute it
from argv[0]. The idea is to state the standard or canonical name
for the program, not its file name. There are other ways to find
out the precise file name where a command is found in PATH.
[1]https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dversion
This fixes that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without this fix we have the following error on Trisquel 11 when
building the GRUB payload:
configure: error: qemu, coreboot and loongson ports need unifont
Trisquel 10 also has an 'unifont' package, and installing it doesn't
break the build of the GRUB payload.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The build system was designed to produce images with different GPU
drivers for a single computer and/or to show the image name in the
final image names, to enable users to know which GPU driver was used.
However since all boards have practically speaking the same GPU driver
('libgfxinit') this adds too much complexity for almost no benefits.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The seabios_grubfirst images provides the same functionality than the
GRUB images, but instead of having GRUB being loaded directly by
Coreboot, Coreboot loads SeaBIOS which then loads GRUB.
These images probably exist to enable end users to try it to workaround
potential compatibility issues between the OS and GRUB with the GRUB
image as we have a BIOS implementation being loaded.
While this looks useful, it also makes things more complicated:
- It increase the number of images to choose from, and it's
complicated to explain the difference between grub and
seabios_grubfirst to end users.
For instance for the "x200_8mb", users need to choose between 2 GPU
modes (corebootfb, or txtmode) and 12 keyboard layouts. So having to
choose between 2 payloads instead of 3 with one difference that is
hard to understand makes things easier.
- It makes testing more complicated as we have one more payload to
test and we also need to make sure to always differenciate both
images in bug reports, documentation, etc.
And if issues arise from this change in the future, we could work with
upstream to fix them and/or replace the grub images with
'seabios_grubfirst' while keeping the 'grub' name to avoid
complicating things by having two main payloads with identical
features.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typos in commit message
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following build error on Trisquel when
qemu-utils is not installed:
successfully built /gnu/store/[...]-gnuboot-trisquel-preseed.img-07-2024.drv
resources/packages/roms/download: line 175: qemu-img: command not found
make: *** [Makefile:713: release] Error 127
An option would be to make sure that the host has qemu_img by adding
its corresponding packages in resources/dependencies/ and to check for
it in configure.ac, but since we already build the qemu with Guix,
it's easier to just reuse that, and this also gives us less
maintenance in the long run.
This was broken by the commit 9cc02ddde1
("packages: roms: Start adding automatic tests.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
We have a test for catching a situation where new files are added in
releases without adding them as well in the ${release_files} variable
to test for their existance.
But this test only warn of the issue instead of failing. And since
people might not inspect all the log details in depth, it's better to
fail instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Before this commit if some files were in the release directory but
missing from ${release_files}, it would show something like that:
[ !! ] release/i945-thinkpads-install/gnuboot_src.tar
The ${release_files} variable is used to test for files missing in the
release directory, and it prints something if a file is missing:
[ !! ] release/roms/gnuboot-0.1-rc3-95-g1783708_d510mo.tar.xz is missing
Since confusion is possible between the two tests (especially if the
people looking at the log don't have all the code and context in mind
when doing that), this commit changes the code to print something like
that instead:
[ !! ] release/i945-thinkpads-install/gnuboot_src.tar missing in ${release_files}
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
This was broken by the commit 7df6d6169b
("Build bucts and patched flashrom for I945 ThinkPads with Guix.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without that fix the build is stuck on the following during days on a
ThinkPad X200 with 8GiB of RAM and an Intel P8600:
building /gnu/store/z7k1rs4j98s5zj0f9xrn1p3k1w1fmgqa-proot-static-5.3.0.drv...
/ 'check' phase
And the Guix manual says the following about -R/-RR:
When this option is passed once, the resulting binaries require
support for “user namespaces” in the kernel Linux; when passed
_twice_(1), relocatable binaries fall to back to other techniques
if user namespaces are unavailable, and essentially work
anywhere—see below for the implications.
So by using -R instead of -RR we don't build proot-static anymore, and
we rely on the fact that most GNU/Linux distribution have namespaces
enabled (else a lot of packages like Guix or container software
would not work on them).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typo in commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
We need to somehow isolate the git configuration being used to build
GNU Boot from the rest of the system as otherwise things like
automatic gpg signatures can kick in and block the build because it
waits for a pinentry.
In addition:
- It enables us to simplify the build code as the git configuration is
now the same during all the build.
- Contributors don't need to setup git anymore just to build GNU
Boot. This also makes GNU Boot a bit more reproductible.
Replacing git inside the build scripts / Makefiles enable us to still
run them manually (like ./resources/packages/coreboot/download).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The resources/packages/roms/boot script already work with the "help"
argument, however most of the other scripts use --help, so for
consistency we need to add --help as well.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The Intel Flash Descriptor files are supposed to be reproducible
already, so it's a good idea to add a test for that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
In GNU Boot, at the time of writing, we want to advise users to use
the GRUB images as they don't require users to modify their
distribtions.
However before the commit aec2e2f2bcf7693a05e416f9722e15b9d1854516
("Fix bug #65663 (No support for LVM2)."), most computers using LVM2
would not boot with these images.
The bug is now fixed by this commit, however since we ship a custom
grub.cfg and that it is very important to get it right, it's a good
idea to have some sort of automated testing for it.
It uses Trisquel (instead of other FSF certified distributions) for
several reasons:
- Trisquel can be used by less technical users, and so it's important
to make sure it works as less technical users tend to have harder
times finding workaround when things break.
- It's probably the GNU/Linux distribution that most current and
potential GNU Boot users use.
- It is also maintained by a community that welcome contributions, so
if we hit some issues, we can also contribute to get it fixed (we
also verified that multiple times by contributing to it).
Note that we also welcome tests that reuse other distributions as
well.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typos in the commit message and fixed copyright notice
Acked-by: Adrien Bourmault <neox@gnu.org>
The xz compression operation can be quite long, so it's a good idea to
show its progression.
To do that we need to produce a tarball file first as xz doesn't have
any idea of the progression when just compressing a piped stream of
data.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without that fix we have the following when running 'make release':
make[1]: Leaving directory '/home/gnutoo/work/projects/gnuboot/gnuboot'
cp: cannot stat 'i945-thinkpads-install-utilities/':
No such file or directory
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The resources/packages/src/release content appeared in osbmk in the
2e2fe863172b513c3bdd4d0497657223ff6abdb4 ("Retroboot beta release,
20201228"). This commit is present in both the master branch and the
libre branch of osbmk.
The libre branch was then used as a basis to the (first) commit
89517ed6b9 ("libreboot!").
Then since GNU Boot kept the history of lbmk, we then have the rest of
the history of that file.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Even if we still don't have any installation instructions that use
these tools, we still need to document somehow what the targets to.
And not adding a help for that would make it inconsistent with the
other targets that are somewhat documented in make help.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Before being merged with the commit
dc6e1f32c1 ("Import website-build to
build the GNU Boot website."), website-build was a separate git
repository.
And so, even after the merge, until the commit
20d122e94a ("website-build: use website
from local git repository."), it still worked in the same way and
still downloaded the website from git.
This prevented merging the website and website-build directories
together as the GNU Boot repository also needed to be a valid Untitled
website repository as well.
Now after this commit, the website is built from the same git tree, so
we can simply adjust the build scripts to be able to move things
around.
In addition of making things more clear for contributors, it also
simplify the migration to haunt as with haunt we typically have the
haunt.cfg (and the autotools build code if needed) code in the top
directory and the markdown files in a subdirectory.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNU Boot can be installed on some I945 ThinkPads without disassembling
them. To do that it requires both a patched flashrom and bucts.
This build them and also integrate Guix in GNU Boot as a dependency to
build them.
This will enable us to later on ship these utilities and then update
the installation instructions to use them somehow.
It also makes sure that we have proper authorship of the patch used
for flashrom and also unify the two flashrom patches not to require
two different flashrom binaries.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
For some reason, 'make release' produces the following files:
- release/roms/gnuboot-lbwww-20211122-328-gafe01fb_default.tar.xz
- release/roms/gnuboot-lbwww-20211122-328-gafe01fb_fam15h_rdimm.tar.xz
- release/roms/gnuboot-lbwww-20211122-328-gafe01fb_fam15h_udimm.tar.xz
This commit works around that issue.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
We also need to check if we have all the files and no superfluous
files inside the released archives.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This has several goals:
- It checks if the test works fine and if someone forgot to add some
files.
- It checks if the build system produces files that it should not
produce due to some bugs.
- It can also check if some leftover files are there from previous
builds. This can help avoiding pushing wrong files as part as a
release.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This makes sure that the release at least has all the expected files.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix building images with make release or './build release
all' results in the following error:
[...]
Built lenovo/t400 (ThinkPad R400)
make[1]: Leaving directory '/home/gnutoo/gnuboot/coreboot/default'
Creating new ROM image: bin/r400_16mb/seabios_withgrub_r400_16mb_libgfxinit_corebootfb_colemak.rom
Usage:
./build <TASK> <PACKAGE>
./build --help
[...]
Refer to the gnuboot documentation for more information.
Error: Invalid task 'descriptors'.
Error: See './build --help'.
Error: build/roms: something went wrong
make: *** [Makefile:47: release] Error 1
This was broken by the commit 857afa42a8
("Switch to packages structure.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Since we use untitled as well it's a good practice to release its
corresponding source code as well to make sure people can rebuild the
website in case upstream disapear.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was broken from the start in the commit
fe28bc3c82 ("dependencies: move into
single package.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was broken by the commit 8f3d30f809
("dependencies: rename debian in pureos-10.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was broken from the start in the commit
fe28bc3c82 ("dependencies: move into
single package.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The "$(dirname $0)"/../dependencies/ directory is the same as
"$(dirname $0)".
So when running the script we have:
# ./resources/packages/dependencies/install
./resources/packages/dependencies/install: 49:
./resources/packages/dependencies/../dependencies/arch: not found
This was broken from the start in the commit
fe28bc3c82 ("dependencies: move into
single package.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, running ./resources/packages/dependencies/install
prints the help and does not do any dependency installation.
This was broken from the start in the commit
fe28bc3c82 ("dependencies: move into
single package.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The 'make release' or './build release all' commands build releases of
GNU Boot that consist of installable images and the upstream source
code used to build them.
The u-boot-libre package is instead meant to follow different release
schedules as it releases deblobbed versions of various u-boot releases
for reuse by distributions like Parabola.
Before the commit 857afa42a8 ("Switch to
packages structure.") users were expected to run the release script of
u-boot-libre separately but after it it ended up being run
automatically as part of 'make release' or ./build release all.
Renaming this script ensure that it's not run during regular releases.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following issue on PureOS byzantium:
$ resources/packages/coreboot/distclean
resources/packages/coreboot/distclean: 19:
resources/packages/coreboot/../../scripts/tasks/distclean.sh:
Bad substitution
resources/packages/coreboot/distclean: 20: .:
cannot open /../../..//resources/scripts/misc/sysexits.sh:
No such file
This happens because packages/coreboot/distclean uses #!/bin/sh and
that the default sh shell isn't using bash:
$ readlink $(which sh)
dash
and using bash instead works fine:
$ bash resources/packages/coreboot/distclean ; echo $?
0
all the other distclean scripts in packages/*/ have exactly the same
issue. The tests/distlean script is also affected since it also
sources the distclean task.
So we use #!/usr/bin/env bash as it work with both Guix and regular
more or less FHS compliant distributions.
This issue was introduced by the commit
c7e28dc660 ("packages: Add distclean").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
We can't require contributors to install Ubuntu as it has freedom
issues[1] but for contributors, installing Trisquel is easier since
it's at least FSDG compliant[2]. So it makes sense to show that
Trisquel is the primary target here.
This is also reflected in the reality as the current GNU Boot
maintainers already installed Trisquel 10 inside virtual machines
and/or containers to test this script.
[1]https://www.gnu.org/distros/common-distros.html#Ubuntu
[2]https://www.gnu.org/distros/free-distros.html
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This can simplify the overal structure of GNU Boot as we don't need to
compute some git tag everytime in the code.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
It is possible to install GNU Boot on I945 Thinkpads without opening
the computer even if the nonfree bios sets the bootblock region (the
last 64K of the flash chip) read-only.
The flash chip looks like that:
+----- -----+---------------------------+-------------------------+
| ... | Secondary bootblock (64k) | Primary bootblock (64k) |
+----- -----+---------------------------+-------------------------+
0 0x1e0000 2MiB
To bypass the read-only restriction we use an utility (bucts) that
tells the hardware to swap the primary bootblock with the secondary
one for the next boot. We then have to disable that swap and reflash
again.
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK generates the two bootblocks
directly in coreboot so we don't need to use special commands to do
that anymore.
In addition the MacBook 1.1 and 2.1 are known not to have such
read-only restrictions so they don't need to have
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK enabled.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The various scripts present in GNU Boot are very fragile, so it's a
good idea to have a pristine GNU Boot source code for making releases.
The issue is that 'git clean -dfx' doesn't remove existing git
repositories like coreboot/ grub/ etc, so we need additional code to
take care of that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This should contain no functional modifications.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
neox: wrote the commit message
Having an {arch,debian,fedora35,ubuntu2004,void} GNU Boot package
looked strange. Having a dependencies package instead makes more
sense.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The various build scripts are scattered around in multiple
places. This make it hard for contributors to understand what they
need to modify.
Most GNU Boot users are interested in running GNU/Linux or BSD
operating systems. And the way to install software on these
operating systems is through a package manager. So most users and
contributors already know the package manager abstraction.
So using that abstraction makes it easier to find where things are.
The scripts to install dependencies don't really fit the new structure
but for now we move them in to make sure that everything works
fine. This could be fixed later on and migrated to a single
dependencies packages by auto-detecting the distribution with
/etc/os-release.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
