openSUSE

GRUB2 with BLS is now in MicroOS and Tumbleweed

Recently the openSUSE project released for MicroOS and Tumbleweed a new version of the GRUB2 package, with a new subpackage grub2-$ARCH-efi-bls. This subpackage deliver a new EFI file, grubbls.efi, that can be used as replacement of the traditional grub.efi.

The new PE binary is a version of GRUB2 that includes a set of patches from Fedora, which makes the bootloader follow the Boot Loader Specification (BLS). This will make GRUB2 understand the boot entries from /boot/efi/entries, and dynamically generate the boot menu showed during boot time.

This is really important for full disk encryption (FDE) because this means that now we can re-use all the architecture and tools designed for systemd-boot. For example, installing or updating the bootloader can now be done with sdbootutil install, the suse-module-tools scriptlets will create new BLS entries when a new kernel is installed, and the tukit and snapper plugins will take care of doing the right thing when snapshots are created or removed.

Reusing all those tools without modification was a significant win, but even better, many of the quirks that classical GRUB2 had when extending the event log are no longer present. Before this package, sdbootutil needed to take ownership of the grub.conf file, as this will be measured by GRUB2 by executed lines. That is right! For each line that is read and executed by the GRUB2 parser, a new PCR#8 will take place, and because GRUB2 support conditional as other complex constructors, it is very hard to predict the final value of PCR#8 without imposing a very minimal and strict grub.conf.

However, with the new BLS subpackage, this file, along with the fonts and graphical assets for the theme, and the necessary modules (such as bli.mod), are now included in the internal squashfs within the EFI binary. GRUB2 will no longer measure those internal files without compromising security guarantees because now it is the firmware that measures the entire EFI when the bootloader is executed during the boot process.

As today, we cannot use YaST2 to install GRUB2 with BLS, but we can do that manually very easily. We need to make a systemd-boot installation, replace LOADER_TYPE from systemd-boot to grub2-bls, install the new GRUB2 BLS package, and do sdbootutil install. Another option is to play with one of the available images for MicroOS or Tumbleweed.

Have a lot of fun!

Hello everyone!

I'd like to announce the start of development and the public availability of what we currently refer to as Leap 16.0 pre-Alpha. Since this is a pre-Alpha version, significant changes may occur, and the final product may look very different in the Alpha, Beta, Release Candidate, or General Availability stages. The installer will currently offer you Base, GNOME, and KDE.

Users can get our new Agama install images from get.opensuse.org/leap/16.0. The installer will currently offer you Base, GNOME, and KDE installation.

Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.

We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they're used to from previous releases.

Further details are available on our roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.

Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.

There is no plan to make a Leap 15.7, however, we still need to deliver previously released community packages from Leap 15 via Package HUB for the upcoming SLES 15 SP7. This is why there are openSUSE:Backports:SLE-15-SP7 project and 15.7 repos in OBS.

The target audience for pre-Alpha are early adopters and contributors who would like to actively be part of this large effort. Adopters should consider booting Agama Media from time to time just to check compatibility with their hardware.

For non-contributor users, I highly recommend waiting until we have a Beta, which is expected in the late Spring of 2025.

Specifically for Agama I highly recommend using github.com/agama-project and collaborating with the YaST team on suggestions and incorporating any changes.

For the rest of the components, the workflow isn't changing; just select version 16.0 for bug submissions.

Feature requests will be reviewed every Monday at a feature review meeting where we'll convert code-o-o requests into JIRA requests used by SUSE Engineering where applicable.

The factory-auto bot will reject all code submit requests against SLES packages with a pointer to code-o-o. You can get a list of all SLFO/SLES packages simply by running osc ls SUSE:SLFO:1.1:Build.

Just for clarification SLFO, SUSE Linux Framework One, is the source pool for SLES 16 and SL Micro 6.X.

I highly recommend using code-o-o to co-ordinate larger community efforts such as Xfce enablement, where will likely need to update some of SLES dependencies. This allows us to share the larger story and better reasoning for related SLES update requests. The list of features is also extremely valuable for the Release article.

For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group. Later, we plan to rework the existing Leap 16.0 Images job group for testing the remaining appliance images.

The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).

Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers poo#164141 Leap 16.0 enablement and poo#166562 upgrade from 15.6.

Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we'd like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.

Do you want to help us on this front? Spread the news and feel free to join the #openSUSE_Marketing Telegram channel(https://t.me/openSUSE_Marketing)! https://en.opensuse.org/openSUSE:Marketing_team

Many thanks to all who helped us to reach this point.

Lubos Kocman on behalf of the openSUSE Release team

hey people on the internet, I updated my tumbleweed to 20241002 and since then, the system would randomly freeze and crash, and automatically reboot after a short while. It also happens when waking from suspend. Does this happen to anyone else?