<div dir="ltr">I find myself agreeing with Liam here, both regarding the problems with UEFI and also the inability to avoid it if we want to use current hardware.<div><br></div><div>And I want to use current hardware. </div><div><br></div><div>Just this morning I was digging through examples of how to make bootable GPT UEFI FAT partitions. Linux has all the tools you need. Next step: finish a port of the PO2013 ORG.Mod to generate x86_64 opcodes instead of RISC5 ones... (stretch goal, do the same for aarch64)</div><div><br></div><div>Cheers,</div><div>Chuck</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 24, 2020 at 8:22 AM Liam Proven <<a href="mailto:lproven@gmail.com" target="_blank">lproven@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 24 Nov 2020 at 16:47, Paul Reed <<a href="mailto:paulreed@paddedcell.com" target="_blank">paulreed@paddedcell.com</a>> wrote:<br>
><br>
> Hi Liam,<br>
><br>
> Do you mean UEFI, or Secure Boot? I'm interested (and in raising the<br>
> tone a bit). ;-)<br>
<br>
:-)<br>
<br>
I really do mean UEFI. Even with Secure Boot off, which is broadly<br>
necessary for any FOSS OS without a large budget behind it (to pay for<br>
signing of bootloader binaries).<br>
<br>
There seems to be, from my own experience so far, 3 or 4 types of UEFI<br>
system in practice:<br>
<br>
[1] UEFI systems where you can pick an option to work in legacy BIOS<br>
emulation, and then all the UEFI stuff disappears and it just looks<br>
and acts like a BIOS. Example: my Thinkpad X220 & T420 even on the<br>
latest firmware. You can enter the firmware with whatever the<br>
manufacturer's normal hot-key combination is, etc.<br>
<br>
[2] UEFI systems which will look for legacy BIOS boot structures on<br>
the boot medium, load from them in BIOS mode and from then look like a<br>
BIOS machine. However, this is dynamic and if booted from a UEFI<br>
medium with an EFI System Partition etc., they act like pure UEFI<br>
machines. Examples: I have seen some fairly recent (Xeon) desktop<br>
Dells from the last 3-5 years like this.<br>
<br>
[3] UEFI systems which offer a choice: for instance, when you enter<br>
the "select a boot medium" menu, and they detect a bootable USB , then<br>
you get 2 boot options for that medium: "legacy boot" or "BIOS boot"<br>
or words to that effect, or "UEFI boot". Depending on which you pick,<br>
the *same boot medium* will perceive itself to be starting on a BIOS<br>
system or on a UEFI system. If you know the difference, these are<br>
easy, but it's easy to get it wrong and enter a config where you can't<br>
install a bootable system, or your booted system can't see or<br>
manipulate the boot structures of an installed system of the _other_<br>
type.<br>
<br>
Examples: I have seen modern 2019-model Dell Precision mobile<br>
workstations like this; my girlfriend's Lenovo Core i5 desktop (about<br>
a 2017-2018 machine).<br>
<br>
Interestingly, I was only able to get my partner's machine to boot<br>
Linux Mint 19.2 or 19.3 from its HD by pressing F12 to pick  a boot<br>
medium; then the GRUB menu appears. Normally, it boots direct to<br>
Win10, whatever settings are in the firmware. (This is based on Ubuntu<br>
18.04, as mainstream as Linux gets). Upgrading the firmware made no<br>
difference.<br>
<br>
Interestingly, this summer, when I upgraded to Mint 20 (based on<br>
Ubuntu 20.04-1), suddenly the EFI GRUB menu started working without<br>
F12. Someone somewhere has fixed something and now it works. Who knows<br>
who or what? All part of the fun of UEFI.<br>
<br>
[4] UEFI systems which are pure UEFI and will only boot from a<br>
correct-configured UEFI medium. Some may _say_ that there is a legacy<br>
boot option but it won't work. Example: my current work desktop, a<br>
Dell Precision Core i7 minitower. I inherited this from a colleague<br>
who quit. He spent days trying to get it to boot. Later, I tried to<br>
help. When he left, I asked for and got the machine, and I spent a<br>
week or so on it. I tried about 6-7 Linux distros, stable and<br>
cutting-edge versions, booted from USB or DVD or network. Nothing<br>
worked. I could not get a Linux distro to boot from the hard disk. In<br>
the end, in desperation, I put the latest Win10 on it, which worked<br>
perfectly. With the boot structures created by Win10, Linux will<br>
dual-boot perfectly happily and totally reliably.<br>
<br>
I have received a lot of abuse from "experts" who tell me that what<br>
I've seen is impossible, not true, etc. Especially from enterprise<br>
Linux vendors, who just get their bootloader signed and therefore see<br>
no problem with this. This is a theme -- I've been in the business 32<br>
years now and I've had that a lot. One exception disproves a million<br>
people for whom something works perfectly.<br>
<br>
IMHO, UEFI is inadequately-specified, as of yet poorly-debugged, and<br>
is not yet really ready for prime time. It works with single-boot<br>
Windows systems, although it is hard to do things like change boot<br>
settings, and it's relatively easy to get an unbootable system if you,<br>
for instance, copy a working HDD install onto an SSD. Fixing this is a<br>
lot of work and the automated tools in Win10 don't work, which<br>
indicates to me that Microsoft don't fully understand this either.<br>
There is no longer any consistent way to get into the firmware setup<br>
program, into Windows' Safe Mode etc. Many systems intentionally<br>
conceal all this to make a smoother customer experience. You need to<br>
do things like set options in a Windows control panel to display the<br>
startup options when the system is next booted. If you can't load<br>
Windows, tough. If you can but it fails to complete boot, tough. If<br>
you don't have a Windows system, tough. I regard this as broken, badly<br>
broken; the industry apparently does not.<br>
<br>
It is important to note, not as paranoia but as a simple statement of<br>
fact, that enterprise OS vendors focus  on servers, and servers<br>
typically do not dual-boot, at all, ever. Most, in fact, run inside<br>
dedicated VMs, so they don't even interact with other OSes at all.<br>
Therefore all this stuff is poorly-debugged and little-tested.<br>
<br>
It is also significant, I think, in paranoid mode, that while<br>
Microsoft _says_ it loves Linux and FOSS now, this is marketing guff.<br>
No significant parts of Windows have been made FOSS. Windows will not<br>
dual-boot with any FOSS OS; in fact it disables other bootloaders. It<br>
is entirely the FOSS OS's job. Windows can't mount, read, or write<br>
Linux filesystems, or even identify them. MS only likes Linux if it's<br>
running  safely inside a Windows VM.<br>
<br>
This, for me, falsifies the claim that MS <3 FOSS. They talk the talk<br>
but do not walk the walk. It is their old embrace and extend tactic<br>
once again.<br>
<br>
As such, the fact that UEFI works so badly with non-MS OSes seems<br>
likely to be quite intentional to me, and that it only cooperates with<br>
big enterprise server OS vendors. The situation is difficult for small<br>
FOSS players and not materially improving.<br>
<br>
> If contemporary UEFI is not a reasonable target for any 3rd-party<br>
> operating systems, such as Oberon, then of course we should know sooner<br>
> rather than later, and not waste our time (or money) with such hardware<br>
> anymore - since there are, as you say, plenty of choices these days.<br>
<br>
I hesitate to make any blanket statements.<br>
<br>
The Oberon community needs to try to ensure that Native Oberon and/or<br>
A2 continue to work on vanilla PC hardware. Insisting on obsolete<br>
tech, e.g. insisting on a BIOS machine, is not a viable strategy.<br>
Requesting at least working legacy boot and supporting a legacy boot<br>
structure on the HDD, as a temporary minimum, is doable.<br>
<br>
However, hard disks of over 2TB are now cheap commodity kit. Such<br>
drives mandate GPT partitioning. GPT is poorly supported on legacy<br>
BIOSes and really is designed to work with UEFI. So the work of<br>
providing a UEFI bootloader for Oberon or A2, even if it requires<br>
Secure Boot to be disabled, is probably inevitable.<br>
<br>
-- <br>
Liam Proven – Profile: <a href="https://about.me/liamproven" rel="noreferrer" target="_blank">https://about.me/liamproven</a><br>
Email: <a href="mailto:lproven@cix.co.uk" target="_blank">lproven@cix.co.uk</a> – gMail/gTalk/gHangouts: <a href="mailto:lproven@gmail.com" target="_blank">lproven@gmail.com</a><br>
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven<br>
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>