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>
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 goal of this script is similar to Linux's checkpatch.pl: it is
meant to check patch before sending them.
Right now it only tests if a signed-off-by is missing, and if the
commit information (commit message, author, date, etc but not the
diff) is too big as a workaround to the bug #66268[1], but over time
more checks can be added.
The report of the bug #66268[1] mention that what tend to trigger the
issue is commits "with a large (4kB) commit message".
[1]https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66268
So we want to avoid such commits to avoid breaking "guix git
authenticate" in the future.
To do that, checkpatch.scm reports an error if the size of the patch
from the beginning of the patch file until the point where the diff
starts is less than 2500 Bytes.
A lower threshold has been chosen as the commit object size can be
bigger than the patch file without the diff, as there are at least
signatures inside the commit objects.
The last commit GNUtoo signed at the time of writing is the commit
83f955870a ("website/docs/build: mark
the Trisquel bug as solved and clarify the Guix one") and this is done
with an RSA GPG key of 4096 bits and in this case the signature is
about 855 bytes. This was calculated with 'git cat-file -p 83f95587'.
As GNU Boot is looking for contributions, including contributions by
less technical users, we do not require its use by people sending
patches, however it is still a good idea to require its use by the GNU
Boot maintainers as we want to spot the most important issues that
cannot be fixed later on.
Thanks to neox for the research and the calculation on the git commit
signature size.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
If we run the following commands:
$ git clone https://git.savannah.gnu.org/git/gnuboot.git
$ cd gnuboot
$ git authenticate bf2b91df54 \
"E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" \
-k origin/keyring
We then end with the following issue:
Authenticating commits bf2b91d to c85fbae (47 new commits)...
guix git: error: commit c85fbae78f
is not a descendant of introductory commit
bf2b91df54
But first the bf2b91df54 commit ("Add
.guix-authorizations file for "guix git authenticate".") is the proper
introductory commit and everything else is fine too (it is signed by
the right key, the signature matches, all the history between bf2b91d
and c85fbae is linear and all the signatures also match fine.
The issue is that the introductory commit size is > 4KB and so this
trigger a bug in Guix and/or guile-git[1] where guix uses eq? to
compare commits and two commits are not equals with eq? if their hash
is the same but that they are > 4KB.
[1]https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66268
The workaround is then to substitute the introductory commit with the
one right after it and also to make sure that any commit in between
that introductory commit substitute and HEAD have a commit message and
or commit data and/or patch that is less than 4KB.
This issue also needs to be fixed upstream in Guix and/or guile-git
but we also need to workaround now as the fix could take time to reach
users as first the problem is not trivial to fix and even once fixed
in Guix, it would be best not to require to have to run git pull
(which can take a huge amount of time, probably hours) just to
authenticate the GNU Boot git repository.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The first version of the 3f9b38739f
patch ("manual: Add section about building GNU Boot.)" and the GNU
Boot 0.1 RC4 announce have the following guix git authenticate
command:
$ guix git authenticate $(git rev-parse HEAD) \
"E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" \
-k origin/keyring
This is wrong as HEAD is not an introductory commit and it can only
work if it is signed by the "E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3
6871 16F6" key which defeats many of the important features of guix
git authenticate like the ability to delegate trust to multiple
people.
This command was probably used by me during early tests as I didn't
have neox's key to sign commit and that my key was invalid (see the
commit dde4223088 "Fix
.guix-authorizations for Denis 'GNUtoo' Carikli." for more details)
and it was probably kept as it appeared to work.
Since the expected way to use guix git authenticate is with an
introductory commit, the output of the command is then predictable and
it should be exactly the same than the one described in the GNU Boot
manual.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: - fixed a typo
- found duplicated see in "(see the @pxref{,,,guix,GNU Guix
reference manual} for more details).", "See the
@pxref{Security features}"
- fixed duplicated see in "they are also documented in the
@pxref{,,,grub,GNU GRUB manual} as well", "and @pxref{Building
GNU Boot from [...]}"
Acked-by: Adrien Bourmault <neox@gnu.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: found/fixed many duplicate see as pxref adds a "see [...]":
- fixed "or the @pxref{Installation,,,guix,GNU Guix[...]}"
- found "See @pxref{Invoking guix git authenticate,[...]}",
"-See also @pxref{Authenticating [...]}", "See the
@pxref{Supported", "See the @pxref{Installing or [...]}
to understand".
Acked-by: Adrien Bourmault <neox@gnu.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: - fixed duplicate see with @pxref in "(@ref{GNU Boot images} for
more details)" and "the @pxref{GNU Boot images types} subsection.",
"will be documented in the @ref{GNU Boot images} section below"
- found "See the @pxref{boot software} section to understand",
"described in the previous subsection (@pxref{GNU resolution graphics",
"described in the previous subsection (@pxref{GNU Boot images types}).",
"(see @pxref{boot software} for more details)."
Acked-by: Adrien Bourmault <neox@gnu.org>
This section explains what hardware components are compatible with GNU
Boot or not.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: found "See @pxref{Supported computer parts and peripherals} for
more details".
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In the GNU Boot 0.1 RC3 release, we already have images for various
computers, so we use that as a base for the list of compatible
computers.
For computers supported by the same images like the ThinkPad X200,
X200s and X200 Tablet, they have different markings on the computer so
it's a good idea to treat them as separate computer models.
Some users might also be used to projects (like Replicant) requiring
very specific computer models, so following the trend probably helps
users avoiding hardware not compatible with distributions they want to
use.
In addition, the installation instructions will also differ a lot
between a ThinkPad X200 whose flash chip is easily accessible and the
ThinkPad X200S which has a WSON-8 flash chip that doesn't have any
clip available for it.
We also list computers that have the RYF certification as separate
computers as it will simplify things later on: so far we're aware that
Minifree Ltd changed the flash chip size on many of the computers they
sold and that that Technoetical provided modified GNU Boot images with
the same MAC Address that is written down on some stickers on the
bottom of the computer.
Because of that installation instructions might differ between a
ThinkPad X200 and a Technoetical X200.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
So far the manual only tell that GNU Boot is a boot software
distribution and it explains what it means.
It didn't tell what it means for GNU Boot to be fully free.
In addition, other 100% free software boot distributions also exists,
so we also need to explain why we need GNU Boot to exist.
More details about the GPU issue will be added later on.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.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>
