diff --git a/site/news/libreboot20241206.Revisions.md b/site/news/libreboot20241206.Revisions.md new file mode 100644 index 0000000..87d02c9 --- /dev/null +++ b/site/news/libreboot20241206.Revisions.md @@ -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. diff --git a/site/news/libreboot20241206.md b/site/news/libreboot20241206.md index 8b39856..49543f4 100644 --- a/site/news/libreboot20241206.md +++ b/site/news/libreboot20241206.md @@ -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).