libreboot
/
lbwww
1
0
Fork 0
Code Packages Projects Releases Activity

update 

Signed-off-by: Leah Rowe <info@minifree.org>
master
Leah Rowe 2024-06-09 23:03:39 +01:00
parent 99728a5cef
commit 6b95fd6afd
2 changed files with 41 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
site/docs/install/index.md
View File

@ -9,49 +9,6 @@ x-toc-enable: true
**IMPORTANT ADVICE: [PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING/UPDATING
LIBREBOOT](../../news/safety.md).**
**GRUB payload warning**
====================
Firstly, it should be stated: in almost all cases, GRUB works just fine, on
all of the machines that we test, but as of 26 May 2024 we got the error
report:
See: <https://codeberg.org/libreboot/lbmk/issues/216>
Although we've only seen this thus far (as per user reports) on Intel
SandyBridge based Dell Latitude laptops, we advise:
**DO NOT use a ROM image where GRUB is the first payload. If you want to
use the GRUB payload, please use a ROM image with `seabios_` at the start
of the file name. Avoid images with `grub_` at the start of the file name.**
ROM images with `grubonly` in them should also be avoided; if you want GRUB
to be the first thing you see (without interruption), use a ROM image
with `seabios_` at the start of the file name, and `grubfirst` at the end;
these place a bootorder file in CBFS, so that SeaBIOS loads GRUB first, but
you can still press ESC to bring up the SeaBIOS boot select menu.
*This warning applies to Libreboot 20240504 and other recent releases.*
**We have since fully mitigated this bug**; SeaBIOS is now the primary payload on
all boards, with GRUB still available in the boot select menu, and we have
identified that it was caused by the xHCI driver which has since been removed
for the affected machines(machines which don't have xHCI anyway, but they
touch code that does run on the given machines). The xHCI support works fine
on some newer machines and will be re-added there by making GRUB multi-tree,
so that different boards can use different versions of GRUB. This will be done,
and present in the next Libreboot release after 20240504, in addition to fixing
the actual bug itself. **For now, there are no problems!**
Libreboot releases after 20240504 will *only* (on x86) contain ROM images where
SeaBIOS is the first payload, without disabling the SeaBIOS menu (no `grubonly`). You'll still be able to use GRUB, either by pressing ESC for the boot
select menu, and/or using an image with `grubfirst` in the file name so that
SeaBIOS loads it first (while still permitting boot select via ESC keypress).
GRUB's code is vast, and complicated, so this policy change is permanent,
until GRUB can be well-audited (likely forked, with dead/legacy code removed).
SeaBIOS code is much smaller and more robust. Remember always: code equals bugs.
Need help?
==========

41
site/news/libreboot20240504.md
View File

@ -454,3 +454,44 @@ fault or by virtue of the product; the eDP-based targets are therefore a liabili
to the Libreboot project.
That is all.
Errata
======
See: <https://codeberg.org/libreboot/lbmk/issues/216>
This bug has been *fixed* in lbmk.git, and the fix will be included in
the next release, but it wasn't caught in the 20240504 release.
The bug is quite serious, and it was previously decided that documentation
should be written warning about it (in docs/install/). The bug was *only*
triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never
reported on other boards, but there's no way to fully know; what is known
is that the offending patch that caused the bug has been *removed*; namely,
xHCI GRUB patches, which are now only provided on Haswell and Broadwell
hardware (where the bug has not occured). **Therefore, we know that the
bug will no longer occur.**
The next release will exclude xHCI support on machines that don't need it,
and a mitigation is in place that makes SeaBIOS the primary payload, to prevent
effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the
first payload then the machine remains bootable even if a similar bug occurs.
It is now the default behaviour, in the next release, that certain images
contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
still press ESC to access the SeaBIOS boot menu if you want to directly boot
an OS from that. This, and the other change mentioned above, will guarantee
stability. GRUB is *no longer* the primary payload, on any mainboard.
However, it was later decided to put this release in the `testing`
directory instead; it was initially designated as a stable release.
All ROM images for the 20240504 release have been *removed* from rsync,
but the source tarball remains in place.
You are advised to use the 20240225 release, or the next release
after 20240504.
A new [audit](audit5.md) has been conducted, marked complete as of 9 June 2024,
fixing this and many issues; a new *true* stable release will be made available
some time in June 2024.