Debian on Bios legacy : better update to UEFI ?

[AngeloU]

I have replaced my old Desktop with new mini Pc (Intel inside, i5).

Surprised to receive a computer with inside installed an old version of Windows ( soon updated to Windows 10).
Firmware is on ''legacy''.

Apart from all technical questions (how to change Bios legacy to UEFI), I would be glad to know different viewpoints.
(Is it sensible,recommended, to change Bios into UEFI or remain with old Legacy (which seems very obsolete) ?

My aim is to install Debian alongside Windows (dual Boot).

Thanks everybody .

[CwF]

It doesn't matter.
KISS

[MagicPoulp]

https://wiki.manjaro.org/index.php/Some ... S_v/s_UEFI

UEFI can in theory boot faster. It manages better large disks with partitions above 2TB.

I would recommend UEFI. But if you do not want to lose time, it does not matter that much.

Double boots:

If what you plan is to have a double boot, you need to know that preserving an existing windows license is delicate. Because if you erase the disc to reinstall, you lose the windows license key.

Since I know how to install debian on a usb SSD disk, I think it is much superior to the double boot windows/debian. It is not trivial to install. I had difficulties to make sure UEFI is used and not MBR, I had to use the advanced installer, then run in rescue mode to add the removable grub option. THen install firmware and kernel from backports in rescue mode. Then it worked fine.

Windows has lots of extra stuff in the boot now with pin codes, and auto changes of the boot sequence. Double boot is not an exact science any more. So if you buy a fresh computer and it has windows, it is not worth the time risking to lose it.
I once had to run bdcedit on windows in the MSDOS shell to change the boot to linux grub so that it stops overiding my grub boot. But it is a time sink and very undocumented.

And honestly, any windows version is fine as long as it is still in support.

[Head_on_a_Stick]

UEFI can in theory boot faster.

[citation needed]

It manages better large disks with partitions above 2TB.

The 2TiB limitation applies to MS-DOS partition tables rather than non-UEFI booting. Some non-UEFI systems can boot from a GUID partition table (I have a ThinkPad X201 that can) and the 2TiB limit would not apply to those. Conversely, booting a UEFI system from an MS-DOS partition table is part of the official UEFI specification — even if some broken implementations will not allow it — and for those UEFI systems the 2TiB would apply.

Windows will install a non-UEFI system if the disk has an MS-DOS partition table, which would appear to be the case for the OP, but Windows has specific tools which can convert MS-DOS to GUID partition tables: https://docs.microsoft.com/en-us/window ... a-gpt-disk

preserving an existing windows license is delicate. Because if you erase the disc to reinstall, you lose the windows license key

Not necessarily. My ThinkPad E485 stores the Windows key in the firmware and so Windows is automatically verified if it is installed again after wiping the original system.

I once had to run bdcedit on windows in the MSDOS shell to change the boot to linux grub so that it stops overiding my grub boot. But it is a time sink and very undocumented.

https://wiki.archlinux.org/index.php/Un ... boot_order

[MagicPoulp]

UEFI can in theory boot faster.

[citation needed]

https://wiki.manjaro.org/index.php/Some ... S_v/s_UEFI

Code: Select all

"UEFI may be faster than the BIOS. Various tweaks and optimizations in the UEFI may help your system boot more quickly it could before. For example: With UEFI you may not have to endure messages asking you to set up hardware functions (such as a RAID controller) unless your immediate input is required; and UEFI can choose to initialize only certain components. The degree to which a boot is sped up will depend on your system configuration and hardware, so you may see a significant or a minor speed increase. "

[PsySc0rpi0n]

I did this a few weeks ago.
I just want to say that I had a hard time to be able to get this working. In my case, I have a Clevo P170EM from aroun 2012. The BIOS menu is not very clear and I tried to install Debian in UEFI mode. UEFI firmware was stubborn and wasn't detecting my new SSD (Samsung Evo 860). After many hours trying different things, and sometimes just repeating the process, I decided to do something I have never did in the past. So, it was a completely new ground to me. Chroot into the current installed system and try to figure out how to make the boot work.
For some reason, the grub wasn't installed correctly and the UEFI firmware wasn't in the correct place. Finally I made it work

Not sure if the reason for all these problems is a poorly built-in UEFI firmware or if it was just me being noob but the fact is that I spent like over a week going round and round and failing at making my laptop booting properly with UEFI boot.

[p.H]

Is it sensible,recommended, to change Bios into UEFI or remain with old Legacy (which seems very obsolete) ?
My aim is to install Debian alongside Windows (dual Boot).

It depends on your needs. Dual boot with Windows adds constraints. I'll assume Debian and Windows will be installed on the same drive.

Unlike GNU/Linux, Windows boot mode is tightly bound to the system drive partition scheme :
- UEFI boot requires GPT partition scheme
- BIOS/legacy boot requires DOS/MBR partition scheme

So if you want GPT on the system drive, you must switch to UEFI boot before installing Debian. You can either reinstall Windows in UEFI mode or convert the system drive to GPT with MBR2GPT.EXE.

In BIOS/legacy boot mode, only one boot loader (GRUB or Windows) ca be installed in the boot drive MBR. Usually Debian is installed after Windows so that GRUB takes control of the boot process and manages dual boot. But Windows updates may overwrite GRUB's boot sector.

In UEFI boot mode, each OS has its own main boot loader in a separate subdirectory within an EFI system partition and registers it in the EFI boot variables (stored in the motherboard non volatile memory). They cannot overwrite each other, but they can mess with EFI boot variables, either changing the boot order or deleting EFI boot entries. An OS may also install a fallback boot loader in a special location of the EFI system partition (called "removable device path"), which does not need a registered boot entry and can be used when all boot entries failed. That may be useful with broken UEFI firmwares which do not handle EFI boot entries properly. Windows does so, and Debian can do it optionally when doing an expert install. But there is only one such location in an EFI system partition and it may be overwritten during an OS update, like the MBR for BIOS boot. A workaround to this is to create a separate EFI system partition for each OS.

Note that you can install Debian and Windows in different boot modes. You will lose the dual-boot capability in GRUB and have to select the OS by selecting the boot mode in the BIOS/UEFI boot menu, but on the other hand it should avoid interference between boot loaders.

The 2TiB limitation applies to MS-DOS partition tables

With 512-byte logical sectors. With 4096-byte logical sectors (4Kn native Advanced Format), the limit is raised to 16 TiB.

Some non-UEFI systems can boot from a GUID partition table (I have a ThinkPad X201 that can)

I have yet to find a non-UEFI machine which cannot boot from GPT. The only required trick with some broken BIOS firmwares was to set the boot flag in the protective MBR.

Windows will install a non-UEFI system if the disk has an MS-DOS partition table

In my experience (limited to Windows 7), it was the other way around : the Windows installer required a DOS partition table if it was booted in legacy mode, and a GPT partition table if it was booted in UEFI mode. Did that change in later versions ?

https://docs.microsoft.com/en-us/window ... a-gpt-disk

I'll just quote the first sentences :

Master Boot Record (MBR) disks use the standard BIOS partition table. GUID Partition Table (GPT) disks use Unified Extensible Firmware Interface (UEFI). One advantage of GPT disks is that you can have more than four partitions on each disk.

Wow. Three sentences, three mistakes. Is this really official Microsoft documentation ?

[Head_on_a_Stick]

Windows will install a non-UEFI system if the disk has an MS-DOS partition table

In my experience (limited to Windows 7), it was the other way around : the Windows installer required a DOS partition table if it was booted in legacy mode, and a GPT partition table if it was booted in UEFI mode. Did that change in later versions ?

I must admit that I don't have a huge amount of experience with installing Windows but yes, a UEFI Windows system requires a GUID partition table and a non-UEFI Windows system requires an MS-DOS partition table. I really don't know whether a pre-existing partition table on the disk will force the installation mode though — that was a presumption on my part.

Wow. Three sentences, three mistakes. Is this really official Microsoft documentation ?

Lol. Yes, it is. Bunch of idiots

[p.H]

I really don't know whether a pre-existing partition table on the disk will force the installation mode

Windows 7 refused to start the installation if the partition table was not the required type.

[AngeloU]

Interesting discussion.

What about virus, and malware ?

Is UEFI safest than old Bios legacy ?

(Secure booting is intended as : " no cracked Windows operating system allowed " ? )

[Head_on_a_Stick]

Is UEFI safest than old Bios legacy ?

UEFI firmware almost certainly introduces more vulnerabilities thanks to it's increased complexity but booting with "Legacy" mode (CSM) enabled will still expose the system to those vulnerabilities because it is emulated in the UEFI firmware.

(Secure booting is intended as : " no cracked Windows operating system allowed " ? )

No, I can get cracked versions of Windows that will boot just fine with Secure Boot enabled.

The Debian developers recognise the benefits of Secure Boot, which is why it is supported in the current stable release. See also https://wiki.debian.org/SecureBoot#What ... re_Boot.3F