[Oberon] UEFI

Tue Nov 24 17:47:25 CET 2020

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.

And I want to use current hardware.

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)

Cheers,
Chuck

On Tue, Nov 24, 2020 at 8:22 AM Liam Proven <lproven at gmail.com> wrote:

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