Considering drop of Legacy BIOS boot from SLES / Leap 16
Hello openSUSE! SUSE is evaluating drop of Legacy boot support, please let us know if you foresee any issues. Please be aware that SLES 16 / Leap 16 support requires x86_64-v2 so I personally believe that there won't be many cases where such a system would not support UEFI. I was a bit concerned about virt scenarios, we should ensure that uefi is the default for new VMs as it seems to be legacy boot now. If you have any concerns, please share them in code-o-o https://code.opensuse.org/leap/features/issue/194 I'll make sure that product management gets to see it. All feedback is highly welcome. Many thanks in advance -- Best regards Luboš Kocman openSUSE Leap Release Manager
I don't agree. One of the selling point of openSUSE/SUSE is that it supports a lot of older hardware. On Fri, Feb 14, 2025 at 7:34 AM Lubos Kocman via openSUSE Factory <factory@lists.opensuse.org> wrote:
-- Terror PUP a.k.a Chuck "PUP" Payne ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- Terrorpup openSUSE Advocate/openSUSE Member x/mastodon.social -- @terrorpup dicord -- terrorpup#3550 bluesky -- @terrorpup967.bsky.social uglyscale.press Register Linux Userid: 155363 openSUSE Community Member since 2008.
On Fri, Feb 14, 2025 at 3:44 PM Chuck Payne <terrorpup@gmail.com> wrote:
I don't agree. One of the selling point of openSUSE/SUSE is that it supports a lot of older hardware.
I do not know how and to whom you sell the openSUSE, but server vendors most certainly stop qualifying their end-of-sale hardware for the new SLES releases, so you have no supported way to deploy new SLES versions on the old hardware.
Hello, On Fri, Feb 14, 2025 at 07:42:28AM -0500, Chuck Payne wrote:
I don't agree. One of the selling point of openSUSE/SUSE is that it supports a lot of older hardware.
and that's still the case for Tumbleweed. For Leap 16 support for a lot of older hardware was dropped by requiring x86_64-v2 CPU feature set for dubious benefit. With that there is not much point supporting legacy BIOS, either. Most if not all hardware that would benefit from that is not supported anyway. Thanks Michal
Hi, On Freitag, 14. Februar 2025 13:51:35 Mitteleuropäische Normalzeit Michal Suchánek wrote:
can't speak for SLES, but as for Leap I suppose, that it will be used even for unsupported hardware, as long as everything will work. At least I have two servers with BIOS versions, that don't fully support UEFI. I will try to update them to the newer versions of Leap, because otherwise I have to dump hardware, that was really expensive, runs without any problems and has enough performance for the next years. And Tumbleweed is no alternative for these servers. So I'd plead for not dropping legacy boot for the moment.
Bye. Michael.
On Fri, Feb 14, 2025 at 1:51 PM Michal Suchánek <msuchanek@suse.de> wrote:
Yes, that's why I personally think dropping legacy BIOS won't really extend the existing compatibility filter. Denis Knorr mentioned 2020 hardware with coreboot/libreboot. I'm not yet sure what it means for such hardware.
-- Best regards Luboš Kocman openSUSE Leap Release Manager
On 14/02/2025 14.56, Lubos Kocman via openSUSE Factory wrote:
Denis Knorr mentioned 2020 hardware with coreboot/libreboot. I'm not yet sure what it means for such hardware.
I got a chromebook with coreboot and installed tianocore on it for UEFI boot. It works fine so far. For the overall issue, I suspect that there are machines out there that support x86_64-v2 but the BIOS does not boot correctly in UEFI mode, so people switched secure-boot off for legacy BIOS boot.
Den 18.02.2025 10:58, skrev Bernhard M. Wiedemann via openSUSE Factory:
To test the Aeon Desktop RC3, I installed it on a separate disk in a machine with already installed openSUSE Slowroll, TW and Leap in a multiboot setup via Grub2 UEFI. Aeon uses systemd-boot, not grub, and was started via BIOS system boot (F11). From there the boot disk priority could be changed back to UEFI Secure openSUSE, so that the Grub menu became default startup again. Althought it is acceptable for testing to use F11 to select the Aeon boot disk via BIOS, it would be fine if the YaST2 Bootloader could support the switch to System-boot and hopefully be able to include/embrace the Aeon Desktop (?) https://bugzilla.opensuse.org/show_bug.cgi?id=1236695
Hello Terje, YaST is basically in a maintenance mode, please don't expect any new features by the YaST team. If your idea would apply also to a boot config screen in the installer, then feel free to raise issue here https://github.com/agama-project/agama/issues Thank you for your understanding Lubos On Tue, Feb 18, 2025 at 12:10 PM Terje J. Hanssen <terjejhanssen@gmail.com> wrote:
-- Best regards Luboš Kocman openSUSE Leap Release Manager
On 2/18/25 12:10 PM, Terje J. Hanssen wrote:
Regarding including Aeon Desktop as an option in YaST or Agama (if I understood correctly), that's not desired by the Aeon developers. At least at this point in time, they prefer to have their own separate deployment mechanisms (not a traditional installer like YaST or Agama). Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
My system supports UEFI, however I installed TW in legacy BIOS mode as more habitual. Would be there any easy tool to switch to UEFI?
On 2025-02-18 15:57, Aleksey Kontsevich wrote:
My system supports UEFI, however I installed TW in legacy BIOS mode as more habitual. Would be there any easy tool to switch to UEFI?
Maybe switching mode in yast bootloader, but you have to create the ESP partition in advance. But AFAIK TW is not removing Legacy BIOS boot. Leap is. -- Cheers / Saludos, Carlos E. R. (from 15.6 x86_64 at Telcontar)
Leap removing legacy BIOS seems to be also an open question. As it seems now SUSE will likely support legacy bios on certain scenarios (VM images etc), so the boot stack itself will likely be supported. That would mean that we (Leap) could likely keep it. The priority of bug reports specific to scenarios unsupported by SUSE would be questionable. Discussions are still taking place and people are listening to the community feedback. Cheers Lubos Lubos On Tue, Feb 18, 2025 at 8:08 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
-- Best regards Luboš Kocman openSUSE Leap Release Manager
wow, what a long discussion! ... considering the whole topic is just about getting the system up. :-) I mean, since throwing out windows and the nvidia graphic card back in the late 1990ies, I have never much thought about booting anymore. It's basically the hardware starting some code on a certain place on disk, that ... over some hops like a bootloader and an initrd loading and handing over to the kernel, and that finally handing over to an init process/system, nowadays mostly systemd. So if maintaining some code there is so much effort, then it seems that there must have been grown a lot of inter-stage, complex code in that area over the years. Well. What I didn't get so far, or I must have missed that: if the suggestion is to remove the support from SLES16/Leap16 to save much effort, then I'm wondering how that effort is saved exactly ... considering that the same support shall be kept in Tumbleweed? And further: what packages are we talking about exactly? ... because some packages like some from Base:System are also sync'ed with SLE from time to time? My personal usage: I have no idea whether my Dell PC from 2013 supports it - I never had to think about it. Then there's also quite some VMs (both openSUSE and SLES). How about other virtualization than the already mentioned qemu like Virtualbox, or some VMware ESX versions? Finally: the whole world was shocked that Win11 partially doesn't support like 4-5 year old HW, and there have been articles in several magazines to migrate them to Linux. Nice! Now it would be a very unlucky timing if SUSE/openSUSE would get into the same boat with a similar move; the Windows fan clubs would ROFL about Linux. Should be avoided, especially if it would be singling out our beloved distribution only. Have a nice day, Berny
Hi Berny, Am 21.02.25 um 21:13 schrieb Bernhard Völker:
I don't think it is the issue of having to maintain (and provide support for!) another boot loader flavor also for SLES, I guess it is more something in the line of "we have some cool new features we'd like to introduce, but it is a lot of work to make them work across all boot loaders, so we want to strip down the list of boot loaders" IIUC, e.g. blscfg on x86 is only possible with UEFI (it works on powerpc without it in rhel-9, but nobody but IBM wants powerpc anyway). blscfg makes configuring boot loader much easier (that's how I understand it), easier in a "you don't need any grub.cfg at all to boot" way which is appealing from a systems management tool developer's (and product manager's, who has to consider the matrix of options that needs to be supported later) point of view. I guess that in the end there will be some middle way of "the old bootloaders are still available, but you will not get anything of the fancy new features if you want to use them". And that's totally fine with me. As long as syslinux is still available and the kernel installation still creates a /boot/vmlinuz and /boot/initrd, we can always boot using extlinux from an ext3 partition or similar. Right now I'm actually guessing that even grub2-<non-efi> will be available, as the maintenance of the package is unlikely to be the biggest problem, but maybe not supported. Hell, even if the installer then only supports UEFI hardware, we could still create a pretty minimal self-deploying iso image with kiwi which installs a minimal installation onto a selected disc including some non-uefi boot loader and then you install the rest of the full system from there. That would actually be a very nice, (and pretty trivial) small contribution where the openSUSE community could shine ;-)
How about other virtualization than the already mentioned qemu like Virtualbox, or some VMware ESX versions?
They all boot UEFI VMs just fine (I don't know if you can even install windows11 without EFI secureboot, so they certainly need to support that). Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
22.02.2025 12:16, Stefan Seyfried via openSUSE Factory wrote:
IIUC, e.g. blscfg on x86 is only possible with UEFI
That's incorrect as was already mentioned in this very discussion. grub2 does not care where boot entries come from as long as it can read them. ...
The challenge is not to load kernel but to maintain the list of available kernels. You can always set "no bootloader" in YaST Bootloader and install whatever you like; but it also stops refreshing your bootloader configuration on kernel installation/removal.
Hi Andrei, Am 22.02.25 um 14:13 schrieb Andrei Borzenkov:
Ok, but probably not in a simple "no grub.cfg needed at all" configuration as seems to be envisioned for the UEFI case. (I know that it is possible, as it clearly is on RHEL's powerpc installation ;-)
Yes, that's something that's simply not possbile anymore. Or has to be handled by the users on their own. It's no longer $YAST_SUCCESSOR's business. Maybe the linux kernel installation scripts could be amended to not only create "/boot/vmlinuz" symlink but also "vmlinuz.old" or similar, so that a static boot menu still could select the last boot entry. And if we want to go very fancy a static boot loader entry that loads a self-contained, ramdisk-only rescue system that allows to fix up bigger goofups could be developed by the community. Note I'm not advocating the "only UEFI is *supported*" way, but I can understand that for SLES at least, SUSE wants to extend the feature set in a specific way which might be incompatible with non-UEFI boot, so I'm thinking about how to keep the non-UEFI case still available for the community distributions without interfering too much with SUSEs goals. have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
22.02.2025 16:22, Stefan Seyfried via openSUSE Factory wrote:
blscfg defaults to scanning the device defined as $root which by default points to your /boot. It does mean that distribution needs to maintain two locations of the BLS entries depending on the current boot mode (or currently selected bootloader). It also means you cannot share BLS entries between installed instances (which could be considered an advantage :) ) Finally, nothing stops you from using whatever location you like and embedding its discovery in the grub binary. It does mean more maintenance work. But from end-user (end-admin) PoV it eliminates grub.cfg.
With perl-Bootloader converted to the simple plugin based architecture, you can drop your scripts under /usr/lib/bootloader. It will not be manageable by YaST, but should otherwise work. I wish SUSE used installkernel as the single entry point, but it does not.
SLES is to my knowledge used by Enterprises and as base for LEAP. So, may I assume that TW is spared from this idea? If not, then I too disagree. My system is used for video editing and system builds and is still fast enough. It features an AMD Phenom2 965 (x86_64-v1) processor. The system BIOS has no UEFI. Another system has UEFI, but I switched back to BIOS boot due to issues of booting from CD/DVD's. I hope that openSUSE TW does not follow the MS-way of unnecessary forcing users to buy new hardware where the old is still perfectly viable. I don't use Windows anymore and rely(ed) solely on openSUSE for all my past and current systems. Regards, Frans de Boer. On 14/02/2025 13:42, Chuck Payne wrote:
On Fri 14 Feb 2025 02:59:44 PM CST, Frans de Boer wrote:
But considering the improvements and relatively IMHO cheap hardware less than US$200 for a Intel Quad core MiniPC (I use Aeon on it) that has built in hardware encoder/decoder, as well as hardly using any power seems a viable option for you? -- Cheers Malcolm °¿° (Linux Counter #276890) Tumbleweed 20250211 | GNOME Shell 47.4 | 6.13.1-1-default HP Z440 | Xeon E5-2695 V4 X36 @ 2.10GHz | ARC A380 & RTX4000 up 23:14, 3 users, load average: 0.23, 0.28, 0.56
Hello Chuck, On Fri, 2025-02-14 at 07:42 -0500, Chuck Payne wrote:
I don't agree. One of the selling point of openSUSE/SUSE is that it supports a lot of older hardware.
I would argue that Gentoo and Debian have better support for old and exotic hardware. However, openSUSE has very good potential to achieve the same. Thus, I have long been trying to propose an unofficial openSUSE distribution for old and exotic architectures. In Debian, I'm a maintainer for something called Debian Ports which supports a lot of old and exotic targets. I would love to the same for openSUSE and I have already started documenting on how to bootstrap openSUSE from Debian for a new architecture [1] [2]. Adrian
[1] https://people.debian.org/~glaubitz/opensuse-new-target.txt [2] https://people.debian.org/~glaubitz/opensuse-debian-bootstrap.txt
Hello, On 2025-02-14 13:34, Lubos Kocman via openSUSE Factory wrote:
SUSE is evaluating drop of Legacy boot support, please let us know if you foresee any issues.
as far as I noticed (also from SUSE customers) BIOS is still rather often used on virtual machines (regardless that technically they likely could also use UEFI in most of their virtualization environments). I think it is often because in business environments things are usually not needlessly "simply changed" as long as their well known and long established way works sufficiently well for what they need. On example I have in mind is Linux in offshore wind turbines. I don't know if they actually use virtual machines there but my point here is the basically immutable technical environment in such a wind turbine where the one who has to install and maintain Linux therein may have to take the technical environment "as is" in practice, e.g. because it is a different company who provides the technical environment "ready to use" and only that is certified "as is" or whatever external conditions which make it impossible in practice to change things. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
On Fri, Feb 14, 2025 at 2:54 PM Johannes Meixner <jsmeix@suse.de> wrote:
That's changing. Many of the new features customers meanwhile need are not possible with legacy BIOS, you need UEFI. Which is also true for the main new Leap 16/SLES 16 features (I don't speak about package version updates). They don't work with legacy bios. Regards, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Hello, On 2025-02-14 15:12, Thorsten Kukuk via openSUSE Factory wrote:
This is a different question. The question was not when UEFI is needed. The question was when BIOS support could be still needed.
When this means Leap 16/SLES 16 cannot (reasonably) work without those "main new Leap 16/SLES 16 features" then Leap 16/SLES 16 can no longer support BIOS i.e. when BIOS support would contradict or conflict with basic Leap 16/SLES 16 core functionality. In this case customers who need BIOS support could still use SLES 15 at least until 31 Jul 2031 and even longer with LTSS, cf. https://www.suse.com/de-de/lifecycle/#suse-linux-enterprise-server-15 Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
On 2025-02-14 08:49:59 Johannes Meixner wrote:
However, there are undoubtably small businesses and charities that run openSUSE on old hardware, and according to <https://www.reddit.com/r/openSUSE/comments/8eda8b/can_opensuse_leap_be_considered_an_lts_distro/?rdt=59057> "... we can promise 'at least 3 years' support for Leap 15. I expect it will be more like 'over 4'. It might reach 5." which means that BIOS support needs to be available for quite some time. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.6 - x86_64
Hi Am 14.02.25 um 13:34 schrieb Lubos Kocman via openSUSE Factory:
1) UEFI requires a compatible graphics card. Older cards do not support UEFI's GOP or UGA protocols, so the display will remain dark on boot. The solution is to boot in UEFI's emulated BIOS mode (aka CSM, aka Compatibility Support Module mode) 2) BIOS on VMs is still an important use case. 3) There's x86-64 hardware with BIOS only. Best regards Thomas
Many thanks in advance
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Hi Thomas, Am 14.02.25 um 15:46 schrieb Thomas Zimmermann via openSUSE Factory:
2) BIOS on VMs is still an important use case.
3) There's x86-64 hardware with BIOS only.
also x86_64-v2? I mean, that's "newer than 5 years" or whenever the last cheap intel machine was sold which did not have x86_64-v2, so UEFI should be available on those? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Friday 2025-02-14 15:54, Stefan Seyfried via openSUSE Factory wrote:
I have here a HP ProLiant ML310e Gen8 v2 with a Intel i7-4770. HP being HP... there is so much 80x25 going on in the boot phase this is never a UEFI. But it is even a x86_64-v3! $ ld.so --help ... Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 (supported, searched) x86-64-v2 (supported, searched)
On 14/02/2025 16:11, Jan Engelhardt wrote:
ld.so --help
Dell Precision T3500 here Intel(R) Xeon(R) CPU W3670 @ 3.20GHz Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 x86-64-v2 (supported, searched) And no EFI either. It might be considered old by some, but it is neatly working machine. Cheers F.
Hi Am 14.02.25 um 15:54 schrieb Stefan Seyfried via openSUSE Factory:
According to [1], x86-64-v2 is roughly equivalent to 2008's Nehalem. That's the time frame to look at and I'd not expect many/most systems from back then to support UEFI. Yet a 2008's computer is still fine for today's office tasks. Best regards Thomas [1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Am 14.02.25 um 13:34 schrieb Lubos Kocman via openSUSE Factory:
Ok, first with my (pretty big) Customer/partner hat on (I know this is not your part, but you can forward this directly to AJ ;-): azure gen1 VMs are a thing. They boot without UEFI. And our operations team is stupid enough to do OS upgrades without installing new VMs but by exchanging the VM's block device.
I was a bit concerned about virt scenarios, we should ensure that uefi is the default for new VMs as it seems to be legacy boot now.
Azure Gen1 is bios boot, azure Gen2 is UEFI.
Has anybody considered the upgrade path from 15.x to 16.x? (I have migrated the server in my basement from legacy to UEFI boot without reinstalling end of last year, but it was nothing I would recommend to anyone *and* it included upgrading the root storage device from SATA to NVME and thus the data had to be copied over anyway *and* it was easy to add an additional EFI System Partition to the new drive *and* it is an LVM based installation, which means that the partition numbering etc. is pretty meaningless anyway) On a technical note: I hope it will be implemented in a way so that users not wanting to switch to UEFI can still set something like "LOADER_TYPE=none" in /etc/sysconfig/bootloader and just use something like extlinux to boot their system. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
* On 2/14/25 13:34, Lubos Kocman via openSUSE Factory wrote:
I was a bit concerned about virt scenarios, we should ensure that uefi is the default for new VMs as it seems to be legacy boot now.
This is a pretty big concern, as far as I can tell. Thinking about libvirt and qemu, VMs can not easily be migrated from BIOS to UEFI - at least not with any built-in functionality. You might get away with a highly manual migration, modifying the XML files and making sure that the virtualized system is also converted to UEFI boot (which is a painful process since you'll have to boot some sort of different system first and chroot into the system you want to modify), but that's still a huge stumbling block. Changing the default setting to UEFI will only help for newly installed VMs, and, frankly, just changing the default and then turning off legacy BIOS boot at pretty much the same time is kind of insolent. The other technical issue with - again, libvirt + qemu backed - VMs is that to the best of my knowledge, full VM snapshots are still not supported through libvirt when using UEFI. People employ workarounds using features like btrfs snapshots, but that's really a kludge and requires your backing storage to be a filesystem supporting snapshots, which really is only a small subset of all of them. You'll also have to be careful to snapshot both all the disk images *and* the nvram part. This limitation has existed since the inception of UEFI support in libvirt, but never been lifted. As much as I'd love to see legacy BIOS boot rightfully die, I do believe that support should not be dropped for a very, very long time still. The VM issue is prevalent, especially in a FOSS environment (proprietary environments ironically seem to handle UEFI in VMs better), but UEFI support is also often broken even in bare hardware that is "only" 10 years old (like MSI Z97 boards that have a known bug causing a full system hang in any UEFI shell I've tried once it's supposed to scroll the output because the current screen is full). Mihai
On Fri, 14 Feb 2025 at 13:34, Lubos Kocman via openSUSE Factory < factory@lists.opensuse.org> wrote:
I wonder where exactly would such Legacy boot support be removed from? Is this about the installer(s) not offering the option anymore? grub2 install? grub support in general? initrds? Or something further down in userlevel, systemd, later time bootup? It's difficult to gauge how this would affect me. Not that my personal use of (nowadays Tumbleweed) should much influence your decision making, but I'm happily still running my full production setup, some 40 HP DL servers from Gen5 to Gen10 with around 250 VMs, exclusively with BIOS setup. Mostly because it's what I started with, and never had reason to switch. I'm not using the installers (well, every 5 years maybe), more cloning / rsyncing and adapting existing installs. PXE booting kernel + initrd out of tw repo mirrors. grub booting the hosts (and. standard dracut initrd). And running libvirt/kvm virtual machines with kernel (self-built) on the host (libvirt <kernel> option), no initrds, and unpartitioned root blockdevices (a real simplification). The outlook that I'll need to fit in UEFI partitions into all these systems, and find out how well the UEFI / secure boot support is in these different generations of HP servers, is ... giving be a bit creepy feeling right now :-) best regards Patrick
On 2/14/25 6:34 AM, Lubos Kocman via openSUSE Factory wrote:
There are a LOT of cases where legacy servers quietly do there job running at 1-10% utilization, have no UEFI capability, and have absolutely no reason to be replaced just to be able to boot UEFI. This is about as well thought out as the Windows 11 hardware requirements. Look at it from a COST/BENEFIT analysis. How much does is cost SUSE to retain BIOS boot? How much benefit does SUSE gain by driving customers heavily invested in legacy hardware to some other vendor that will support them? I've always tried to avoid shooting myself in the foot -- if at all possible. If the cost to SUSE to keep legacy boot outweighs the risk of losing those folks, well, then I guess it's "just business", screw 'em... However if the cost to keep legacy boot is minimal, then I'd think twice before pulling the trigger. -- David C. Rankin, J.D.,P.E.
On Sat, Feb 15, 2025 at 12:26 AM David C. Rankin <drankinatty@gmail.com> wrote:
The costs for keeping legacy BIOS support are very high, It's doubling the efford. Currently EFI support is restricted to what legacy BIOS can do. As a result, everything has to be implemented into the bootloader. Look at how fat grub2 is, how many patches it has and what all is not possible with it, which are nobrainers if you use systemd-boot or grub2-BLS, so pure UEFI bootloaders. There are meanwhile many features which are not available with legacy boot. Keeping legacy boot would mean: 1. maintaining two complete different toolsets to set up booting, one for legacy BIOs, one for UEFI. I don't speak here about the bootloaders itself, I'm speaking here about all the scripts and hooks to set up the system correctly. 2. maintaining different bootloaders for the same architecture. 3. everything touching the bootloader or scripts around it need to be able to work with both variants.
We are currently losing more customers because we cannot implement features with the current setup than we would lose with dropping legacy bios. And the requirements for these features are coming from e.g. data protection laws in the EU. So something you have to take seriously and which will affect more and more customers.
However if the cost to keep legacy boot is minimal, then I'd think twice before pulling the trigger.
The costs are high. If it would be for free we wouldn't think about it. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 2/15/25 1:52 PM, Andrei Borzenkov wrote:
Thanks Andrei. Does it lump everything into 1 big menu or have they added support for submenu's like grub ? Does it automatically update for new kernels installed and new snapshots created like grub does ? Can zypper create automatic pre/post snapshots which are automatically added to the boot menu ? Thanks, last time I looked at it all those features were not there yet but it has been a while -- Regards, Joe
On Sat, Feb 15, 2025 at 7:59 PM Joe Salmeri <jmscdba@gmail.com> wrote:
Still one big menu
Does it automatically update for new kernels installed and new snapshots created like grub does ?
grub does not automatically update the menu for new kernels or new snapshots, these are scripts called by the update stack. Same for systemd-boot.
Can zypper create automatic pre/post snapshots which are automatically added to the boot menu ?
zypper creates automatic pre/post snapshots, what does this have to do with systemd-boot? About the boot menu: see above.
Thanks, last time I looked at it all those features were not there yet but it has been a while
These "features" are no features of the bootloader, neither of grub2 nor systemd-boot, but of our update scripts. Somebody just needed to implement BLS support there, and that's already done a long time agol Just install Tumbleweed or MicroOS with systemd-boot as bootloader. Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 2025-02-16 07:32, Thorsten Kukuk via openSUSE Factory wrote:
On Sat, Feb 15, 2025 at 7:59 PM Joe Salmeri <jmscdba@gmail.com> wrote:
For systemd-boot there is PR that can help: https://github.com/systemd/systemd/pull/28084
Hi Thorsten, Am 15.02.25 um 12:24 schrieb Thorsten Kukuk via openSUSE Factory:
is grub2-BLS the thing using /boot/loader/xxxxx config files per kernel? and then just a very short grub.cfg with some variables and "blscfg" or similar? If yes, this is working in RHEL9 perfectly fine on powerpc. Which certainly is not using UEFI :-) Ignore this if grub2-BLS is something different. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 15.02.25 um 22:02 schrieb Neal Gompa:
It is the same thing. The grub2-bls stuff is shared between Fedora and openSUSE.
Ok, so if it is working fine on powerpc, it does not need UEFI ;-) Anyway. I don't care if the installer supports non-EFI systems, as long as I can set LOADER_TYPE=none and just install my own boot loader, be it syslinux or lilo, that's good enough for me. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Sat, Feb 15, 2025 at 09:44:01PM +0100, Stefan Seyfried via openSUSE Factory wrote:
We take a different approach than RHEL by putting all BLS config, along with the kernel and initrd, in the EFI partition (/boot/efi) instead of /boot. Also, grub.cfg is not used at all. It is basically the same layout you would have with systemd-boot, just a different loader can be an option. Thanks,
On Mon, Feb 17, 2025 at 8:46 AM Stefan Seyfried via openSUSE Factory <factory@lists.opensuse.org> wrote:
The company behind POWER does not want to support BLS, so everything stays the same. And since there is currently no technical need for BLS on POWER, this is not a problem. Interesting is that RedHat as part of this company seems to introduce BLS on this architecture... Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Mon, Feb 17, 2025 at 3:29 AM Thorsten Kukuk via openSUSE Factory <factory@lists.opensuse.org> wrote:
This seems strangely false, since IBM introduced BLS support to zipl years ago. On Red Hat/Fedora systems, BLS is used with GRUB, petitboot, and zipl. Petitboot knows how to handle BLS with GRUB on POWER just fine. We even introduced support for these bootloaders using BLS with kiwi. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Feb 17, 2025 at 04:51:55AM -0500, Neal Gompa wrote:
There are several differences, but the main one is that Fedora/Red Hat use /boot for blscfg, whereas we use /boot/efi. As a result, they do not require an additional ESP-like partition on Power for integration. Additionally, Fedora/Red Hat still use /boot/grub2/grub.cfg alongside blscfg, with Linux entries replaced by blscfg commands that retrieve BLS fragments from /boot/loader/entries/. In contrast, our scheme eliminates grub.cfg entirely (as that is a bloat). Moreover, while Fedora/Red Hat store kernel and initrd in /boot, we need to copy them to /boot/efi. Thanks, Michael
On Mon, Feb 17, 2025 at 5:45 AM Michael Chang <mchang@suse.com> wrote:
There are people in Fedora who want to put everything in the ESP, but there are many (including myself) who think it's a terrible idea. The ESP can only get so big before various systems fail to be able to read it, and not all firmwares even handle a FAT32 ESP either. I think you're making a mistake by doing it this way, as now the OS is more vulnerable to host firmware goofiness. Considering /boot as bloat seems silly since we do this specifically to avoid the restrictions of the underlying platform. The grub.cfg file is more of an installation difference. Anaconda generates the config file as part of installation. -- 真実はいつも一つ！/ Always, there's only one truth!
On 2025-02-17 11:28, Neal Gompa wrote:
On Mon, Feb 17, 2025 at 5:45 AM Michael Chang <mchang@suse.com> wrote:
What is everything? We are putting the boot entry, the kernel and the initrd in the ESP. In the future, if we go to the UKI path, we will put them instead. Because how openSUSE snapshots are designed, the kernel and the initrd can be shared between multiple snapshots, and only the boot entry will be different here. This is compatible with multi-kernels and save a lot of space. UEFI can only read FAT32, and moving the kernel and initrd into /boot will force the user to use only grub2-bls (and that is fine), but with the current design they can use systemd-boot and grub2-bls as a drop-in replacement. Maybe this restriction is too much to pay for just selecting between different boot loaders, but it simplify a lot later, when more interesting features for the user like FDE or automatic boot assessment are enabled. I know that some developers experimented with UEFI file systems drivers, but AFAIK those approach are yet very brittle and limited. I guess this can be revisited later, or we can invest time on improving the situation.
Hi, Am Montag, 17. Februar 2025, 13:08:06 Mitteleuropäische Normalzeit schrieb aplanas:
It could also use a separate partition with FAT32 for storing those, which is natively supported by BLS, see XBOOTLDR on https://uapi-group.org/specifications/specs/boot_loader_specification/. That way only the bootloader itself has to reside on the ESP. Cheers, Fabian
On Mon, Feb 17, 2025 at 7:08 AM aplanas <aplanas@suse.de> wrote:
There's an ext2/3/4 FSD in the EDK2 tree, and there's a Btrfs FSD developed by the guy who made Btrfs for Windows. Both are used with other UEFI boot managers (rEFInd and Quibble, among others), so I don't think it's a bad path to go. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Feb 17, 2025 at 07:53:16AM -0500, Neal Gompa wrote:
Nonetheless, not all EFI can make use of these drivers. Do they work on Arm, RicsV, loongarch? Under EDK2? Under u-boot? Also does this support LVM, software raid, encryption? Going down this path is basically change for the sake of change, without reaping the benefits: making the bootloader trivial, avoiding maintenanace of two separate stacks of fs/md drivers, avoiding boot environment limitations that prevent use of some encryption schemes, avoiding lock-in to a specific bootloader. Thanks Michal
On 2/15/25 5:24 AM, Thorsten Kukuk wrote:
That makes it pretty clear. If the maintenance costs are as high as you indicate and it prevents implementing needed features, then I think you have your answer. Before raising the axe, it may be helpful to see what other distros are doing. This is the first I've heard about the high cost of maintaining BIOS boot. I say that because I also run Arch, Debian, and Ubuntu. All provide BIOS and UEFI boot and I've not seen threads about needed to drop BIOS boot elsewhere. While this list is a good place to get a feel for the issue, you really need to survey your paying customer base. That's where the rubber meets the road. I'd also look at the old (albeit hated) Demming TQM approach to continue providing BIOS boot if possible. Find ways to reduce cost and complexity for the near term until you have a clear picture on how badly it will impact the paying customers. I wish you the best in your effort, change is hard, but reverting a bad change is often harder. -- David C. Rankin, J.D.,P.E.
On Sun, Feb 16, 2025 at 3:14 AM David C. Rankin <drankinatty@gmail.com> wrote:
Nobody is currently dropping legacy BIOS boot. It's been discussed a few times, though. Fedora has discussed it at least twice[1][2]. The second time led to dropping syslinux[3] and using GPT for BIOS systems[4], and eventually GPT for all architectures[5]. An idea that's come up a couple of times is providing a way to emulate UEFI on legacy BIOS, using either DUET from EDK2 or U-Boot. Nothing has been done on that front either. [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [3]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [4]: https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault [5]: https://fedoraproject.org/wiki/Changes/Anaconda_Installer_Using_GPT_on_all_a... -- 真実はいつも一つ！/ Always, there's only one truth!
On 2/14/25 9:06 PM, JS via openSUSE Factory wrote:
And, everything from Intel Nehalem (2008) and AMD Bulldozer (2011) will run x86_64-v2. There are a lot of BIOS only systems (or early buggy UEFI boards) that fit that category. I still think dropping BIOS boot now would be shooting yourself in the foot. Look at SUSE-2030 and then natural attrition will have taken a majority of systems. You can then go to UEFI and x86_64-v3 at the same point in time. -- David C. Rankin, J.D.,P.E.
Fri, 14 Feb 2025 13:34:03 +0100 Lubos Kocman via openSUSE Factory <factory@lists.opensuse.org>:
SUSE is evaluating drop of Legacy boot support
There are zero technically details in the provided URL about what steps are required to achieve this. Apparently it is more than "disable build of i386-pc in grub2.spec". This would give some estimate about what the burden if keeping BIOS actually is. Olaf
Hello all, Lubos Kocman wrote:
so there still seems to be hardware supporting x86_64-v2 but not UEFI (mostly broken UEFI). For SUSE this is no problem, since they still have the SLE 15 branch for some years. But openSUSE Leap does not! We switch Leap base to SLE16. If both plans (dropping BIOS support in SLE16 AND only using SLE16 as base for LEAP) ar carried out, those Leap users would have to switch to Tumbleweed or look for a new distro. The same was already done with 32bit Hardware longer time ago. And the same is already decided with the switch to x86_64-v2 only in SLE/Leap 16. Now the question is: Does our community have enough interested contributors to support BIOS boot on Leap 16. Yes, there still is a SLE15, where one can look, but how fast will things change until 15 and 16 are too different. On the other hand: How many users and contributors with old hardware will be lost, when they have to look for a different distro.
I was a bit concerned about virt scenarios, we should ensure that uefi is the default for new VMs as it seems to be legacy boot now.
Personally I am really interested in UEFI for new VMs. But converting existing VMs from BIOS to UEFI is not a no-brainer. E.g, one of four Windows 10 VMs was reproducibly broken after conversion from MBT to GPT, I still don't know why. I did not try to convert Leap VMs to UEFI. Are there recipes for that?
Regards, Andreas
On 2/14/25 11:04 PM, Lubos Kocman via openSUSE Factory wrote:
The only concern I have is often the process if you have to install the nvidia kernel drivers the hard way is much simpler if you switch to legacy bios and don't need to worry about signing keys etc. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2/17/25 9:39 PM, Andrei Borzenkov wrote:
Probably nothing, but I'm lazy and just having legacy set in the bios didn't require me learning anything new. I think at one point it was also the suggested way when doing nvidia manually. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 14.02.25 13:34, Lubos Kocman via openSUSE Factory wrote:
AFAIK, the HP ProLiant MicroServer Gen8 servers are affected. They have x86_64-v2: $ /lib64/ld-linux-x86-64.so.2 --help [...] x86-64-v4 x86-64-v3 x86-64-v2 (supported, searched) But the HP MicroServer Gen8 servers have no UEFI boot. See https://community.hpe.com/t5/proliant-servers-netservers/microserver-gen8-ue... Björn
participants (34)
-
Aleksey Kontsevich -
Ancor Gonzalez Sosa -
Andreas Vetter -
Andrei Borzenkov -
aplanas -
Bernhard M. Wiedemann -
Bernhard Völker -
Bjoern Voigt -
Carlos E. R. -
Chuck Payne -
David C. Rankin -
Fabian Vogt -
Frans de Boer -
Fridrich Strba -
J Leslie Turriff -
Jan Engelhardt -
Joe Salmeri -
Johannes Meixner -
John Paul Adrian Glaubitz -
JS -
Lubos Kocman -
Malcolm -
mh＠mike.franken.de -
Michael Chang -
Michal Suchánek -
Mihai Moldovan -
Neal Gompa -
Olaf Hering -
Patrick Schaaf -
Simon Lees -
Stefan Seyfried -
Terje J. Hanssen -
Thomas Zimmermann -
Thorsten Kukuk