Libreboot 20241206 release revisions

English | Revisions

Return to index

This article concerns Libreboot 20241206. For general information about that release, please read the Libreboot 20241206 release announcement.

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.

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:

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.

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.

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.

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.

Markdown file for this page: https://libreboot.org/news/libreboot20241206.Revisions.md

Subscribe to RSS for this site

Site map

This HTML page was generated by the Untitled Static Site Generator.