Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UEFI Failing to Load Menu Which Previously Worked #162

Closed
PicoMitchell opened this issue Oct 28, 2020 · 5 comments
Closed

UEFI Failing to Load Menu Which Previously Worked #162

PicoMitchell opened this issue Oct 28, 2020 · 5 comments

Comments

@PicoMitchell
Copy link

I build the latest iPXE periodically to keep up with changes.

The last build from last month (2020-09-23) works perfectly fine in UEFI and BIOS mode. But when I built the latest iPXE on 2020-10-20, I'm having issues with my exact same menu files in UEFI while BIOS continues to work fine.

I just built the latest iPXE again today to see if anything has changed and I'm getting the same behavior.

I have script which downloads the latest iPXE source and then does a few minor modifications to include the build date as the version and enable the settings we use, which are:

UNCOMMENT IN config/general.h: #define POWEROFF_CMD, #define PARAM_CMD, #define PING_CMD, #define CONSOLE_CMD
UNCOMMENT IN config/console.h: #define CONSOLE_FRAMEBUFFER
ADD IN config/defaults/pcbios.h: #define MEMMAP_SETTINGS

My embedded menu file successfully runs dhcp, ping, and then tries to boot my actual menu file from the server which was successfully detected with the previous commands.

I can see the the menu file get loaded with the "ok" message but then the computer just hangs on a black screen or reboots.

This main menu file has a lot of options, but everything is done as safe as I could, all the initial custom color and image loading lines end with "||" so they should just continue to show the menu if anything fails.

Up until the point that the first menu is displayed, all that is done is setting variables for later use, a few of which are conditional for the platform but nothing too fancy. As far as I know I have things set up in such a way that a menu error should never cause a shutdown or reboot, worst case would be an unstyled menu or an error getting displayed.

Is there anything in the commits since 2020-09-23 that might explain this behavior? Or is there more specific information you need about my setup/menus?

Thanks so much for any help and/or advice with this issue.

@PicoMitchell
Copy link
Author

I'm checking out and building with specific commits to try better to determine which commit caused the issues I'm seeing.

I'm going to continue narrowing down, but so far I've determined that commit 6ccd523 from 2020-10-14 works properly and that 04cb17d from 2020-10-19 DOES NOT work with the same error as described above.

I also tried commit 1e8648f from 2020-10-16 which seemed to take a really long time to initialize iPXE to the point that I just shut down the comp. Not sure whether that is a related issue or another thing so mostly disregarding that for more investigation with other commits from earlier on 2020-10-16. Will follow up when I learn more.

@PicoMitchell
Copy link
Author

Latest progress:

2091288 from 2020-10-16 WORKS

87e39a9 from 2020-10-16 init hangs (different issue or related?)

f2c8261 from 2020-10-19 init hangs (different issue or related?)

@PicoMitchell
Copy link
Author

PicoMitchell commented Oct 29, 2020

b50ad5f from 2020-10-19 DOES NOT work with same error as described above.

So, something happened between 2091288 and 87e39a9 which caused initialization to hang.

Then, something between f2c8261 and b50ad5f fixed the hanging on initialization, but somehow the new menu loading issue as originally described is now present in that build and (I believe) all newer builds.

I think that's about the most helpful I can be with narrowing down where this issue may have happened in the code.

@mcb30
Copy link
Member

mcb30 commented Oct 30, 2020

@PicoMitchell Thank you for the detailed information! Commit 87e39a9 I think accidentally pulls in the USB driver stack, and this is an issue that shouldn't have been fixed by any more recent commit that you had tested. I have now fixed this particular issue in commit 1687370 (which credits you for the discovery).

So, could I possibly ask you to retest with the current master branch? Thanks!

@PicoMitchell
Copy link
Author

Thank you so much, the latest build appears to fix this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants