Thanks so much for the screenshot. It is helpful.
Looking at your screenshot and the error output, I think you can manually recover this by doing the following, but if you can run the debug steps I listed below first to collect information for us it would be helpful. .
- when you get to the terminal, hit esc to drop to the shell.
- look at the top of the screen. You have your internal NVME drive as FS1. And your usb drive as FS0. (You can see they mention the device type in the path)
- type FS0: to switch to your usb drive.
- type: CapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1
This will force installing the capsule on your NVME EFI partition.
Technical Background is as follows:
The firmware update process is as follows:
- When the capsule update is installed, it is copied to the ESP partition of the boot drive. The system does a cpu reset, and then applies the update early on in the boot process, so it needs to be saved to the disk so it is not lost during cpu reset. The capsule can be stored on any disk with a fat32 partition, but we have found some drives are not recognized early on in boot, so the best partition is the one on your NVME drive.
The early detection of the boot drive is critical to the previous 3.06 updater we released, as it required rebooting the system several times, and having the usb drive be recognized so the system can run the next steps of the update. However based on customer feedback we found that many people have usb flash drives that take longer to initialize, and will not be recognized. When this happens the bios will clear the boot variable as the drive is not found, and then immediately boot to the OS part way through the update.
We found the EDK2 updater allows us to chain several capsules together to install them all at the same time, which gets around the problem of the usb drive not being recognized.
Based on the error message, it looks like the updater is getting a little confused as it seems you have the EFI variable BootNext defined. But in your case the BootNext variable is pointing to an invalid partition.
The capsuleapp will check if the variable OsIndications is set, this is a special variable which indicates to the bios that an update should be applied. If this is set the updater will check if the variable BootNext is set, and use this to stage our bios update on the same partition as the current pending update. If these are not present/set then the updater will look at all the partitions on your system, and try to select the best one.
I think you might be hitting a case where there was a failed update, or linux installed an update (such as DBX) and then something went wrong and this variable was never cleared.
I would be interested in getting these variables. In Linux, you can look at the variables as a root user in /sys/firmware/efi/efivars
It would be interesting to see your Boot* variables, BootNext, and OsIndications variables. (They will all have a long string -GUID on the end of the variable name). OsIndications is binary, so you can get it by piping to xxd. file
Could you gather the contents of your ESP partition by running as root: ls -R /boot/efi/EFI/
Could you also see if there is a folder in your usb drive you used to update that is /EFI/CapsuleUpdate/
I would suggest trying the following to try to recover if the method above does not work.
- boot to your bios setup menu (F2), and then go into the setup menu->save and exit. Load optimal defaults. then reboot and try to install again.
- you could try deleting the OsIndications variable by removing the associated file /sys/firmware/efi/efivars/ in linux and then try installing again.