When originally installing Ubuntu last year I was not entirely clear minded about how to proceed. The BIU installation guide for Ubuntu calls for Grub to be installed to / (root) in the partition prepared for Ubuntu. I missed that detail. This resulted in Ubuntu's boot loader being installed to the ESP, not root.
The system dual boots Win10 and Ubuntu.
BIU was installed first, then Win10, then Ubuntu.
A week ago I reinstalled Ubuntu 18.04. One of the ambitions of this reinstall was to to remedy the location of the boot loader. Unfortunately I neglected to make a new boot item. I used the same boot item created long ago for the original Ubuntu install. However, I did take care to direct the Ubuntu installer to put the boot loader in / (root).
The install was a no-worries process. Ubuntu boots and works A-OK. However, I would like to be certain that the boot loader is located in root.
Using Ubuntu's file manager to check the root directory, the only stray files outside a child directory are:
initrd.img
initrd.img.old
vmlinuz
If the install had proceeded as it should have done I would expect to find the boot loader there.
Boot items with different settings each successfully boot Ubuntu.
1) Boot from Ubuntu partition.
Ubuntu boots successfully when boot item is directed to /boot (not / root) to find a boot file from either of:
/boot/grub/x86_64-efi/grub.efi
/boot/grub/x86_64-efi/core.efi
(the directory /boot/efi is empty)
2) Boot from EFI system.
If boot item is directed to files in ESP Ubuntu boots normally too:
/EFI/Ubuntu.001/grubx64.efi
Although when I tested this just now a couple of text screens flashed up too quickly for me to read.
My guess is that booting from Ubuntu partition is somehow redirected to find grub in the ESP.
How can I determine precisely how Ubuntu is booting?
I would like to have the boot loader referenced from root.
Every time grub is updated BIU is hijacked and needs to be reset.
I expect to have to make changes to OS files to have Ubuntu recognise grub if it is moved to root.
Check Ubuntu boot loader location
Re: Check Ubuntu boot loader location
Radiogram,
You have a UEFI system and no matter what you choose for the Linux bootloader, it always goes to the ESP.
In BIU Boot Item, Menu Item, Edit. Have a look at Boot File.One of mine is...
\EFI\ubuntu.001\shimx64.efi
You need shimx64.efi with Secure Boot.
Boot field is EFI System Partition.
You have a UEFI system and no matter what you choose for the Linux bootloader, it always goes to the ESP.
In BIU Boot Item, Menu Item, Edit. Have a look at Boot File.One of mine is...
\EFI\ubuntu.001\shimx64.efi
You need shimx64.efi with Secure Boot.
Boot field is EFI System Partition.
Re: Check Ubuntu boot loader location
Hello Brian,
The workings of UEFI remain a mystery to me but this behaviour suggests robust flexibility.
I don't understand it but I'm happy it's working so reliably.
On my system the \EFI\ubuntu.001\ directory contains these files:
fwupx64.efi
grubx64.efi
mmx64.efi
shimx64.efi
Boot items will boot from grubx64.efi and shimx64.efi.
If boot item is directed to fwupx64.efi some kind of GNU grub update console appears.
If boot item is directed to mmx64.efi boot attempts would launch Shim UEFI key management console.
Boot items directed to EFI files in ESP would only boot if
Edit Boot Item > Option > Rename Directory was checked.
Don't know why that's needed.
Boot items directed to files in Ubuntu's /boot/grub/x86_64-efi/ directory have Rename Directory option greyed out.
These boot items seem to proceed more smoothly. No text flashing to screen.
It is indeed computing magic that boots directed to these files get thrown back to grub in ESP.
So lots of ways to get to the same destination - a booted OS.
In coming days I will install Ubuntu 20.04 Focal to a partition on same boot drive as Win10 and 18.04 Bionic.
Presumably when I do this a new directory will be created in ESP, probably labelled \EFI\ubuntu.002\ and it will contain same collection of files as seen in ubuntu.001.
Is that close to right?
Oh, secure boot. Is that for logins to encrypted Ubuntu OS?
Hmm, ah, no. It's a very complex verification process. All done in the blink of an eye.
https://wiki.ubuntu.com/UEFI/SecureBoot
Might explain the initrd.img.old file found in root directory. I updated mobo firmware drivers yesterday.
Thank you for your work in these forums. You are a workhorse here. And a very generous one.
Cheers,
Radiogram
The workings of UEFI remain a mystery to me but this behaviour suggests robust flexibility.
I don't understand it but I'm happy it's working so reliably.
On my system the \EFI\ubuntu.001\ directory contains these files:
fwupx64.efi
grubx64.efi
mmx64.efi
shimx64.efi
Boot items will boot from grubx64.efi and shimx64.efi.
If boot item is directed to fwupx64.efi some kind of GNU grub update console appears.
If boot item is directed to mmx64.efi boot attempts would launch Shim UEFI key management console.
Boot items directed to EFI files in ESP would only boot if
Edit Boot Item > Option > Rename Directory was checked.
Don't know why that's needed.
Boot items directed to files in Ubuntu's /boot/grub/x86_64-efi/ directory have Rename Directory option greyed out.
These boot items seem to proceed more smoothly. No text flashing to screen.
It is indeed computing magic that boots directed to these files get thrown back to grub in ESP.
So lots of ways to get to the same destination - a booted OS.
In coming days I will install Ubuntu 20.04 Focal to a partition on same boot drive as Win10 and 18.04 Bionic.
Presumably when I do this a new directory will be created in ESP, probably labelled \EFI\ubuntu.002\ and it will contain same collection of files as seen in ubuntu.001.
Is that close to right?
Oh, secure boot. Is that for logins to encrypted Ubuntu OS?
Hmm, ah, no. It's a very complex verification process. All done in the blink of an eye.
https://wiki.ubuntu.com/UEFI/SecureBoot
Might explain the initrd.img.old file found in root directory. I updated mobo firmware drivers yesterday.
Thank you for your work in these forums. You are a workhorse here. And a very generous one.
Cheers,
Radiogram
Re: Check Ubuntu boot loader location
Radiogram wrote:>
> In coming days I will install Ubuntu 20.04 Focal to a partition on same boot drive as
> Win10 and 18.04 Bionic.
> Presumably when I do this a new directory will be created in ESP, probably labelled
> \EFI\ubuntu.002\ and it will contain same collection of files as seen in ubuntu.001.
> Is that close to right?
>
Radiogram,
That's correct.
If you install other distros you could have Debian.xxx, centos.xxx, fedora.xxx, Manjaro.xxx, opensuse.xxx, etc.
Ubuntu and Mint have ubuntu.xxx.
> In coming days I will install Ubuntu 20.04 Focal to a partition on same boot drive as
> Win10 and 18.04 Bionic.
> Presumably when I do this a new directory will be created in ESP, probably labelled
> \EFI\ubuntu.002\ and it will contain same collection of files as seen in ubuntu.001.
> Is that close to right?
>
Radiogram,
That's correct.
If you install other distros you could have Debian.xxx, centos.xxx, fedora.xxx, Manjaro.xxx, opensuse.xxx, etc.
Ubuntu and Mint have ubuntu.xxx.
Re: Check Ubuntu boot loader location
Thank you, Brian.
While I do not understand UEFI completely this exercise has been worthwhile in helping me get a better feel for it.
Posting this thread has been an unusual learning experience.
I thought there was a problem of my own making but actually the system's boot arrangements were working exactly as they should. Flipping around boot item settings for testing demonstrated features of boot management I wasn't aware of.
At time of posting my question I was bracing myself for a big session of reassigning grub references in the OS via terminal after its location was moved. What a relief it is to realise everything is working just as it was intended to.
While I do not understand UEFI completely this exercise has been worthwhile in helping me get a better feel for it.
Posting this thread has been an unusual learning experience.
I thought there was a problem of my own making but actually the system's boot arrangements were working exactly as they should. Flipping around boot item settings for testing demonstrated features of boot management I wasn't aware of.
At time of posting my question I was bracing myself for a big session of reassigning grub references in the OS via terminal after its location was moved. What a relief it is to realise everything is working just as it was intended to.
Re: Check Ubuntu boot loader location
Radiogram wrote:
>What a relief it is to realise everything is working just as it was
> intended to.
That's great. Installing multiple Linux OS is easy. Copying a Linux OS to the same or another drive is a little more complex but TeraByte Support has published a reliable procedure.
>What a relief it is to realise everything is working just as it was
> intended to.
That's great. Installing multiple Linux OS is easy. Copying a Linux OS to the same or another drive is a little more complex but TeraByte Support has published a reliable procedure.
Re: Check Ubuntu boot loader location
> Installing multiple Linux OS is easy.
I am truly amazed at how easy it is.
Reinstalling 18.04 Bionic was just a breeze.
Sure, it took time to prepare the ground:
- flash iso to USB stick
- backup boot drive images
- read TBI Ubuntu install guide
- carefully select Ubuntu installer's "Something Else" parameters
When I hit the installer's go button it was all finished in about a minute and the OS worked like a charm.
Having read that Secure Boot article I now realise there are mountains of engineering effort done to allow tasks such as OS installs to work with bombproof reliability in the hands of ordinary users.
I am truly amazed at how easy it is.
Reinstalling 18.04 Bionic was just a breeze.
Sure, it took time to prepare the ground:
- flash iso to USB stick
- backup boot drive images
- read TBI Ubuntu install guide
- carefully select Ubuntu installer's "Something Else" parameters
When I hit the installer's go button it was all finished in about a minute and the OS worked like a charm.
Having read that Secure Boot article I now realise there are mountains of engineering effort done to allow tasks such as OS installs to work with bombproof reliability in the hands of ordinary users.