Using the UEFI Shell to Restore Boot Configuration

Question

I am using an embedded board that supports UEFI. It is a new fangled board and comes up with American Megatrends BIOS and a UEFI shell (I am more used to dealing with a bootloader and not a PC BIOS on an embedded board).

The details of the board are not so important.

What is important is that under certain conditions (in software while writing to PCI space in an incorrect way) we can hose the boot sector in the onboard Flash.

Since this hardware will be a REMOTE piece of hardware, there is no option of walking out to nowhere land, sticking in a USB and reflashing this thing.

I would like to write a script to make the BIOS Shell do this. If the machine is hosed and we have corrupted the bootsector on a deployed system, I would like to automatically run a restore sequence. Is this sort of thing possible? Can I do it with a UEFI shell? Is this doable in anyway?

Now I understand UEFI was created to provide 'secure' boot, I may be doing the opposite of what it was intended to do!

Solution

EFI doesn't use the boot sector of the disk. Thus, I suspect that you misunderstand what's happening to your system. My guess is that you're actually damaging the NVRAM entries that hold the boot order for the device. The easiest way to deal with this problem is to not use those entries, and instead name your EFI boot loader EFI/BOOT/bootx64.efi (or more generally, boot{arch}.efi, where {arch} is an architecture code; x64 is the architecture code for x86-64). If you don't want to do this for some reason, and if your EFI shell is a version 2 shell, you can use the bcfg command in an EFI shell script to do the job. This command is documented to varying extents in various places, such as the Arch Linux wiki and Intel's site. Unfortunately, the older version 1 EFI shell doesn't support the bcfg command, so this option won't work with it, although it might be possible to extract the relevant code from the TianoCore source code and create a standalone bcfg command that you could use with an older shell.

If you really need to write to the MBR, then writing an EFI application in C might be a better choice than trying to do it in the EFI shell. There's a lot of EFI programming documentation out there, but most of it is like Unix man pages -- it assumes that you already know the topic and just need to check the details. I've written a brief tutorial introduction, but it's very basic and doesn't cover disk I/O. (You could use that and the source code to gptsync, which is included in the last couple versions of rEFInd, though, to learn how to read and write the MBR of a disk.)

If I understand correctly, whatever you do (unless using the fallback filename is sufficient), you'd need to fit it into the normal boot sequence. This would be possible with either an EFI shell program launched as the default or as a binary program; but you'll have to be sure that your custom program concludes by launching the "real" boot loader, or that the "real" boot loader launches after the new program.

Comments

[Ramhound]

I don't see anyway of doing this. Whats more interesting is the fact that just accessing PCI space can corrupt the boot sector.

[Xofo]

Yes I know ... it is one use case - boot sector has been corrupted in a variety of situations, which has raised eyebrows. As such wondered if there was a way to restore the system ... some kind of embedded system restore. I would need to have a good image and overwrite the MBR somehow and the only way I can think of is having the bios kick this script off somehow.

[Ramhound]

I don't see a way to do it through a remote connection that wouldn't always happen. Which wouldn't really work well.

[Xofo]

I do not really need a network, other than maybe if I want to send a RESTORE command somehow (another issue) or to have a script that says if after 3 failed boots, do a restore. Other thoughts - I think what I want is to somehow get the Bios to restore the boot sector from an image on a backup storage device (maybe another flash). Maybe another way is to specify another bootable device incase the first one fails ... but I would still want to do a restore on the first one ...

[Xofo]

Luke - It is not so much that I am writing to PCI space in an incorrect way, it is more so that I found a way to break the system and I want to prevent that. The problem was (1) Writing to a PCI device that is not there (2) Writing to Flash when the hardware write-protect is there ... I don't expect either of these to hose the boot sector of the Flash, but it did. Thus when hosed the system looks for the next bootable device (there is none) and the EFI shell comes up (when we plug in a display ... yes it has an HDMI (useful for debugging, but not used in deployed state).

[Xofo]

This was mostly helpful. A few clarifications and some information.

[Xofo]

It has an AMT Bios. Usually these boards have UBoot or the VxWorks Bootloader (not a PC Bios). What I do is write the (VxWorks) bootloader to the internal flash, rearrange the boot order in the bios to point to it and then run VxWorks. Well this all works fine - no problemo. However there are times (just one example) when we try to access via software a PMC card that we forgot to plug in and ZAP, the system hangs. Then on reboot the VxWorks bootloader is trashed. I want a recovery for when I deploy this just in case. Thanks.

[Xofo]

So I want to use the EFI to RESTORE the VxWorks bootloader in case the bootloader is trashed. I need a failsafe for such a worst case scenario. I think you gave me some ideas.

[Xofo]

Thanks you for the pointers Mr. Rod Smith ... I think I have enough to explore this issue and try to find a work-around!

[Xofo]

Revisiting this 2 years later, I am encouraged to see that this weird question generated over 3000 views.