When using ./configure --disable-guix, and a recent distribution (like
Parabola and Guix but not Trisquel 11 (aramo)), we can see cells
spanning multiple columns.
Once the website is built (with make build), we can easily test for
that with grep:
$ grep colspan ./untitled/www/lbwww/site/status.html
<td colspan="4">Can’t install due to missing images</td>
<td colspan="4">Fail: #66487</td>
<td colspan="4">Untested | Untested | Untested | Untested</td>
<td colspan="4">Can’t install due to missing images</td>
<td colspan="4">Fail: #66463, #66487</td>
<td colspan="4">Untested | Untested | Fail: #66487 | Fail: #66487</td>
<td colspan="3">Can’t install due to missing images</td>
<td colspan="3">Can’t install due to missing images</td>
<td colspan="3">Can’t install due to missing images</td>
But with ./configure without --disable-guix, we don't see any columns
spanning since the commit 338154a654
("website: Makefile.am: use common guix shell command.").
If we build the website at this commit (without --disable-guix) we see
that the '--commit=' argument is bogus in the command being used:
guix time-machine --commit= -- shell --system=i686-linux
--container --network --emulate-fhs --share=`realpath ../` bash
coreutils findutils git grep nss-certs pandoc sed -- ./build.sh
And we then ends up with this message:
guix time-machine: error: Git error: unable to parse OID - too short
This was then repaired in the commit
2e3818668d ("website: use Guix
v1.4.0."), but we then end up without 'colspan' because we ended up
using older software that don't support this feature.
There are two reasons for not relying yet on this feature:
- We want to use Guix v1.4.0.
- We build a tarball of the website is also part of the release, and
guix is not used during the build. And we need all distributions to
produce at the very least a functionally equivalent output.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was present from the start in the commit
540bcca0fb ("website: status: Add GNU
Boot 0.1 RC5.").
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
9cc02ddde1 ("packages: roms: Start
adding automatic tests.").
I vaguely remember having made the original tests with Trisquel 10,
and if we select LVM in Trisquel 10 both in the graphical and
netinstall installers, it ends up creating a BIOS boot partition (code
ef02), an UEFI partition (code ef00) in the case of the graphical
installer, and an LVM physical volume. I then migrated the automatic
test to Trisquel 11 before sending the patch.
But with the commit 9cc02ddde1
("packages: roms: Start adding automatic tests."), we end up with a
rootfs that has a /boot partition, so GRUB will find that and use it
to boot, without testing if GRUB can find the grub.cfg inside the LVM
partition.
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
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 already have a 'rootfs.img' argument but it is not documented in
the help.
This was broken from the start in 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>
If we do 'ls' in grub, the LVM volumes looks like that: '(lvm/[...])'
and while in certain conditions, the parenthesis are not necessary, in
the case of the code that does the regexp, it is required.
I vaguely remember having made the original tests with Trisquel 10,
and if we select LVM in Trisquel 10 both in the graphical and
netinstall installers, it ends up creating a BIOS boot partition (code
ef02), an UEFI partition (code ef00) in the case of the graphical
installer, and an LVM physical volume. I then migrated the automatic
test to Trisquel 11 before sending it.
But with the Trisquel 11 automatic test, we end up with a boot
partition, so the test will always succeed regardless of weather or
not GRUB is capable of booting from LVM partitions.
This was also tested on real hardware with Trisquel 10 installed with
the graphical installer.
The most likely explanation is that the GRUB config file being tested
also differed from the one in git, especially because both the
automatic tests and the manual tests were tested with both a
non-working GRUB configuration and a working one.
In addition using the new configuration file on a computer that was
using an old Libreboot version probably from around 2016 was made to
boot again using this new configuration file, and this looks even
more strange.
A possible explanation could be that the GRUB version is different,
though the given computer is not available for further testing, so
it's not possible to confirm that hypothesis.
Reported-by: Adrien Bourmault <neox@gnu.org>
neox: private bug report and the information on how to fix it.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was not caught because the dev variable is used earlier and so it
produces no error.
In addition the commit 860b00bf1e
("ressources/grub, website: add LVM2 support (fix bug #65663 "No
support for LVM2").") where this issue was introduced was not tested
with LVM partitions that are encrypted.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
While the grub configuration file format is very different from real
shell scripts, the similarities are enough to make it pass shellcheck
with very few adjustements.
The advantage of using shellcheck here is that we can still detect
some issues such as variables that are referenced but not assigned.
For instance if we add 'echo "$test"' in the beginning of the
configuration file we then have:
In resources/grub/config/grub.cfg line 24:
echo "$test"
^---^ SC2154 (warning): test is referenced but not assigned
(for output from commands, use "$(test ...)" ).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This adds information about the merge of the website-build history
inside the GNU Boot main repository.
This doesn't have details of where website-build was before being
integrated in Genuine Libreboot, but since the history is preserved in
git and that we don't track much the rename of projects yet (like the
rename of retroboot to osboot), it's about the same level of details
than the rest.
In addition, website-build was most likely somewhere on
https://git.sr.ht/~gnutoo but I don't recall the exact repository
names or the exact moves between Genuine Libreboot, GNU Boot, and
repositories in https://git.sr.ht/~gnutoo, but this level of detail is
not very relevant, especially because I use my own repositories to
work on things before sending them to upstream projects, and so only
keeping the official projects makes more sense as it simplifies the
history.
The https://git.sr.ht/~libreboot/lbwww-build path was confirmed with
https://archive.org/web.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The grub_x200_8mb_corebootfb_frazerty.rom was tested on a ThinkPad
X200. The computer booted fine.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
We ship images for computers like the Gigabyte D945GCLF2D which are
not working. All the SeaBIOS images are also not working in the GNU
Boot 0.1 RC4. And many of the images were never tested.
In the 0.1 RC4 the images were removed from the FTP as keeping them
would increase too much the risk of users breaking their computer.
However to make the removal of images really work, the people
responsible for the release would then need to test all the images
themselves to be really sure that things are working, or to somehow
build a procedure where some users privately get the images before the
release.
This doesn't work because it would put too much burden on the actual
maintainers: it would require too much time for testing all the images
and this is not automated. In additions the current maintainers don't
even have all the supported computers and the GNU Boot project relies
on all users that can test to test the images.
In addition, releasing the images as part of the release procedure is
easier for everybody: the testers can also get the full source code
easily, they don't need to use custom images, anyone can test, etc.
Because of that it was decided that it was better to teach users to
minimize the risk themselves by looking at the status before upgrading
GNU Boot.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Before we had columns for installation and upgrade. These got replaced
to add the 4 image types as space was missing for all of them: it
would have made the markdown lines over 80 characters and it may also
create tables whose width is too big to be readable.
The installation and upgrade instructions were not added in an
additional table because:
- so far nobody tested trying to find instructions on the GNU Boot
website to install GNU Boot,
- we plan to (re)write install and upgrade instructions to make them
easier to use than what is currently scattered around the website.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit adds a debugging configuration file for the t400_8mb image,
enabling building debugging images with UART console support and RAM
initialization debugging messages, for both corebootfb and txtmode displays.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit adds a debugging configuration file for the x200_8mb image,
enabling building debugging images with UART console support and RAM
initialization debugging messages, for both corebootfb and txtmode displays.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit adds a debugging configuration file for the D16 RDIMM 16MB image,
enabling building debugging images with UART console support and RAM
initialization debugging messages.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit includes debugging images (with UART console) from bin-dbg in the
release, for instance in the roms-dbg directory. Tar files contain the string
"debug" to avoid people installing a debug image by accident, which can be a
problem as it can cause longer boot times. We also include a README explaining
what are the debugging settings.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: created the README
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
When a computer does not boot at all or the result is only a deep black screen,
a very useful option can be to use a serial connector to get UART debug console
and read it, looking for any useful hint. However, enabling UART debug console
with a sufficient level of details slows down the boot process in most cases.
This commit adds the capability to build debug images, using a special
configuration file for coreboot with debug options. This is a simplistic way
that works for now, but should be improved later on.
These debug images will be generated in the bin-dbg/ directory instead
of bin/ where regular images are located.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Denis 'GNUtoo' Carikli substancially modified this file at least with the
commits:
a202dce646 (images: remove 'libgfxinit' from the image names)
80f75a334f (rename seabios_withgrub images to seabios)
6fa9af30ad (Remove images with the seabios_grubfirst main payload)
5b9dd7adba (packages: fix calls to build descriptors)
585f4d359a (coreboot/i945 Thinkpads: replace dd commands with INTEL_ADD_TOP_SWAP_BOOTBLOCK)
This commit thus adds GNUtoo's copyright notice.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Denis 'GNUtoo' Carikli substancially modified this file at least with the
commits:
f0959c9283 (packages: roms, src: release: xz: show progress)
fd9986da0b (Move releases from releases/<git describe> to releases)
This commit thus adds GNUtoo's copyright notice.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The list of files retrieved by producing files with 'cbfstool
<path/to/image> print' and greping inside that. The image files for
that were the ones generated by the official build of GNU Boot 0.1
RC4.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Before resources/packages/roms/release contained a mix of spaces and
tabs. This unify to spaces as there are less tabs than spaces.
This should contain no code changes.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This test is an easy way to make sure that at least QEMU's SeaBIOS
images work fine.
When designing the GRUB test my intent was mostly to test the grub.cfg
file and also enable further automatic testing to help catch issues
when improving the GRUB configuration.
However since the build system inherited from Libreboot 20220710 is
extremely fragile, and that GNU Boot also starts having the
infrastructure to build on more and more distributions with different
compiler versions (we now supports 2 Trisquel version and 1 PureOS
version), with setups variations (work is ongoing to add support for
building in chroots), it might be a good thing to check if SeaBIOS
works.
This would also catch bugs like bug #66487 ("RC4: All SeaBIOS images
are broken") [1] where the SeaBIOS payload was missing in all images,
however it would not catch situations where SeaBIOS is present in QEMU
images but missing in other images, so different tests must be done
for that situation. In addition it would be costly just to boot a VM
to check for missing files.
[1] https://savannah.gnu.org/bugs/?66487
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 when building a release:
makeinfo \
--pdf \
--no-split \
-o pages/manual/gnuboot.pdf \
../manual/gnuboot.texi
This is pdfTeX, Version 3.141592653-2.6-1.40.22 [...]
[...]
Writing index file gnuboot.cp
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1
./../manual/gnuboot.texi:122: epsf.tex not found, images will be ignored.
@image ...f.tex not found, images will be ignored}
[...]
./../manual/gnuboot.texi:122: Emergency stop.
@image ...f.tex not found, images will be ignored}
@global @warnednoepsftrue ...
l.122 mainboard.}
./../manual/gnuboot.texi:122: ==> Fatal error occurred, no output PDF file pro
duced!
[...]
./../manual/gnuboot.texi:122: ==> Fatal error occurred, no output PDF file pro
duced!
Transcript written on gnuboot.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make: *** [Makefile:767: pages/manual/gnuboot.pdf] Error 1
The epsf.tex can be found in the texlive-plain-generic package in
/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex.
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
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 when building a release:
ROM image release archives available at release/roms/
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for awk... awk
[...]
checking for tex... no
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following issue when building a release:
ROM image release archives available at release/roms/
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for awk... awk
[...]
checking for makeinfo... no
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following issue when building a release:
ROM image release archives available at release/roms/
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for awk... awk
[...]
checking for gm... no
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The goal is to minimize the difference with the
resources/dependencies/trisquel script.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This makes sure that there is only one apt command that is called.
Since this change results in the some package names (like 'git') being
passed twice to apt install, this situation was tested with 'apt
install sl sl' on Trisquel 10 (nabia), Trisquel 11 (aramo) and also
PureOS 10 (byzantium) in case the trisquel and pureos dependencies are
merged later on, and it worked fine.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This package is unused since the commit
e50f311c45 ("dependencies: pureos: go
back to apt (instead of packagekit).").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This package is unused since the commit
3f85c3ff22 ("dependencies: trisquel: go
back to apt (instead of packagekit).").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The history if the pureos-10 file is shared with the one of the
trisquel-10 file until the ubuntu2004 file was forked into the debian
file in the commit 8a79f7b163 ("Fix
https://notabug.org/libreboot/lbmk/issues/59").
Because of that, like the trisquel file, the pureos-10 file was first
introduced by Leah Rowe in 2014 as it cannot be found in 2013
Libreboot tarball releases (20131212, 20131213, 20131214) but it is
found in 20140711.
We then have the complete history through the
obsolete-repository-preserved-for-historical-purposes, osbmk and GNU
Boot repositories.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed own email address
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
