How to boot from an EUFI original or clone Linux partition

[brucebne]

Incidentally, after I copied and resized a Mint partition this morning, then applied "boot-repair" to regain access, I've been getting the following error message after choosing a BIU boot menu item:

"warning: unable to point uefi to current boot item:

but a successful boot continues anyway.

I am presuming 'boot-repair' doesn't fix or restore things to the same as a new installation.
i.e.
boot-repair when asked to reinstall grub
- installs it on the OS partition
- creates on ESP a /ubuntu.00x/ folder with one file in it, grubx64.efi (there's no grub.cfg requiring a uuid number change, nor shimx64, mmx64, fwupx64 efi files)

[Brian K]

Thanks. I now prefer your method over the IFL method. The IFL method takes a minute or two longer to run through the steps, just related to finding files and copy/paste, not to hardware differences.

I did it from installed Mint 19.1, not from a flash drive.

Your latest issue is weird.

[Brian K]

brucebne wrote:
> Incidentally, after I copied and resized a Mint partition this morning,
> then applied "boot-repair" to regain access, I've been getting
> the following error message after choosing a BIU boot menu item:
>
> "warning: unable to point uefi to current boot item:
>

Does that happen when you boot Win10?

[brucebne]

Brian K wrote:

> > "warning: unable to point uefi to current boot item:
> >
>
> Does that happen when you boot Win10?

Yes....it happens for all BIU boot items (1xwin10 and 2x Mint)
However it doesn't happen if I Press F12 and boot directly into Mint from the BIOS menu items presented.

So I am thinking it is something to do with BIU passing to grub....maybe something to do with BIU's or Grub's record of the GPT partition table.

[brucebne]

Brian K wrote:
> Your latest issue is weird.

Yes I appreciate I am messing around doing things not intended by the designers of this stuff.

The smart thing to do would be to read GPT/UEFI documentation for a month before doing this stuff.
But white papers are as dry as buggery....not that I prefer experimenting in the dark, and discovering things by trail and error.

At the end of the day I don't like working with things unless I know how they work, and can get myself and others out of trouble.

If I didn't have to go to work, I'd document and create flow charts and visual representations of this stuff and put it on a blog.
There's obviously a big need to clarify how EFI/GPT+MBR/Grub interact.

[Brian K]

I would restore an image of the ESP. The image would need to have been taken prior to this issue commencing. I hope you have a recent image.

[brucebne]

Brian K wrote:
> I would restore an image of the ESP. The image would need to have been
> taken prior to this issue commencing. I hope you have a recent image.

LOL.... yeah I do....well from about 36 hours ago.

Another lesson that whenever I do ANY changes to partitions, backup the OS parts and ESP.

I keep thinking this should be as easy as BING was with MBR....

[brucebne]

Just had a look back through my backups, and will do as you suggest.

I can be a slow learner.....but I think the take home from this latest 'issue' is know when to take 1 step back to take 2 steps forward.....especially when adventuring into unknown waters.

[Brian K]

I've done lots of ESP restores in BIU. They take a second or two.

[brucebne]

Brian K wrote:
> I've done lots of ESP restores in BIU. They take a second or two.

My ESP takes similar time both ways.
My Mint part. take 18 seconds.

And in case you missed me saying it earlier, the Lenovo clone operations are just as quick as imaging.
So the slow copy issue is unique to the Dell

This arvo I have trialled doing OS part. slides and resizes on the Lenovo.
After sliding the clone, I got the same message as I did with the Dell
"warning: unable to point uefi to current boot item"

This message comes a second of choosing ANY BIU boot menu item.
So I am now suspecting this might be generated by BIU.

Something else that happens in BIU is, after doing any work with partitions (slide, resize, new part, delete part), and I exit "work with partitions", and try to do something else (say imaging, boot menu edit), I get an error message "unable to load boot.dat" and BIU freezes.

So how's this for a presumption of why?
BIU either

- only writes GUID partition entry changes into its memory until the user exits BIU. At that point BIU updates the GUID Partition Table with new partition address and size info.
Hence, imaging/restoring operations are not possible once even one GUID partition table change has been made using "work with partitions".

- needs to be exited and reopened to reload GPT table with changes it has written during a session.
This would be a reasonable safety precaution against corrupting GPT.

- It might also be that GPT only backs up 'primary GPT' to 'secondary GPT' with a computer reboot....and BIU can only proceed with certain operations after GPT backs itself up.

As for the message
"warning: unable to point uefi to current boot item"
that might be due to how BIU sets up boot menu items.

Actually something that occurred to me while thinking this through is, after doing partition changes, to delete the old boot menu items, and make new ones.
This might force BIU to update GPT data associated with Boot menu items.

OK, I've just spent an hour creating new boot menu items, and trialing different item options, but I couldn't get rid of the warning.
However, when I boot directly into Mint via a BIOS boot, bypassing BIU, I don't get any warning messages.
So I presume this error is BIU's.