move 20241206 rev notes to own page
this release is pretty crazy. a lot more revisions are planned for the 6 december release. move the revnotes to a dedicated page, in anticipation of many more revisions (in my head there are about 30 additional changes planned). Signed-off-by: Leah Rowe <info@minifree.org>master
Leah Rowe
parent
4aea280c60
commit
2a4b7d5943
|
|
@ -0,0 +1,119 @@
|
|||
---
|
||||
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.
|
||||
|
|
@ -351,113 +351,17 @@ for reading, and have a wonderful day!
|
|||
Revisions
|
||||
=========
|
||||
|
||||
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.
|
||||
Several revisions have been made to this release, since the original release.
|
||||
With stable releases, it's normal to make such revisions, when critical bugs
|
||||
are discovered, or desirable changes are otherwise identified.
|
||||
|
||||
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.
|
||||
When these changes are made, the release is re-compiled, with the newly amended
|
||||
binaries and sources re-uploaded, replacing what was there before. Individual
|
||||
patch files are also provided, so that you can (using them as reference) revert
|
||||
the source archive back to previous revisions.
|
||||
|
||||
Revision 1
|
||||
----------
|
||||
Please see: [Libreboot 20241206 release revisions](libreboot20241206.Revisions.md)
|
||||
|
||||
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
|
||||
----------
|
||||
|
||||
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
|
||||
----------
|
||||
|
||||
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
|
||||
----------
|
||||
|
||||
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
|
||||
----------------
|
||||
|
||||
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.
|
||||
Many revisions are planned in the run-up to next year's stable release ETA Summer
|
||||
of 2025. In particular, there is much work that still needs to be done on the
|
||||
U-Boot payloads (x86 and ARM64).
|
||||
|
|
|
|||
Loading…
Reference in New Issue