Why not EFI mode? Your own computer should work OK in EFI and ‘legacy/BIOS’ might not be perfectly specified so the installer will need guessing. (U)EFI is a proper standard.
So it might be that not using EFI is a cause things fail. I know Tumbleweed, if upgraded for many years has issues with grub2 v.s. grub2-efi, saw it this week again. It has ‘i386-pc’ and ‘x86_64-efi’ and AFAIR there is interpackage dependency so you can’t remove only ‘i386-pc’ variant, while that works in Debian (Trixie or later). So maybe that is a reason TW works and Debian not, as ‘legacy/BIOS’ will need ‘i386-pc’ it seems.
And all the installations I carry out are in legacy mode (EFI disabled in my BIOS).
I agree with luse4x4, on more recent hardware this is not a good idea, and I can’t see the benefit. 15 years ago, UEFI implementations could be very buggy, these days it’s the other way around.
My bet is that many of your install issues would go away in EFI mode…
Yes also my experience. I just dusted off and old AMD E-350 based computer/motherbaord. Nice fanless, 4x SATA connectors, so once (and still) great for HDD’s and backup-NAS or so. But the EFI mode is just totally unreliable, I already put in a new/good BIOS/RTC backup battery, but it doesn’t change things. It simply forgets boot entries and various other issues. So basically I need to manually construct/copy a /EFI/BOOT/BOOTX64.EFI file, then it sort of works, if there is no SATA detection timeout, that is another problem.
In legacy/BIOS mode it more reliability reads just the first sector(s) of the HDD or SSD, that is only very simple firmware code, no FAT filesystem driver etc. i386-pc grub supports putting its binary code there, so that is all modern/proper open source code and also supports GPT, which of course also checks last sectors of HDD etc (2nd backup table). And this is only just boot process, plenty of things can go wrong after that.
EFI supports slow but basic display framebuffer methods, I do not know details, but openSUSE Tumbleweed should/does use that, so at least if such basic driver is kept all the way permanently, it works. I know this is also the method to get Tumbleweed running on ARM SBC’s with rather fast Mali GPU for example, but no good/widespread drivers yet.
The other option is to install via a serial console (is basic text mode), but many PC’s do not even have COM ports anymore, so you always need the display/framebuffer hardware.
For BIOS, I just remember writing hacks and fast code for putting graphics directly ‘on the screen’, is long time ago, all depending on which videocard/GPU it was, nothing standard. Only standard was x86, well, if you did not own a Via CPU or other clone.
Hum, curious : before install of Tumbleweed, i have selected “other OS” instead of UEFI Windows" + F10.
So, i have no EFI partition.
For the install of Ubuntu and Linux mint, i have not checked this point.
These 2 installs are working without UEFI partition.
After reading your message, I went back into the BIOS to see if the status had changed and yes !
It is returned to UEFI Windows without any action on my part.
I know this choice, but don’t remember anymore what it does or its effect. Might also depend on brand of BIOS. I actually don’t understand, UEFI is not 1-to-1 related to Windows. But maybe it is then just UEFI or Legacy.
Anyway, if no EFI partition and it is just a Linux only computer, so no dual-boot Windows, one can create it afterwards without re-installation. That is what I have done several times, but can be very tricky the BIOS might be flipping between UEFI and Legacy depending on what is found on the HDD/SSD. And if ‘compatibility mode’, you allow that. Not sure if your setting are like that. I would nowadays pick strict mode, so only UEFI, else a BIOS/firmware might look in first sectors of HDD/SSD and if still old bootcode there, flip to Legacy again.
For libvirt hypervisor (standard in al distros) version 10.x it is just old PC-BIOS of some sort or Tianocore EDK2. So no guessing or flipping, just what the VM is defined. That choice is there for x86, for aarch64 it is only UEFI.
If you do new install, so format HDD/SSD and the installer is booted in UEFI mode already, it will create EFI System Partition (ESP) automatically. Nowadays 1GB sized, so also OK for systemd-boot.
As I suggested in other message, one can convert from Legacy to UEFI. So if you want a handful of distros on 1 SSD/HDD, and it is currently just 1 in Legacy BIOS mode, you need to shrink that rootfs partition, and add ESP and construct a generic bootx64.efi loader and put that on the ESP. Can be very tricky, I have done that by copying files etc from a properly booting UEFI VM, so kernel+initrd+grub files. For sure you first need to disable Secure Boot. And zero the bootsector and use gdisk to put a new protective MBR there.
It might be easier to let it handle by the Tumbleweed live or rescue USB-stick. If you want to do it on the running system itself, you need Btrfs as rootfs as that allows live shrinking, is very powerful and great if the computer is for example a NAS that must run 24/7 (only quick reboot for new kernel).
@opsusemaco Hi, that is not actually true, on a GPT disk you create a 2MB PMBR partition to support legacy boot, so in theory a EFI partition will also be fine…
My NAS (which I purchased in 2010) knows nothing about UEFI. Nevertheless it boots (using GRUB2) openSUSE Tumbleweed quite happy from a GPT-partitioned NVMe via USB2.0.
It certainly does not. e.g., my 2008 Biostar does not support EFI, while its only storage device is formatted GPT. Doing so does require a tiny BIOS boot partition for a bootloader.
You can use GPT partitioning with BIOS mode. And it is actually possible to use UEFI with MBR partitioning, provided that the EFI partition is a primary partition and not a logical drive.
That your display doesn’t support higher resolutions doesn’t directly equate to no use to you. HDMI was originally designed for HDTV, not computers. DisplayPort was designed for computers, which means functionality that HDMI cannot provide, as well as performance not measured by display resolution. e.g., DP provides Multi Stream Transport , which enables up to 9 monitors to be daisy chained from a single DP output, and is the basis for typical laptop docking stations with multiple video outputs.