Fedora 42 will offer optimized binaries for x86_64 v2, v3 and v4, says goodbye to SquashFS and plans to unify grub and shim

Fedora Linux Logo

The Fedora developers have announced a new proposal to be implemented in the upcoming Fedora 42 release (scheduled for late April), which introduces the ability for maintainers to package additional executable variants optimized for microarchitectures x86-64-v2, x86-64-v3 y x86-64-v4.

It is mentioned that purpose of this proposal, it is el take advantage of specific performance improvements based on hardware capabilities, although Fedora will continue to produce packages for the standard x86-64-v1 architecture.

Notably Other distributions are already moving in this direction., as CentOS is mentioned as an example, where it is compiled using x86-64-v2, while RHEL 10 is based on x86-64-v3. While Performance improvements typically range around 10%, with certain scenarios showing notable increases, reaching up to 120%. 

In this model, Optimized libraries are placed in specific subdirectories, allowing the dynamic linker to automatically load the most suitable version. For executables, Fedora plans to implement a similar system using the hwcaps-loader layer, which will select and run the variant most compatible with the detected CPU capabilities. Maintainers will decide which packages will include these additional variants, based on specific performance tests.

Currently, the proposal, still pending approval by the FESCo (Fedora Engineering Steering Committee) which aims to extend existing support for optimized libraries, which are currently delivered using the glibc-hwcaps mechanism.

Grub and Shim Unification in Fedora 42

In addition to that, another of the changes that have been proposed for Fedora 42 is the one unify the update methods of bootloaders GRUB and Shim in the standard and atomic versions of the distribution. This proposal seeks to replace the place where RPM package installation scripts directly update the /boot and /boot/efi directories, with the use of the bootupd toolkit, already implemented in Fedora atomic releases.

The new proposal raises RPM packages containing bootloaders install their components into a separate directory inside the /usr partition, rather than directly modifying the mentioned directories. The contents of /usr would then be synchronized with /boot and /boot/efi using bootupd.

It is mentioned that by implementing this change, Several significant advantages are presented:

  • Greater security and reliability: Using bootupd would allow for the implementation of an alternative boot option. This means that in the event of problems following a bootloader update, users could revert to a previous configuration without the risk of rendering the system inoperable.
  • Consistency between variants: By taking a common approach to both atomic and standard Fedora releases, maintenance would be simplified and discrepancies between upgrade methods would be reduced.
  • Modularity: By separating the bootloader components into /usr, package management is made easier, reducing potential conflicts during upgrades.

Fedora 42 says goodbye to SquashFS

Last but not least, too In Fedora 42 it is planned to migrate all active builds of the distribution from SquashFS to EROFS filesystem, This is done in order to take advantage of the advanced capabilities of EROFS, which already has support for Dracut since its version 103. However, this proposal still requires the approval of the FESCo (Fedora Engineering Steering Committee), in charge of technical decisions in the development of Fedora.

It is mentioned that The choice of EROFS is due to the need to adopt a file system in constant development, SquashFS has not received any significant updates since 2023. EROFS, on the other hand, continues to evolve and incorporate improvements that could offer long-term benefits to the distribution. In addition, its unique method for data compression, based on fixed-size blocks after compression, sets it apart from other systems and allows for more efficient handling of performance in certain situations.

The change will affect all system images operating in read-only mode., such as Live editions with KDE, Xfce, Budgie, LXQt, MiracleWM and COSMIC desktopsIt will also include specialized variants such as Fedora KDE Plasma Mobile and Fedora CoreOS Live. The decision seeks to take advantage of the advantages offered by EROFS in terms of performance and random access speed.

Finally, if you are iInterested in learning more about it, you can check the details In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.