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>
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>
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>
Currently GNU Boot has no manual, and it needs one to organize better
the information it provides to users and/or contributors.
Since we need to start somewhere, beside adding the manual license, we
describe a bit what the GNU Boot project is, and also ask for help for
completing the manual.
The GFDL 1.3 comes from the gnulib source code at the commit
d64d66cc4897d605f543257dcd038524a0a55215 ("autoupdate").
The beginning and the end of the document are also very similar to the
GNU Hello manual from the commit
24225d705684322f482135e8a2d679485fce0811 ("maint: remove the obsolete
gettext module") as they were copied and modified from that.
The 'dircategory Kernel' was chosen to be the same than GRUB, so they
both appear in the same group in the Emacs info reader ('info'
command in Emacs).
As for the "Overview" of GNU Boot it also contains background
information that will be needed later on and that needs to be
introduced right from the start:
- If people reading the manual do not understand what a boot software
is, all the rest will be too complicated to explain.
- We also need to explain where GNU Boot is physically located on the
computer from the start as we plan not to use the 'ROM' terminology
as it's confusing: ROM means read-only-memory, and so there is no
point of providing GNU Boot ROM images if the nonfree boot software
can't be replaced.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
In the commit 0f74569af0 ("dependencies:
switch arch, debian, fedora35, ubuntu2004 to packagekit"), the
Trisquel script was converted to use packagekit to then be able to
unify the dependency management between several distributions.
However GNU Boot doesn't build directly on Parabola, and the build is
completely untested on Fedora and Void, so the other scripts are less
important. In contrast building GNU Boot is regularely tested on
PureOS 10 (byzantium) and Trisquel 11 (aramo).
Since the Guix debootstrap package can be used to safely create
chroots of PureOS and Trisquel, it may be possible to use that to
build GNU Boot on any distributions.
However packagekit requires a daemon to work:
# pkcon install guix
Failed to contact PackageKit: Could not connect:
No such file or directory
And in turn the /usr/libexec/packagekitd daemon requires dbus as shown
by the /lib/systemd/system/packagekit.service file:
[Unit]
Description=PackageKit Daemon
# PK doesn't know how to do anything on ostree-managed systems;
# currently the design is to have dedicated daemons like
# eos-updater and rpm-ostree, and gnome-software talks to those.
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target
[Service]
Type=dbus
BusName=org.freedesktop.PackageKit
User=root
ExecStart=/usr/libexec/packagekitd
So reverting back to apt seems a safe choice for now.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In the commit 0f74569af0 ("dependencies:
switch arch, debian, fedora35, ubuntu2004 to packagekit"), the
Trisquel script was converted to use packagekit to then be able to
unify the dependency management between several distributions.
However GNU Boot doesn't build directly on Parabola, and the build is
completely untested on Fedora and Void, so the other scripts are less
important. In contrast building GNU Boot is regularely tested on
PureOS 10 (byzantium) and Trisquel 11 (aramo).
Since the Guix debootstrap package can be used to safely create
chroots of PureOS and Trisquel, it may be possible to use that to
build GNU Boot on any distributions.
However packagekit requires a daemon to work:
# pkcon install guix
Failed to contact PackageKit: Could not connect:
No such file or directory
And in turn the /usr/libexec/packagekitd daemon requires dbus as shown
by the /lib/systemd/system/packagekit.service file:
[Unit]
Description=PackageKit Daemon
# PK doesn't know how to do anything on ostree-managed systems;
# currently the design is to have dedicated daemons like
# eos-updater and rpm-ostree, and gnome-software talks to those.
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target
[Service]
Type=dbus
BusName=org.freedesktop.PackageKit
User=root
ExecStart=/usr/libexec/packagekitd
So reverting back to apt seems a safe choice for now.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'sudo resources/dependencies/pureos-10' results in
the following issue:
Finished [=========================]
Command failed: Expected package name, actually got file.
Try using 'pkcon install-local libtool' instead.
And with this patch the command above works fine:
Finished [=========================]
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following build error on PureOS 10
(byzantium):
Submodule path 'util/nvidia/cbootimage': checked out
'65a6d94dd5f442578551e0a81ecbe5235e673fd4'
Committer identity unknown
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got '[...]')
ERROR: download/coreboot: Unable to apply patch
'../../resources/coreboot/default/patches/0001-apple-macbook21-Set-default-VRAM-to-64MiB-instead-of.patch'
for board 'default' on tree 'default'Committer identity unknown
This is because PureOS 10 (byzantium) has git 2.30.2 and in PureOS,
and since 'man git' doesn't show GIT_CONFIG_GLOBAL nor
GIT_CONFIG_SYSTEM, git 2.30.2 doesn't understand these variables.
Since git already has -c option, we use that instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'make release' fails with the following error:
[...]
ROM image release archives available at release/roms/
set -o pipefail ; ./build release website | tee -a make-1732208182.log
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
[...]
checking for dot... no
configure: error: dot was not found in PATH ([...])
make: *** [Makefile:710: release] Error 1
This happens because during releases we also ship a tarball of the
website, and the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.")
started using dot without also adding the graphviz dependency in the
dependencies for building releases.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'make release' fails with the following error:
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 dot... no
This happens because during releases we also ship a tarball of the
website, and the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.")
started using dot without also adding the graphviz dependency in the
dependencies for building releases.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, Trisquel fails with the following error:
Resolving [=========================]
Package not found: ttf-unifont
Command failed: This tool could not find any available package:
No packages were found
And when installing ttf-uifont with apt, we get this error:
# apt install ttf-unifont
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package ttf-unifont is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
fonts-unifont
E: Package 'ttf-unifont' has no installation candidate
The ttf-unifont dependency was introduced in Libreboot when it didn't
use git yet. It can be found in Libreboot's 5th release, second
revision[1] in libreboot_src/builddeb.
[1]https://rsync.libreboot.org/oldstable/20140622/libreboot_src.tar.gz
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix running the script results in the following error:
# ./resources/dependencies/trisquel
+ ./resources/dependencies/trisquel
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
packagekit-tools is already the newest version (1.2.5-2ubuntu2+11.0trisquel1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
awk: cmd. line:1: {print
awk: cmd. line:1: ^ unexpected newline or end of string
The issue was introduced in the commit
94118b896a ("dependencies: Trisquel 10:
Fix script for non-english locales.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
While the FAM12H SMU firmware is under a free license, as the
F12NbSmuFirmware.h contains the following copyright header:
* Copyright (c) 2011, Advanced Micro Devices, Inc.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of Advanced Micro Devices, Inc. nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
we also lack the corresponding source code.
Since AMD Family 12H was removed upstream, and that GNU Boot doesn't
support any computers with this CPU family, it's easier to remove the
file than to try to fix the issue in some other way.
Reported-by: Leah Rowe <info@minifree.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The file contains the following copyright header:
// This file contains an 'Intel Peripheral Driver' and is
// licensed for Intel CPUs and chipsets under the terms of your
// license agreement with Intel or your vendor. [...]
[...]
// Copyright (c) 2010-2013 Intel Corporation. All rights reserved
// This software and associated documentation (if any) is furnished
// under a license and may only be used or copied in accordance
// with the terms of the license. Except as permitted by such
// license, no part of this software or documentation may be
// reproduced, stored in a retrieval system, or transmitted in any
// form or by any means without the express written consent of
// Intel Corporation.
While there is also many contradicting statements like this one in
src/soc/intel/fsp_baytrail/Kconfig:
## This file is part of the coreboot project.
##
## Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
## Copyright (C) 2013-2014 Sage Electronic Engineering, LLC.
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; version 2 of the License.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
The baytrail FSP was added in Coreboot by the commit
954f3882f1ea8512de9a5a6a38569c36bffae405 ("Add the Bay Trail FSP
include & srx directories") by Martin Roth, proably not on behalf on
Intel.
The commit also contains an email address from Martin Roth with the
se-eng.com domain (from Sage Electronic Engineering) and doesn't
contain any email address related to Intel. This increase the
probability that Intel wasn't involved in adding the Bay Trail FSP to
Coreboot.
Because of the (strong) doubts, the fact that the Bay Trail FSP was
also removed upstream and that GNU Boot doesn't support computers with
Intel Bay Trail, it's easier to just remove the nonfree software.
Reported-by: Leah Rowe <info@minifree.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
This was introduced in ARM trusted firmware in the commit
c76631c52b0b1550ff182c177555485700274314 ("rockchip: include hdcp.bin
and declare hdcp key decryption handler").
The hdcp.bin file contains code as it is included inside one of the
arm-trusted-firmware drivers with the following code:
__asm__(
".pushsection .text.hdcp_handler, \"ax\", %progbits\n"
".global hdcp_handler\n"
".balign 4\n"
"hdcp_handler:\n"
".incbin \"" __XSTRING(HDCPFW) "\"\n"
".type hdcp_handler, %function\n"
".size hdcp_handler, .- hdcp_handler\n"
".popsection\n"
);
The same file that contains the above code has the following copyright header:
* Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
This conflicts with the message of the commit mentioned above:
For some reason, HDCP key decrytion can't open source in ATF, so we
build it as hdcp.bin. Besides declare the handler for decrypting.
and we also have missing corresponding source code.
Because of the lack of source code, and the fact that GNU Boot doesn't
support computers with RK3399 yet, it's easier to remove the hdcp.bin
firmware than to pursue other ways to fix the issue.
Reported-by: Leah Rowe <info@minifree.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed "file file" typo in commit message
Acked-by: Adrien Bourmault <neox@gnu.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>
When pandoc is already installed on Trisquel 10, we have the
following:
# pkcon -y --allow-reinstall install pandoc
Resolving [=========================] Package not found: pandoc
Command failed: This tool could not find any available package: No packages were found
Since install_packages takes care of not trying to reinstall a package
that is already installed, using that instead fixes this issue.
This was broken by the commit 8a181f112f
("dependencies: trisquel: Add pandoc").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In French 'Installed' is 'Installé', and so when French is being used,
the grep that is used to understand if a package is already installed
fails.
This was broken by the commit 5050b5365e
("dependencies: trisquel-10: workaround package not found if already
installed.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The trisquel-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>
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>
The "4.7 Mcopy" section inside the mtools info manual explains that
mcopy's '-m' argument "Preserve the file modification time.".
So in the commit 9cc02ddde1 ("packages:
roms: Start adding automatic tests."), I vaguely recall having used it
to workaround some reproducibility issues.
Guix 1.4.0 uses mtools 4.0.42. So after retrieving the source with
'guix time-machine --commit=v1.4.0 -- build --system=i686-linux
--source mtools' we have that in the writeit function in mcopy.c (with
arg->preserveTime being set by -m):
/* preserve mod time? */
if (arg->preserveTime)
now = date;
else
getTimeNow(&now);
And date is set by the following in mtools 4.0.42:
if (Source->Class->get_data(Source, &date, &filesize,
&type, 0) < 0 ){
fprintf(stderr, "Can't stat source file\n");
return -1;
}
Since Guix is supposed to make images reproducible somehow, and that
mtools isn't patched by Guix to do that, and that it takes the time
from the source file, I used '-m'.
Since I was confident enough that gnuboot-trisquel-preseed.img was
reproducible, in the commit 9cc02ddde1
("packages: roms: Start adding automatic tests."), I also added the
checksum and checked it at build time to make sure the image is really
reproducible.
But when building this image again few days ago the checksum was
different. So I used the Guix diffoscope package to investigate the
issue.
Note that at the time of writing, you either need to use Guix's
diffoscope or to disable guestfs support in diffoscope for it to work,
otherwise diffoscope 277-1 (the version in the Parabola at the time of
writing) produce a python error probably because the partition table
size is 0, and it contains a FAT12 filesystem according to fdisk, but
then the FAT12 filesystem contained within also contains that
partition table. See the upstream bugreport at
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/390
for more details.
Here the preseed.img.old file corresponds to the checksum in the
commit 9cc02ddde1 ("packages: roms:
Start adding automatic tests."), and preseed.img.new to the one I got
by building again few days ago:
$ sha512sum preseed.img.old preseed.img.new
f12a4a941afc9e24288481ed1b44fbfedf52d706e9e8aa01cfb26bf5ccd54ca52afe9ef5497faf2966ba730c1200d8b8691ebb87e6a75cd8966e0edd49bcb3c0 preseed.img.old
5613d9a5cdd8847d5a688d56c77b8cf8881baa5eef7f373bb05a5ec601e383204e6a57b399d3de913c29386b18e7e3903c9511037922204744e3234cadc8671b preseed.img.new
And by using diffoscope we have:
$ diffoscope preseed.img.old preseed.img.new
--- preseed.img.old
+++ preseed.img.new
│┄ Format-specific differences are supported for ext2/ext3/ext4/btrfs/fat filesystems but no file-specific differences were detected; falling back to a binary diff. file(1) reports: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, sectors 2048 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 2, sectors/track 16, serial number 0x1234abcd, label: "MEDIA ", FAT (12 bit)
│┄ Installing the 'guestfs' Python module may produce a better output.
@@ -157,23 +157,23 @@
000009c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000a00: 4d45 4449 4120 2020 2020 2008 0000 5a4b MEDIA ...ZK
00000a10: 6e46 6e46 0000 5a4b 6e46 0000 0000 0000 nFnF..ZKnF......
00000a20: 5052 4553 4545 4420 4346 4720 1800 0000 PRESEED CFG ....
-00000a30: 21ec 21ec 0000 0000 21ec 0200 f50d 0000 !.!.....!.......
+00000a30: 21ec 2859 0000 0000 21ec 0200 f50d 0000 !.(Y....!.......
00000a40: 4365 0000 00ff ffff ffff ff0f 0000 ffff Ce..............
00000a50: ffff ffff ffff ffff ffff 0000 ffff ffff ................
00000a60: 0272 002d 0062 006f 006f 000f 0000 7400 .r.-.b.o.o....t.
00000a70: 2e00 7300 6500 7200 7600 0000 6900 6300 ..s.e.r.v...i.c.
00000a80: 0173 0068 0075 0074 0064 000f 0000 6f00 .s.h.u.t.d....o.
00000a90: 7700 6e00 2d00 6100 6600 0000 7400 6500 w.n.-.a.f...t.e.
00000aa0: 5348 5554 444f 7e31 5345 5220 0000 0000 SHUTDO~1SER ....
-00000ab0: 21ec 21ec 0000 0000 21ec 0400 3002 0000 !.!.....!...0...
+00000ab0: 21ec 2859 0000 0000 21ec 0400 3002 0000 !.(Y....!...0...
00000ac0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000ad0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000ae0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000af0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b00: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b10: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b20: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Here it really look like a timestamp, and since mdir gave no
difference between the 2 files inside the 2 images, I patched mdir
with the following patch:
@@ -438,6 +438,18 @@ static int list_file(direntry_t *entry, MainParam_t *mp UNUSEDP)
if(*mdir_longname)
printf(" %s", mdir_longname);
printf("\n");
+
+ printf("-> ctime_ms: 0x%hhx\n", entry->dir.ctime_ms);
+ printf("-> ctime[0]: 0x%hhx\n", entry->dir.ctime[0]);
+ printf("-> ctime[1]: 0x%hhx\n", entry->dir.ctime[1]);
+ printf("-> cdate[0]: 0x%hhx\n", entry->dir.cdate[0]);
+ printf("-> cdate[1]: 0x%hhx\n", entry->dir.cdate[1]);
+ printf("-> adate[0]: 0x%hhx\n", entry->dir.adate[0]);
+ printf("-> adate[1]: 0x%hhx\n", entry->dir.adate[1]);
+ printf("-> time[0]: 0x%hhx\n", entry->dir.time[0]);
+ printf("-> time[1]: 0x%hhx\n", entry->dir.time[1]);
+ printf("-> date[0]: 0x%hhx\n", entry->dir.date[0]);
+ printf("-> date[1]: 0x%hhx\n", entry->dir.date[1]);
} else {
char tmp[4*MAX_VNAMELEN+1];
And this then gives the following diff:
-> ctime[1]: 0x0
-> cdate[0]: 0x21
-> cdate[1]: 0xec
--> adate[0]: 0x21
--> adate[1]: 0xec
+-> adate[0]: 0x28
+-> adate[1]: 0x59
-> time[0]: 0x0
-> time[1]: 0x0
-> date[0]: 0x21
@@ -20,8 +20,8 @@
-> ctime[1]: 0x0
-> cdate[0]: 0x21
-> cdate[1]: 0xec
--> adate[0]: 0x21
--> adate[1]: 0xec
+-> adate[0]: 0x28
+-> adate[1]: 0x59
-> time[0]: 0x0
-> time[1]: 0x0
-> date[0]: 0x21
This means that the access date difers. This also explains why it was
not spoted during the creation of the commit
9cc02ddde1 ("packages: roms: Start
adding automatic tests.") as tests were done at the same date.
So this time I created a build VM by adding the following service to
my Guix system configuration (I also had to remove hacks I had that
set the kvm group id to the same ID used by Trisquel run 'guix system
reconfigure' and rebooted):
(service virtual-build-machine-service-type
(virtual-build-machine
(cpu "host")
(cpu-count 2)
(auto-start? #f)))
This created a VM whose clock is set to 'a few years ago' according to
the Guix manual[1].
[1]https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#Virtual-Build-Machines
I then ran built the image as usual:
$ guix time-machine --commit=v1.4.0 -- build -L resources/guix/ \
gnuboot-trisquel-preseed.img
--without-tests=gnuboot-trisquel-preseed.img
I then copied the resulting image, started the build VM with 'herd
start build-vm', deleted the old image from the store (with 'guix gc
-D') and then re-built it (it used the VM to offload the build as
shown in the build logs).
And now both resulting files are now the same despite being built on a
different date.
See also the following blog post for more context into use cases for
this build VM[2]:
[2]https://hpc.guix.info/blog/2024/03/adventures-on-the-quest-for-long-term-reproducible-deployment/
Bug: https://savannah.gnu.org/bugs/?66224
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The image resulting from the gnuboot-trisquel-preseed.img package is
checked against checksums inside the 'check function of this package.
If for some reasons we want to update the checksums, an easy way to do
it is to build the package but not run the 'check function and do the
checksum on the resulting file. The Guix 1.4.0 manual explains how to
not run 'check with the "--without-tests=package" option in the
"10.1.2 Package Transformation Options" section.
However if we attempt that with the following command, the
without-tests has no impact at all:
$ guix time-machine --commit=v1.4.0 -- build -L resources/guix/ \
gnuboot-trisquel-preseed.img \
--without-tests=gnuboot-trisquel-preseed.img
This changes makes the above command work as expected.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The test data consists mostly in nonfree boot firmware images. The
images contain nonfree binaries like for instance microcode updates
without complete and corresponding source code.
As more and more boot firmware images are added over time it's a good
idea to just remove everything in that directory to make sure that we
don't ship nonfree software from that directory again, while also
lowering the maintenance costs.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
