Thank You Polaris96, for understanding that my counterpoint was by no means a flame to any person here, just a complaint about industry implementation.... nor did it come from ignorance of the specs as Didier would dismiss my opinion, which would have been a bad enough assumption, but to add in "hearsay" and "baseless statements" just adds rude, and uncalled for jumping to wild conclusions. Thanks to all else who responded with dignity.

I am disappointed in the gulf between the design imperative specs and the results, at least so far. Some of my disappointment comes from how little it does for me, so far. It's good to see it listed out so succinctly so I can better now see at least how it may benefit some others, but for example I've not had problems with numbers or sizes of partitions. So certainly some of the upside has escaped me at the 1st hand experience level.

Admittedly I have only personally worked on a dozen or so motherboards where UEFI was even a choice, but I do have that experience and I have read a great deal on the subject and only little of that is confined to forum posts. To be as objective as I can possibly be I can't say that I have never responded in a public forum without thoroughly researching the subject, but it has been extremely rare. I don't "paint by numbers" nor learn by rote.

I suppose the bottom line is that it is fairly new and seeks to fix and eventually replace a system that is so old, and has been broken in many ways for so long, that it is going to take a lot of time for revision to cover it all, so I am probably guilty of judging too soon, but then again I was only referring to it's current state and how much it does for or to me, and do far it has been more of the "to" side

Dugan - Just finished reading all 6 pages of your linked thread. Thank you very much. It must be quite timely because that has become a real "break out the crawler and droplight and get tour hands dirty" thread - the best kind

My answer wouldn't have been rude if you had just stated "I had no luck with the implementation of UEFI so far". But that's not at all what you wrote in post #8, or my English is even worst than I think it is.

Furthermore, is is quite understandable that it takes time for firmware and motherboards vendors to provide fully compliant implementations.

Before beginning coding, a firmware developer has to fully read and understand the 2637 pages of the spec, but also acquire a sufficient knowledge of most of the 118 documents referred to in annex Q1.

The first sentence of the spec states:That means that it is as much work for the firmware provider as it is for the OS developer to implement it. In neither case can this be done over night.

I re-read my post, Didier, and I truly do not see anything even remotely offensive to anyone but possibly OS peddlers. How I incurred your condescending wrath is still a mystery to me. It seems as if you want to put some burden of shame on me and it is not my fault that UEFI has yet to please me, but that is no more offensive in my book than saying it is my opinion that Hummers are gas-guzzling behemoths that need stricter regulation for public roads.

Here is an elaborated answer.

I apologize to readers who could be bored by this discussion. At least I will try to make this post useful to someone interested by the topic of this thread.

My sentence: was not intended to you but to people reading this thread in the hope of finding some useful information or more generally learn something. Do you think that your post brings them anything useful? People just could just (wrongly) conclude from it "No UEFI implementation is worthwhile, so better stick to BIOS".

Not basing your statement on any practical example but just generalizing from your (not reported) experience made your post look very much like spreading FUD. That is why I wrote "baseless": you are not providing any evidence. So for people reading it that is "hearsay" and that's why I suggest is that they (not you) acquire some knowledge of the spec instead.

Using such words as as "OS peddlers" (care to name some and tell us why you call them "peddlers"?) or "shameful" (of what?) doesn't help either.

But it is not too late: you are still welcome to provide examples or what went wrong, giving as many details as possible like the Slackware version and edition you tried to install, the MOBO and firmware brands, models and versions, what you did, what issues you encountered, how you solved them. This will certainly help people owning the same hardware/firmware or considering its acquisition.

Somehow, such information could complement the HCL.

Examples of such information are the Broken UEFI Implementation wiki recently set up by Steve McIntyre and announced on his blog.

See also the Problems Starting Tails (similar issues could be encountered trying to boot a Slackware installer) and the Miscellaneous test results under Syslinux[1] also from Tails.

And Arch's UEFI/Hardware wiki page.

That's the lists I am aware of. If anyone knows of others, feel free to post links or pointers.

Cheers,
Didier

PS I don't feel any wrath against you.

[1]Tails use mainly Syslinux 6.03 to boot on UEFI firmware but similar issues could be encountered with other boot loaders.

enorbet i kind of agree with didier in regard to your original comment. I don't doubt you meant well and it's obvious that you're a well informed person, but I read, "os-peddlers..." and immediately thought, "oh boy, here we go, it'll be gnu uber alles and take a stand together before the military industrial complex takes our souls MMAAAANNNNNN..."

I was wrong and I apologize for reading your comments in that light, but it was kind of hard not to.

thank you gentlemen, both, for your insight.

addressing an entirely different (informational, thankfully) comment. This is subjective because I've only worked on one platform (and have no intentions of becoming a UEFI guru any more than the job requires).

I have read the Broken UEFI implementation wiki that didier mentions. I actually own some of the referenced hardware (Gigabyte Dual UEFI BIOS). Again, subjective with a test population of one unit, but it worked well for me once I realized what the issue actually was. Not a UEFI problem at all.

I did have issue with IOMMU being disabled and I wonder if many of the "broken UEFI" complaints arise from this (weird) factory setting.

The people at debian are driving that wiki and they've always been great about helping the bigger community. Definitely a site worth looking over.

The only issue I have with BIOS based systems is the fact that Microsoft refuses to support BIOS+GPT booting.

GPT has been in usage on BIOS systems for a good amount of time, even before UEFI was the craze. GPT fixed everything that MBR was lagging behind in. UEFI on the other hand really fixed nothing BIOS already did, still does, and does well minus a slightly useful added security layer. Everyone says GPT boot over BIOS is a hack, well yes it is, but so is any computer code. GPT+BIOS works, works well, and I've really never ran into a system that couldn't boot using GPT partitioning with the proper configuration.

It is so easy to misunderstand even in person let alone with just text on a page absent physical cues. I had just wanted to find out if someone either knew something I didn't or simply had needs different from mine and all it took was one possibly badly chosen word and we were off. Kudos, gentlemen, for displaying civilized adults can and do work misunderstandings out as long as nobody gets overly emotional/defensive.

I'd like to know how can I add a Slackware kernel to the rEFInd menu, booting directly from rEFInd and bypassing ELILO. I tried doing that after reading the docs but all I got was a kernel panic. In my experience, documentation for EFI boot managers (ELILO, rEFInd, GRUB2) is either absent or abstruse.

I my case none of my motherboards are UEFI (yet). This computer has two 1TB hard drives. One (Sector size (logical/physical): 512B/512B) uses MBR. The other (recently replaced) uses GPT out of necessity. The new hard drive has a sector size (logical/physical): 512B/4096B and MBR does not work on these hard drives. So I am using BIOS+MBR+GPT.

There is no misconception. The difference between BIOS+MBR vs UEFI+GPT is helpful to keep in mind when trying to get around/do something with secure boot or setting up UEFI. Maybe better to think of it as BIOS/MBR/lilo vs UEFI/GPT/elilo. That GPT can be mixed in with BIOS/MBR/lilo (outwith UEFI) is actually not relevant for running a system until it comes to solving secure boot issues. But not the other way round: UEFI only works with GPT/elilo.

I would have to disagree, the context of my comment was that the OP's two first joyful things about UEFI, was actually things about GPT. My point was that to get the benefits of GPT, one does not necessarily need to jump ship from BIOS to UEFI. For anyone who wants to use a new fancy large hard drive with an older non-EFI mb, being able to mix GPT and BIOS is certainly relevant, even before dealing with secure boot.

I'm now intrigued about the possibility of making a slackware-current USB installer that boots with rEFIND...

I'll try to do that and let you know when it's available, hopefully later today.

I have no Mac but as long as you are eager to test...

PS But I will first make some preliminary tests on my Thinkpad that has an UEFI firmware.