Linux 5.7 Git Restores The Ability To EFI Boot Following Fallout In 5.7-rc1

[Space Heater]

So you decide to open up with a slam of the poster. Well why should anyone read further?

I guess the truth hurts. You decided to open up with a ridiculous claim that Linux has no testing, and you've obviously put zero effort into fact-checking beforehand. You are fine with insulting the Linux developers and all of the effort that goes into testing by claiming it doesn't exist, so have a taste of your own medicine.

Since you decided not to post any relevant supporting evidence to support your claim that it impacts SOME systems, not all systems, let's speculate a bit.

Well given it affects Michael's UEFI systems, and not mine, that's proof it impacts some but not all UEFI systems. I don't know how to make this any simpler for you.

Where are the links to the testing platforms and test results used by Linux developers? Buried in a Linux Kernel Mailing List? Perhaps nowhere to be found? Just anecdotal memories from very busy developers?

Why do you refuse to put any effort into researching topics before posting long screeds on phoronix?

A non-exhaustive list of Linux testing:

Kernel Selftests

https://kselftest.wiki.kernel.org/

https://www.kernel.org/doc/html/late...kselftest.html

KUnit - Kernel Unit tests
https://www.kernel.org/doc/html/late...nit/index.html
https://google.github.io/kunit-docs/...y/kernel/docs/

Linaro's Linux Kernel Functional Testing

https://lkft.linaro.org/

https://qa-reports.linaro.org/lkft/

Linux Test Project

https://linux-test-project.github.io/

Intel GFX CI

https://intel-gfx-ci.01.org/

Block Layer testing - blktests
https://github.com/osandov/blktests/...ster/README.md

XFS Tests

https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

Kernel builbot for stable-queue and hwmon

https://kerneltests.org/

Kernel CI

https://kernelci.org/

Linux Kernel Performance tests

https://github.com/intel/lkp-tests

KVM Unit tests
https://git.kernel.org/pub/scm/virt/...unit-tests.git

Simple point: You can claim all the testing you wish, but until the test methods and subsequent results are published for others to study and repeat THOSE RESULTS DO NOT EXIST. That's basic scientific method. To argue it any other way is promoting pure HOAKUM.

I assume you're now going to say that this testing is simply not sufficient. Well like I said before there are efforts to increase and improve testing. The problem with your posts is that they are simply not specific and in-actionable. You're basically saying "do more tests", as if that is some great insight and no one has thought of that.

Circling back to the speculation "some systems and not all" implies that some distributions are messing with the Linux codebase for whatever reason when they compile it.

The kernel I run is compiled on one of my servers, it has *nothing* to do with distributions tweaking kernels. This regression simply doesn't affect all UEFI systems.

Conversely, Linux tries to get all that hardware compatibility handled in the installer process.

No, the linux kernel probes the hardware at every boot to check which modules to load, it's not determined only once at install time. Again, do research before trying to come across as an expert.

[NotMine999]

Also testing such feature in baremetal hardware, without mocking everything, is complicated to automate, recover from error without human interaction and so-on.

Is not like just plug something in your CI/CD that will run a docker thing to test it, it is like testing in smartphones without adb or other midleware to help this out

I totally agree that it is a manual effort at this level. Once a boot USB key or boot CD/DVD is created the boot testing should take no more than 5 minutes. It either works or it doesn't.

Then those efforts need to be consistently applied, clearly documented, and widely published, not crowd-sourced across a bazillion blogs & mailing lists that may or may not be reputable.

The person on the street who is not a computer hobbyist and cannot afford IBM-Redhat, Oracle, or whatever support wants easy-to-access info so they can make better, more informed decisions regarding Linux. Otherwise they'll just stick with Windoze or Apple Mac.

[NotMine999]

You don't know what you're talking about, Linux is tested quite a bit and there are efforts to increase its testing as well. I think it's clear you have not done even a cursory search of this topic.

This issue does not affect all systems running UEFI by the way. I've been running 5.7-rc1 on a desktop (set to UEFI mode) since a few hours after the release was tagged. I've even rebooted several times as well.

So you decide to open up with a slam of the poster. Well why should anyone read further?

Actually I read the Git changes. There are 2 different methods involved here; 1 is now clearly marked "Deprecated" and the other is obviously, if you read the comments, the proper method.

+EFI Handover Protocol (deprecated)

was previously listed in the code as

-EFI Handover Protocol

Since you decided not to post any relevant supporting evidence to support your claim that it impacts SOME systems, not all systems, let's speculate a bit.

Where are the links to the testing platforms and test results used by Linux developers? Buried in a Linux Kernel Mailing List? Perhaps nowhere to be found? Just anecdotal memories from very busy developers? At least Michael shows us his work and we can use his test suite to compare results. Having test evidence readily available for anyone on the Internet to study would be very helpful to people that WANT to improve the quality of Linux so it will gain wider mainstream acceptance by displacing more and more Windozes platforms. Perhaps the Linux distributions maintain their own testing lists? I saw that in the past with Redhat before they forked to Fedora and RHEL; I stopped using Redhat and Fedora at that point.

Simple point: You can claim all the testing you wish, but until the test methods and subsequent results are published for others to study and repeat THOSE RESULTS DO NOT EXIST. That's basic scientific method. To argue it any other way is promoting pure HOAKUM.

Circling back to the speculation "some systems and not all" implies that some distributions are messing with the Linux codebase for whatever reason when they compile it. Distributions might not be following "best practices" or "proper methods" that the Linux developers would want. That's one point of view. The reverse point of view is Linux is not providing clearly written details regarding how code is expected to be implemented by distributions. You have to consider both points since neither has be disproven.

The Git commit referenced in Michael's article suggests to me the earlier method that's now marked "Deprecated" was "loose"; it allowed boot loaders to do things that they are now expected not to do.

+The boot loader MUST respect the kernel's PE/COFF metadata when it comes
+to section alignment, the memory footprint of the executable image beyond
+the size of the file itself, and any other aspect of the PE/COFF header
+that may affect correct operation of the image as a PE/COFF binary in the
+execution context provided by the EFI firmware.

All of the updated comments suggest to me a tightening up of expectations for boot loaders. Maybe this Linux code has evolved as developers have learned things about boot loaders and these changes "caught out something or some distro that was playing fast and loose" with the result being "breakage". In any case, you test, you test, you TEST, and you publish your results where they can be easily found, and not buried in some mailing list. Mainline Linux developers are well-known (just search the LKML archives) for publishing their "test results" in the LKML, but not always providing direct links to their test methods and raw test data. Maybe they assume you can "go find them" or whatever.

Finally, the Windoze case. Have you ever considered why Windoze boots up to silly lo-res specs and then you have to find/load drivers? The lo-res apporach just works on an extremely broad range of hardware. Then Windoze can start their in-depth hardware probing and Internet searching for drivers. When is the last time someone said they could not get a fresh install of Windoze to boot? It's extremely rare nowadays; the target hardware is either "broken" or doing stuff Windoze can't figure out. Conversely, Linux tries to get all that hardware compatibility handled in the installer process. Sometimes the Linux installer screws up (had that happen with Beta code) and sometimes the hardware is just plain quirky (had that happen with 3rd party video hardware, not Intel, AMD, or Nvidia HW). I think a better setup process for Linux is needed, like "basic setup first" then "in-depth hardware probing" so you can work in hi-res afterward. The alternative is a bloated and complex installer, but we have more and more distributions opting for DVD or USB as the minimum install media, so maybe size no longer matters?

[andrei_me]

Also testing such feature in baremetal hardware, without mocking everything, is complicated to automate, recover from error without human interaction and so-on.

Is not like just plug something in your CI/CD that will run a docker thing to test it, it is like testing in smartphones without adb or other midleware to help this out

[Space Heater]

Regression suggests to me that there is poor or no quality control being done to Linux code, especially critical code.

You don't know what you're talking about, Linux is tested quite a bit and there are efforts to increase its testing as well. I think it's clear you have not done even a cursory search of this topic.

This issue does not affect all systems running UEFI by the way. I've been running 5.7-rc1 on a desktop (set to UEFI mode) since a few hours after the release was tagged. I've even rebooted several times as well.

[archsway]

Regression suggests to me that there is poor or no quality control being done to Linux code, especially critical code.

Perhaps the Linux community should work more intensely on "code quality" ... or is Linux code simply getting to the point that it's too darn complicated and screwups, even avoidable screwups like this one, are inevitable?

Yes, think of all the production servers using an -rc1 kernel that now don't boot because of this.

[NotMine999]

Regression suggests to me that there is poor or no quality control being done to Linux code, especially critical code.

Perhaps the Linux community should work more intensely on "code quality" ... or is Linux code simply getting to the point that it's too darn complicated and screwups, even avoidable screwups like this one, are inevitable?

In the Windoze world, and I am including this link intentionally, there is a new effort to use AI that is proving successful. It identifies critical bugs 97% of the time. Yes, the AI code has to be "trained" with the help of security experts.

https://venturebeat.com/2020/04/16/ai-spots-critical-microsoft-security-bugs-97-of-the-time/

My point is this: there is technology and human talent available to develop tools to help the Linux community improve "code quality". And sometimes the problem requires "process improvement" and "unflagging adherence to good process" as a part of the overall solution.

Discuss.

Oof, that's a bad regression. Good thing it's fixed.

[phoronix]

Phoronix: Linux 5.7 Git Restores The Ability To EFI Boot Following Fallout In 5.7-rc1

If you tried out Linux 5.7-rc1 at the start of the week you may have found your system unbootable if using EFI... Fortunately, those EFI fixes have now been merged several days later...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-rc1-Post-EFI-Fixed