Lately I've been refamiliarising myself with BIU to prepare to install Ubuntu 24.04 LTS.
My BIU augmented system has been working A-OK since installing Win10 and Ubuntu 18.04 in 2019. In 2020 I reinstalled the Ubuntu 18.04 OS and added Ubuntu 20.04. There are, however, a few points of curiosity.
Over time new directories were added to the ESP when updates were applied to the Ubuntu installations, especially with Ubuntu 20.04 since it was the OS used for the lion's share of my computing needs. On most occasions when I saw new Linux headers appear in terminal output when running:
sudo apt update && sudo apt upgrade
... new Ubuntu boot items would subsequently appear BIU's boot menu window.
In the directory efi/EFI/BOOT/ there ended up being many ubuntu.nnn files (nnn = numerals). But there were only two Ubuntu OSs installed. The system had directories labelled ubuntu.001 all the way up to something like ubuntu.025.
A long while ago, after backing up the ESP I deleted most of the extra directories. Both Ubuntu 18.04 and Ubuntu 20.04 continued to boot normally from BIU from the respective boot items (two each - one by me, other by install process) that had been created during installation.
A similar thing has occurred with MS Windows. Win10 was the first OS installed to the system. Initially in efi/EFI/BOOT/ there was only Microsoft.001. Following system upgrade to Win11 in 2023 Microsoft.002 appeared as well. The Windows installation booted normally from both of these directories and their associated BIU boot items. Yesterday I upgraded Win11 to version 23H2 and Microsoft.003 appeared.
After removing Microsoft.003 from the efi/EFI/BOOT/ directory the system continued to boot normally from boot items linked to the other two Microsoft boot directories.
Since building this system with BIU I did not access directory efi/EFI/BOOT/ until yesterday. It contains a collection of files that seem to be related to Ubuntu installations. Filenames are as follows:
- BOOTX64.nnn - numbers 000 up to 025; sizes were initially 1.3MB, 960kB after March 2023.
- BOOTX64.EFI - only one instance.
- fbx64.nnn - numbers 000 up to 024; sizes initially 1.2MB, 88kB after Aug 2021.
- mmx64.efi - only one instance, 860kB.
- SHIMX64.DAT - only one instance, 860kB.
The two Ubuntu OSs were installed using an unorthodox method. Instead of directing the Ubuntu installer to put the boot loader into the ESP I pointed it to / (root). The method is outlined in this post:
viewtopic.php?p=18914#p18914
As Brian K noted at the time, the boot loader was still placed in the ESP. While my unorthodox intstallation routine produced a bootable OS Brian noted that it doesn't work if Secure Boot is enabled.
IIRC new Ubuntu boot items appeared in BIU's boot menu after Linux headers were updated. BIU usually needed to be reactivated following updates that included Linux headers.
With so many new Ubuntu boot items appearing in BIU I began to think my unorthodox installation method might have been the cause. Is that possible or is this expected behaviour?
For the installation of Ubuntu 24.04 I intend to follow an orthodox installation using BIU and direct the Ubuntu installer to place boot loader in ESP. This OS will be installed to the partition presently occupied by Ubuntu 18.04.
Are the multiple BOOTX64.nnn and fbx64.nnn files superfluous and redundant? Will it be safe to delete them too?
My aim is to tidy up ESP directories as much as possible while still being able to boot Win11, Ubuntu 20.04, the new Ubuntu 24.04, and the old Ubuntu 18.04 should the unlikely need arise to restore it.
Guidance and advice will be appreciated.
Redundant directories & files in ESP?
Re: Redundant directories & files in ESP?
Radiogram,
I don't have answers and I'd be interested to see answers. I looked at two computers.
\EFI\BOOT\
BOOTX64.nnn - numbers 000 up to 013 in one computer. 000 to 041 in the other
BOOTX64.EFI - only one instance.
fbx64.nnn - numbers 000 up to 012 in one computer. 000 to 039 in the other
mmx64.efi - only one instance,
SHIMX64.DAT - only one instance
BOOTIA32.EFI only in the second computer. Not in the first
There were no ubuntu.nnn or Microsoft.nnn
\EFI\
Microsoft.nnn - several
ubuntu.nnn - several
Boot and BootIt directories
Typical Boot Files are...
\EFI\Microsoft.001\Boot\Bootmgfw.efi
\EFI\ubuntu.002\shimx64.efi
I don't have answers and I'd be interested to see answers. I looked at two computers.
\EFI\BOOT\
BOOTX64.nnn - numbers 000 up to 013 in one computer. 000 to 041 in the other
BOOTX64.EFI - only one instance.
fbx64.nnn - numbers 000 up to 012 in one computer. 000 to 039 in the other
mmx64.efi - only one instance,
SHIMX64.DAT - only one instance
BOOTIA32.EFI only in the second computer. Not in the first
There were no ubuntu.nnn or Microsoft.nnn
\EFI\
Microsoft.nnn - several
ubuntu.nnn - several
Boot and BootIt directories
Typical Boot Files are...
\EFI\Microsoft.001\Boot\Bootmgfw.efi
\EFI\ubuntu.002\shimx64.efi
-
TeraByte Support
- Posts: 3641
- Joined: Thu May 05, 2011 10:37 pm
Re: Redundant directories & files in ESP?
perhaps enable the rename option then while ubuntu is running this is only that directory.
Re: Redundant directories & files in ESP?
Brian,
You never fail to cut through.
The behaviour you described in the two computers you checked correlates with what I've seen in the ESP of my PC.
It seems this unexplained spawning of boot directories in the ESP (both within /EFI/ and /EFI/BOOT/ ) is normal.
It takes up a lot of partition space though. Before I deleted unused ubuntu.nnn directories a couple of weeks ago the output of terminal command:
df -h
... showed the ESP was 44% full. After deleting those files it is 37% full.
If the computer has a long service life (which I intend this computer to do) and if numerous OSs are installed the unexplained spawning of boot directories could fill the ESP. Starting with 400MB might not be big enough.
Terabyte Support,
When each of the two Ubuntu OSs were installed to my PC two BIU boot items and corresponding ubuntu.nnn boot directories were created:
• one created by me in which I directed the boot loader to be placed in / (root) on that system's partition.
In its BIU boot item the rename option is greyed out.
• the other was created automatically (by BIU?) during the install process.
In its BIU boot item the rename option is active and checked.
Last week another lot of update packages which included Linux headers et al came down the pipe for Ubuntu 20.04. A new boot directory was not created this time.
I tested the additional boot directories, microsoft.002 and microsoft.003, to see if they would boot. I edited a working boot item to look for microsoft.002 instead of microsoft.001. Win11 did not boot.
Same happened when I tried to use microsoft.003. However, I had previously moved microsoft.003 out of the /EFI/ and saved the file to a backup directory on my system. Maybe the moving and copying changed files in the directory. It certainly changed their ownership. I had to use sudo to effect the copy.
You never fail to cut through.
The behaviour you described in the two computers you checked correlates with what I've seen in the ESP of my PC.
It seems this unexplained spawning of boot directories in the ESP (both within /EFI/ and /EFI/BOOT/ ) is normal.
It takes up a lot of partition space though. Before I deleted unused ubuntu.nnn directories a couple of weeks ago the output of terminal command:
df -h
... showed the ESP was 44% full. After deleting those files it is 37% full.
If the computer has a long service life (which I intend this computer to do) and if numerous OSs are installed the unexplained spawning of boot directories could fill the ESP. Starting with 400MB might not be big enough.
Terabyte Support,
When each of the two Ubuntu OSs were installed to my PC two BIU boot items and corresponding ubuntu.nnn boot directories were created:
• one created by me in which I directed the boot loader to be placed in / (root) on that system's partition.
In its BIU boot item the rename option is greyed out.
• the other was created automatically (by BIU?) during the install process.
In its BIU boot item the rename option is active and checked.
Last week another lot of update packages which included Linux headers et al came down the pipe for Ubuntu 20.04. A new boot directory was not created this time.
I tested the additional boot directories, microsoft.002 and microsoft.003, to see if they would boot. I edited a working boot item to look for microsoft.002 instead of microsoft.001. Win11 did not boot.
Same happened when I tried to use microsoft.003. However, I had previously moved microsoft.003 out of the /EFI/ and saved the file to a backup directory on my system. Maybe the moving and copying changed files in the directory. It certainly changed their ownership. I had to use sudo to effect the copy.
Last edited by Radiogram on Sun May 19, 2024 10:39 pm, edited 1 time in total.
-
TeraByte Support
- Posts: 3641
- Joined: Thu May 05, 2011 10:37 pm
Re: Redundant directories & files in ESP?
if you boot directly to something outside of the boot item, there will be no \efi\ubuntu at that point, and perhaps that's when it gets recreated. The process would be to boot the item with the rename enabled then without booting back to BIU, boot the other media. BIU will rename it back once it loads again.