120 lines
5.6 KiB
Markdown
120 lines
5.6 KiB
Markdown
---
|
|
title: Libreboot 20241206 release revisions
|
|
x-toc-enable: true
|
|
...
|
|
|
|
This article concerns Libreboot 20241206. For general information about that
|
|
release, please read
|
|
the [Libreboot 20241206 release announcement](libreboot20241206.md).
|
|
|
|
Occasionally, stable releases such as this one may contain minor (or critical)
|
|
issues that went unnoticed during testing. When this occurs, critical or
|
|
otherwise desirable fixes are implemented, while not fundamentally altering
|
|
the substance of the original release.
|
|
|
|
When this occurs, the ROM image and source code archives are entirely re-built,
|
|
and re-uploaded, replacing the old one. Patch files are provided alongside the
|
|
updated source archive, so that you can revert (from it) back to the older
|
|
revisions if you wish; by doing this, you can therefore also re-create the
|
|
original release archive, for reference.
|
|
|
|
Revision 1 (8 December 2024)
|
|
----------
|
|
|
|
A bug was found whereby `seabios_` images are created twice, This was fixed in
|
|
the revision `e3b77b132e6b5981c09bc1ce282afaae64058ab3`. This bug caused vendor
|
|
file insertion to fail on release images, because the `vendorhashes` file would
|
|
list the file twice, but one of the hashes would be wrong.
|
|
|
|
This is because the build system wrongly created U-Boot-only images first with
|
|
that name, because the `add_uboot` function in `rom.sh` unconditionally created
|
|
images with U-Boot in them; the function also creates ARM64 images, where U-Boot
|
|
is the primary payload.
|
|
|
|
On x86 machines, SeaBIOS should be the main payload, chainloading U-Boot.
|
|
|
|
The build system would then create the actual `seabios_` image, replacing the
|
|
other one, on x86 machines.
|
|
|
|
So, the command to create the first image was removed. However, just before
|
|
uploading `rev1` images, it was discovered that this would cause no U-Boot
|
|
images to be built for ARM64 devices, which lead to Revision 2:
|
|
|
|
Revision 2 (8 December 2024)
|
|
----------
|
|
|
|
See commit ID `b910424b5df8ed7c931a7b8f5cc8e34eacf0ca3e`.
|
|
|
|
Revision 1 was reverted, and replaced with the following logic instead:
|
|
|
|
In `add_uboot`, the instruction to create a ROM image was changed so that it
|
|
only creates one where U-Boot is the primary payload (which is the case for
|
|
ARM64).
|
|
|
|
The source archive is now `20241206rev2` instead of `20241206`, and the same
|
|
is true of affected images on x86, where `vcfg` is set in `target.cfg`.
|
|
|
|
Revision 3 (11 December 2024)
|
|
----------
|
|
|
|
See commit ID `3b6b283eabe7a655c861d1543aeae49d27566f53` and the two commits
|
|
before that.
|
|
|
|
This revision disables PCI-E Re-plug (hotplug feature) for the NVMe SSD on
|
|
Dell OptiPlex 3050 Micro, to prevent the device from being renamed randomly;
|
|
such renaming will cause a system crash if booting Linux from the NVMe.
|
|
|
|
In my case, I was running RAID1 (SATA+NVMe) and every few days, the RAID1 got
|
|
unsynced; I simply re-synced and it was fine, but what if that was a RAID0? It
|
|
would possibly corrupt the entire array.
|
|
|
|
This revision should prevent the issue from occuring. Without this patch,
|
|
the `nvme0n1` device (as an example) might randomly rename to `nvme0n2`, because
|
|
Linux would see it as a new device.
|
|
|
|
This same fix was made to the ThinkPad T480/T480s to fix the same issue there,
|
|
which manifested during S3 resume, but that bug never made it into the release
|
|
because it was fixed *before* the initial release of Libreboot 20241206.
|
|
|
|
The ROM images were all re-uploaded, compiled from the rev3 tarball, because it was discovered that the rev2 tarballs had a GRUB built showing the old Libreboot 20241008 version number; the actual code in GRUB matched the code for 20241206, but it was a cached GRUB build from just before updating the version number for release. This is because the rev2 ROM image tarballs were done manually, to avoid a full re-build of every target in lbmk. To avoid all doubt, all ROM images have been re-compiled with the version number corrected, from the rev3 tag.
|
|
|
|
Revision 4 (17 December 2024)
|
|
----------
|
|
|
|
Rev4 fixed a bug: GRUB was not allowing the background image to be changed,
|
|
despite rules in `grub.cfg` that made one in CBFS load before memdisk. This fix
|
|
was implemented by no longer inserting background images into GRUB's memdisk,
|
|
instead inserting them into CBFS.
|
|
|
|
This way, you can remove what's in CBFS and replace it with your own, if that's
|
|
what you want to do.
|
|
|
|
To celebrate this fix, the default background logo was also changed. The old
|
|
one was a white silhouette of the Libreboot logo, whereas the new one is of
|
|
the same shape but shows a rainbow-coloured gradient instead of all-white. This
|
|
rainbow logo was also used in U-Boot on the very initial Libreboot 20241206
|
|
release, and it's also used for the main website logo at the time of this
|
|
revision.
|
|
|
|
Basically, this fix was done as an excuse just to do another revision update,
|
|
to change the logo! The actual bug was actually quite minor and irrelevant.
|
|
|
|
Revision 5 and 6 (17 December 2024)
|
|
----------------
|
|
|
|
All current ROM/src archives in this release match changes up to rev6.
|
|
|
|
I decided afterall to keep using the boring all-grey silhouette logo in GRUB.
|
|
I also made the same decision for U-Boot.
|
|
|
|
The plain logo is less eye catching and looks less out of place, and it's
|
|
uncontroversial in every way. This revision still contains the fix allowing
|
|
GRUB backgrounds to be changed. Rev5 made this change to GRUB and Rev6 made
|
|
it to U-Boot. All ROM images were re-compiled to rev6, and re-uploaded.
|
|
|
|
A minor change, to be sure. I need Libreboot to be as trouble-free as possible
|
|
to everyone, and some countries are culturally hostile to the particular
|
|
colour gradient used by the old logo (from rev4); even if I preferred that
|
|
logo, I want those users to have no trouble at all using Libreboot in public.
|
|
Libreboot's only purpose is to provide free boot firmware.
|