after updating to the 0.71 debug firmware on the MinnowboardMax, my system would not automatically boot from the sdcard. After adding a boot option, there was no way to change the boot order, and booting would fail due to lack of a hard drive and I would be dropped to EFI shell.
What are the steps of the reported failure? Configuration Changes in configuration Expected behavior Actual behavior Other information: The boot option processing follow the "fast boot rules". When a boot option is configured, the system will automatically boot to that device if it is available. This allows the user to set the default boot device, and to boot straight to that device. If the boot device is removed or non-functional/non-boot-able, the system will fall through the standard boot order and unless there is a valid boot device attached, will drop into shell. In the Shell, enter the “exit” command. This will exit the shell and open the device manager environment. The device manager will allow the developer to select a boot device from a menu. The system will boot to the selected device as part of the process. Once the system has booted to the new device, it will continue to use that boot path until it is no longer a valid boot path (the device removed or unable to function).
To the best of my knowledge, these were the steps that I was following: (there is a 90% chance that I will use the wrong term for something) 1. flash the 0.71 debug firmware to a minnowboard max 2. insert an sdcard with a bootable installation of Debian Linux 3. power on the device 4. see an error message that the harddrive is missing, I was never dropped to a shell 5. power cycle the minnowboardmax 6. during the memcheck, press F2 to enter the device manager environment 7. create a new boot item that points to the sdcard 8. try to change the boot order so that the sdcard is the first item The very short desciption: the device manager environment would not allow me to change the boot order on the "change boot order" screen
Don't worry about terminology (you you should what I call some things)... If I can't understand, I will ask clarification questions. OK, let's try to break this down some: 1. flash the 0.71 debug firmware to a MinnowBoard max SO far so good. Now, when the firmware is re-flashed, the setup options (particularly boot order) will revert back to the system defaults. 2. insert an sdcard with a bootable installation of Debian Linux No Problem 3. power on the device At this point, the default boot order should be the default setting. So firmware will attempt to boot the SD before we get to the Shell. 4. see an error message that the hard drive is missing, I was never dropped to a shell If the firmware cannot find a device upon boot, we drop down the boot order, and eventually hit the shell. For a system to hang on a message like this, would indicate that the firmware found what it thought was a boot-able device, handed control over to the boot loader from that deice, and was never heard from again. Question: could this "hard Drive missing message be an OS boot loader message? 5. power cycle the minnowboardmax OK, 6. during the memcheck, press F2 to enter the device manager environment OK 7. create a new boot item that points to the sdcard OK 8. try to change the boot order so that the sdcard is the first item The change of boot order is to select the boot device. I will ask the firmware developers about this, to make sure. But setting the boot device to the SD Card will make the SD card the first to boot. Additional question: after setting SD as the first boot device, power down system, and remove SD card. upon power up (without device): 1) IS the "Hard disk not found" error reported? 2) does the system fall into the shell?
>Question: could this "hard Drive missing message be an OS boot loader message? booting with the sdcard removed displays a "boot failure" error and then drops to the shell.
OK, this begins to make sense. If the system had successfully booted to the SDcard in the past (last boot), then the fast boot mechanics will consider the SDcard to be the accepted default boot path. When the SD card is removed, then the attempt to boot that device is no longer possible, and there will be a boot failure to that device (the Firmware treats the SDCard as a storage media, and may report it as a drive (due to the file system - I would have to check this out). Important point here, is that the attempt to the SDcard will fail, and a message about that failure will be registered. Now (this is the point I am unsure of, and will ask one of the firmware developers), when the default boot deice fails, I am not sure if the fallback is to traverse the generic boot order (as seen in the boot manager) or to drop directly to shell (which provides some diagnostics for debug). In the traverse of the generic boot order, then other boot devices could be detected. In the drop to shell case, the system will drop to shell where the user can enter the boot manager and set a new default boot device. Fast Boot is a bit different from the legacy Firmware boot order system. In the old system, on every boot, the system would traverse the boot order, taking time on each device to determine if it were bootable before moving on. For expedience the changing of boot order was a table of only a few options (Floppy then hard, Hard then floppy, etc) that had its own set of pitfalls (having the floppy then hard setting, then attempting to boot with a data only floppy in the drive - which really gummed the works). The plan is that most system will establish the boot device and on most boots stick to that device. The fallback to shell allows the user to choose new boot devices. What is the behavior you were expecting?
My initial bug submission was in regards to not being able to change the boot order in the legacy firmware (if that is the proper term). The desired result would be (after adding a boot option), to allow the user to change the boot order in the legacy firmware. There is a screen for changing the boot order, but it wasn't working for me.
It sounds like the operation of the "Fast Boot" methods is running headlong into the 'boot order' system. If the fast boot is dropping straight to shell when the default device is not-booting, then this would explain the issue. The failed boot of the current default, should cause the "Boot device select" code to traverse the order (set in the change boot order screen) and either boot another device, or eventually get to shell (in accordance to the order and possible boot devices on the system). It appears that the system is just falling to the shell. This is something the firmware developers can look into and resolve. On a quick side note, the MinnowBoard MAX firmware has no 'Legacy firmware' component to it. While the firmware on the MinnowBoard MAX provides basic firmware functions (some similar to those of Legacy BIOS), the mechanisms are UEFI infrastructure based in implementation. Again, don't worry about the lexicon (I understand your allusion), but the "Legacy vs UEFI" subject can derail an otherwise straightforward technical issue.
I just received an email telling me to comment on this issue as there is "INFONEEDED", what info is needed?
The question comes back to what you are seeing, and what you expect. At this point we understand that the process is not working as expected, we have an understanding that it could be one of several things: 1) the fast boot mechanism is interacting with the Boot order select 2) It has been discovered that the F10 (save changes) hot key does not work on the boot manager menu setting boot order, which may also impact the behavior of the boot order selection. 3) there could be a fall through case, sort of a catch 22 where the shell becomes he fall back regardless. However, without an understanding of what is being done (particularly that F10 key) what is expected, and what is happening, the firmware team cannot be sure to fix the behavior in a satisfactory manner. When asked "What is the behavior you were expecting?" the response referenced a "legacy BIOS". The response provided some scenarios that might accommodate what you are seeing, or expecting, but is left with an unknown of what behavior you wish to see. Also, when you say 'legacy BIOS' do you mean the setup function of the firmware (the device or boot manager)?
when I say "legacy BIOS" I mean the firmware setting that lets the user setup the device in a fashion similar to how it would be done on a machine with a BIOS. There is a screen in the setup where the user can attempt to change the boot order. On that screen, regardless of what buttons I pressed, the order never changed. Because I was unable to change the boot order, my only option was to delete all of the entries that were not my bootable device.
Need to have the changing boot order double checked. If is works, then we need a description of how it works (what the steps are , button to enact those steps, and what to expect). Right now the the prolblem could be that the command structure is not well commented, and is confusing (need to select, press enter, change, close change, and save - as to oposed to just +/- move options), or could be the system does not work. Need to have a level set.
Hi jezra, Can you try the following steps to change your boot order on your side?(eg:Set the desired boot-able device to the first boot-able device) Firstly,you can reach the setup screen where the user attempt to change the boot order. Seconly,press the "Enter" key,then <boot-able device order pop menu> will prompt. Thirdly,move the cursor down to the desired boot-able device, at this point,while pressing "Shift" key + "+" key, making the cursor up to the first boot-able device,then pressed the key "Enter". Lastly, move the cursor to "Commit Changes and Exit",then press the "Enter" key.
Moving to NEEDINFO. Please resound the last comment.
I think this comes down to a semantics problem that's two fold: 1) the main menu has two boot related menus - "Boot Manager" - "Boot Maintenance Manager" and the distinction is not readily apparent. I think this is leading to at least part of Jezra's confusion, specifically that in the Boot Manager there's no way to change things (it's more a boot loader than a boot manager). 2) in the Maintenance Manager, once you've drilled down far enough, you can change the ordering. However to save it you have to specifically select "save and commit" from the screen as opposed to F10, as F10 does *NOT* save anything on that screen. for 1 I think we need to refactor the menus somehow and make the naming (at the very least) more obvious for 2 we need to get F10 working on that screen, as well as making it more obvious in the menu hierarchy. Since we have a menu revamping bug open already, I think this should focus on #1 and trying to make it more obvious what the two menus do
John needs David to review
What about following changes: A. Change "Boot Manager" to "Boot Option Menu" B. Add a "Change Boot Order" sub-page under "Boot Option Menu" C. Enable "save" function of F10 function key under "Change Boot Order" sub-page .
John will review
"Save" function of F10 key has been enabled by V0.77 release.
I noticed, on 0.77, that F10 was added (and seems to work) but the other "save" option is now gone. Is that correct? If so can we have both? (I.E. put back the other option). The reason being is it's incredibly difficult to hit "F10" from a serial console, thus making it almost impossible to actually change the boot order solely from a serial console.
Works