I decided to start over with this PC as it was setup as legacy BIOS/MBR.
I changed the BIOS to UEFI, wiped the SSD, converted it to GPT, restored Windows 10 using Macrium, made sure Windows booted, installed Lubuntu 24.04 and again there was no grub menu, but would just boot straight into Windows instead of Lubuntu like yesterday.
I decided to flash the USB stick using Rufus as you can specify GPT & UEFI, re-installed Lubuntu, now I get an annoying error message during boot
“Failed to open \EFI\ubuntu\ - Not Found”
but then the grub menu appears and can boot into Lubuntu or Windows just fine.
I went into the BIOS and viewed the Boot Option and I see that '\EFI\ubuntu' does indeed exist so I’m confused about that error message.
And the Discover app works so far.
Could you provide a clear picture of your partition setup?
Please also provide the results of:
sudo efibootmgr -v
lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,partflags,uuid,partuuid
sudo efibootmgr -v
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0000,0001,0003,0004,0005,0006,0002,0007
Boot0000 Diskette Drive BBS(Floppy,,0x0)
dp: 05 01 09 00 01 00 00 00 00 / 7f ff 04 00
Boot0001* INTEL SSDSC2KW256G8 BBS(HD,,0x0)494e54454c205353445343324b5732353647382020202020202020202020202000
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 49 4e 54 45 4c 20 53 53 44 53 43 32 4b 57 32 35 36 47 38 20 20 20 20 20 20 20 20 20 20 20 20 20 00
Boot0002* Windows Boot Manager HD(1,GPT,023f9b79-d74a-46c0-8ecd-f76f6d75a6cd,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000000120100000010000000040000007fff0400
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 40 06 00 00 00 00 00 79 9b 3f 02 4a d7 c0 46 8e cd f7 6f 6d 75 a6 cd 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 5c 00 42 00 6f 00 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00 6d 00 67 00 66 00 77 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
data: 57 49 4e 44 4f 57 53 00 01 00 00 00 88 00 00 00 78 00 00 00 42 00 43 00 44 00 4f 00 42 00 4a 00 45 00 43 00 54 00 3d 00 7b 00 39 00 64 00 65 00 61 00 38 00 36 00 32 00 63 00 2d 00 35 00 63 00 64 00 64 00 2d 00 34 00 65 00 37 00 30 00 2d 00 61 00 63 00 63 00 31 00 2d 00 66 00 33 00 32 00 62 00 33 00 34 00 34 00 64 00 34 00 37 00 39 00 35 00 7d 00 00 00 00 12 01 00 00 00 10 00 00 00 04 00 00 00 7f ff 04 00
Boot0003* USB Storage Device BBS(USB,,0x0)
dp: 05 01 09 00 05 00 00 00 00 / 7f ff 04 00
Boot0004* CD/DVD/CD-RW Drive BBS(CDROM,,0x0)50313a2054535354636f7270204456442b2f2d52572053482d323136424200
dp: 05 01 09 00 03 00 00 00 00 / 7f ff 04 00
data: 50 31 3a 20 54 53 53 54 63 6f 72 70 20 44 56 44 2b 2f 2d 52 57 20 53 48 2d 32 31 36 42 42 00
Boot0005 Onboard NIC BBS(Network,,0x0)49424120474520536c6f74203030433820763133373600
dp: 05 01 09 00 06 00 00 00 00 / 7f ff 04 00
data: 49 42 41 20 47 45 20 53 6c 6f 74 20 30 30 43 38 20 76 31 33 37 36 00
Boot0006* Ubuntu HD(1,GPT,023f9b79-d74a-46c0-8ecd-f76f6d75a6cd,0x800,0x64000)/File(\EFI\ubuntu\shimx64.efi)
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 40 06 00 00 00 00 00 79 9b 3f 02 4a d7 c0 46 8e cd f7 6f 6d 75 a6 cd 02 02 / 04 04 34 00 5c 00 45 00 46 00 49 00 5c 00 75 00 62 00 75 00 6e 00 74 00 75 00 5c 00 73 00 68 00 69 00 6d 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
Boot0007 UEFI: INT13(RAID,0x80) PciRoot(0x0)/Pci(0x1f,0x2)/VenHw(aa7ba38a-dabf-40c3-8d18-b55b39609ef7,8001000000005241494420202020ffffffffffffffffffffffffffffffffffffffffffffffff)/HD(1,GPT,023f9b79-d74a-46c0-8ecd-f76f6d75a6cd,0x800,0x64000)
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 02 1f / 01 04 3a 00 8a a3 7b aa bf da c3 40 8d 18 b5 5b 39 60 9e f7 80 01 00 00 00 00 52 41 49 44 20 20 20 20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff / 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 40 06 00 00 00 00 00 79 9b 3f 02 4a d7 c0 46 8e cd f7 6f 6d 75 a6 cd 02 02 / 7f ff 04 00
lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,partflags,uuid,partuuid
NAME FSTYPE SIZE FSUSED LABEL PARTLABEL MOUNTPOINT PARTFLAGS UUID PARTUUID
sda 238.5G
├─sda1
│ vfat 200M 32.8M EFI system partition /boot/efi 0x8000000000000000 9837-4A1E 023f9b79-d74a-46c0-8ecd-f76f6d75a6cd
├─sda2
│ 128M Microsoft reserved partition 0x8000000000000000 5442a99a-2ecc-4b3a-bcc8-f84fcce4dc87
├─sda3
│ ntfs 49.8G Basic data partition 01D8ADF3DCF91840 dc59b135-8efe-46dc-ade6-43a2a556a6f4
└─sda4
ext4 188.4G 7.2G lubuntu_2404 lubuntu_2404 / 6157e839-a186-472e-abc0-24c6644bfdc5 b204c750-8ceb-4583-9985-472404665e61
Well clearly, the first device that is attempted to boot from is a floppy, so that may be the problem. It also may be a problem that the second device getting booted is the issue, which appears to point at the hard drive, but not the partition if I’m reading it correctly.
What you can see is that the current boot is 6, or the Ubuntu partition, or looking at the partition UUID, specifically sda1, which makes sense given that it’s the /boot/efi partition. One thing you can do is temporarily set the thing to boot directly to this rather than following the boot order. This will work for one boot and then won’t work for subsequent boots:
sudo efibootmgr -n 6
If that works, try it again and make sure it works as expected in both Lubuntu and Windows.
If that is good you can change the boot order as follows:
sudo efibootmgr -o 6,x,y,z
where x,y,z refers to any other boot entries you’d like to keep.
All of this info is new to me but very interesting, this machine doesn’t have a floppy drive so I wonder where that is coming from.
It’s almost sleep time here so I will try those things in the morning.
It’s interesting that ~4 years ago I installed 20.04 and ~2 years ago I installed 22.04 on this same machine without any issues.
Thank you very much for all your time and I will update in the morning.
You are aware that when you reformat the ISO using options as provided by some software, the result needs to match your hardware exactly (ie. match your firmware settings), esp. in regards uEFI/Secure-uEFI & BIOS/CSM/legacy.
Ubuntu QA (which applies to Lubuntu as well) involves mostly cloned ISOs written to media; ie. we don’t adjust our ISOs when writing to data, but actually only Quality Assurance test the unchanged image.
A reformatted ISO (ie. written with options that cause thumb-drive to look differently) can cause the installer (calamares in Lubuntu) to incorrectly write boot details to the wrong location; the result of it not detecting at install, what is expected.
I’ll suggest not reformatting the ISO and try a documented ISO writing procedure, if what Walter is suggesting doesn’t work, and especially for future installs.
Don’t forget ISOs of 20.04 & earlier differed in format to the releases of 20.10 & later; as Ubuntu has ensured all architectures boot identically for 20.10 & later, thus there are differences between releases of ISOs on 20.10 & later, esp. when contrasted to 20.04 & earlier
Good morning,
Thanks for the reply.
I did follow the documented ISO writing procedure the first time I flashed the USB stick, and the first time I installed 24.04 there was no grub menu and booted straight into Lubuntu, when I re-installed 24.04 after re-formatting the ssd again there was no grub menu and booted straight into Windows, that’s why I decided to try Rufus.
We do test multiboot setups (meaning Lubuntu plus other OSes, whether they be Linux or otherwise) using the replace partition option in the installer. I would expect those to work right out of the box. If you’re doing manual installation, well, you’re running with scissors. You can screw up all sorts of things and the installer won’t second guess you. It’s quite possible if you did do manual installation, you created your own problem.
What we do not test is anything involving Windows tools. That includes Rufus. We’d probably typically download the ISO with zsync (which naturally ensures the ISO is valid). When making USBs, we’d probably use Startup Disk Creator (or perhaps mkusb), as mentioned in the manual. Being sort of Linux-specific, this is not really a good test for what to do if all you have is Windows.
The biggest problem is that we all primarily use Linux. So we can’t even reasonably test using Rufus. There are countless problems people have reported with it over the years (just search for “Rufus” here). I just noticed our manual points to an Ubuntu tutorial on Rufus but there’s now a note on it saying that they suggest balenaEtcher which is available for both Windows and Linux, so perhaps we can try using that in the future.
If you aren’t too deep in this install, you may want to consider using balenaEtcher and starting over.
If you want to keep forging ahead with what you have, did the instructions I gave you solve the issue?
Thanks for the reply.
Both times I installed I did the replace partition, I did nothing manually.
I can try using balenaEtcher and re-install, anything I should do first?
Here’s today’s findings:
Tried the “sudo efibootmgr -n 6” command and booting Lubuntu and Windows was fine.
I re-ran “sudo efibootmgr -v” command to verify same as yesterday.
I looked at the bootorder on my other PC and tried setting the same device order (not boot #'s) on this one:
sudo efibootmgr -o 6,7,1,0,3,4,5
which would be:
Boot0006* Ubuntu
Boot0007 UEFI: INT13(RAID,0x80)
Boot0001* INTEL SSDSC2KW256G8
Boot0000 Diskette Drive
Boot0003* USB Storage Device
Boot0004* CD/DVD/CD-RW Drive
Boot0005 Onboard NIC
Rebooted.
Got an error message that it couldn’t find hard disk - WTH?
Got into BIOS, there were 2 boot devices listed:
Ubuntu - was enabled
UEFI: INT13(RAID,0x80) - was not enabled so I enabled
Rebooted.
Got the same error mesage about not finding \EFI\ubuntu but had grub menu and booted Lubuntu.
Ran the “sudo efibootmgr -v” command again and now it sees 2 diskette drives and moved the INTEL SSDSC2KW256G8 to Boot0008*
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0001,0003,0004,0005,0008,0006,0007
Boot0000 Diskette Drive
Boot0001* Diskette Drive
Boot0002* Windows Boot Manager
Boot0003* USB Storage Device
Boot0004* CD/DVD/CD-RW Drive
Boot0005 Onboard NIC
Boot0006* Ubuntu
Boot0007* UEFI: INT13(RAID,0x80)
Boot0008* INTEL SSDSC2KW256G8
The only thing you need to make sure to do before using Etcher is to make sure the ISO passes the integrity test, as described in the manual.
So I should point out a couple things about efibootmgr:
- This lists the entries in your volitaile RAM (NVRAM)
- This does not list attached devices
- The asterisks indicate active entries
My guess is that the firmware you’re using just naturally comes with default entries in NVRAM that are inactive by default. I think that “RAID” entry you have may be one of them, unless you know that you are running a RAID array.
That said, what I said yesterday about the floppy drive was wrong. However, the first active device that was being booted was the INTEL device, which I think is the thing that’s throwing up the error.
So you can edit your NVRAM two ways: through the firmware itself (what you call “BIOS;” technically, it’s not, but I understand what you mean) and through efibootmgr. It’s possible that when you got into the firmware, it also reset your boot order.
Another possible explanation is that the boot number changed. Looking at that “INTEL” device here’s what I see:
See the difference? So I would always run sudo efibootmgr -v to check the index before making changes.
So to summarize, I’d change your boot order to only the active devices that you know you want to use.
Then after you’re done, run sudo efibootmgr -v again to make sure that the “NextBoot” is set to your first boot entry.
I apologize if I’m wasting your time…
I did use ‘Startup Disk Creator’ utility in Lubuntu 22.04 the first time I flashed the USB stick.
I did check the BootOrder this morning before I manually set.
I do not have a RAID device.
I thought I would try to set BootOrder 1 more time:
Verified devices again then:
sudo efibootmgr -o 6,8,3,4
which would be:
Boot0006* Ubuntu
Boot0008* INTEL SSDSC2KW256G8
Boot0003* USB Storage Device
Boot0004* CD/DVD/CD-RW Drive
Rebooted
Got same not finding \EFI\ubuntu message but had grub menu and booted Lubuntu.
Ran "sudo efibootmgr -v’ command.
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0008,0001,0003,0004,000A,0006,0009
Boot0000 Diskette Drive
Boot0001* USB Storage Device
Boot0002* Windows Boot Manager
Boot0003* CD/DVD/CD-RW Drive
Boot0004* Onboard NIC
Boot0005 Onboard NIC
Boot0006* Ubuntu
Boot0007* UEFI: INT13(RAID,0x80)
Boot0008* Diskette Drive
Boot0009 UEFI: INT13(RAID,0x80)
Boot000A* INTEL SSDSC2KW256G8
So it changed the BootOrder.
And now it shows 11 devices, it added another ‘Onboard NIC’ device and ‘UEFI: INT13(RAID,0x80)’ device.
I rebooted again and nothing changed, so it seems it’s after I manually set BootOrder that it adds device(s) and changes the order.
I’ll try re-installing now and see what happens.
Thanks again.
You’re not wasting my time, but I appreciate your consideration. One can learn a lot trying to solve strange issues 
To be frank, I haven’t had to do this much before.
As for Startup Disk Creator, I’m surprised it didn’t work! There may be a bug there. I’ll look further.
So here’s my other thinking: maybe (for some odd reason) for changing the boot order, the index without the padded zeroes doesn’t work. So maybe do sudo efibootmgr -o 0006,0008,0003,0004. I will say that the man page specifically says zero padding isn’t necessary, but I’m struggling to come up with any other explanation for what you’re seeing.
Re-installed after using BalenaEtcher to flash usb stick, no change at all, still get the message during boot, BootOrder and # of devices same as my last post.
Let me try your last suggestion.
Zero padding didn’t help, still changed BootOrder and added 3 more devices.
Maybe try to do the same thing within the firmware itself?
I mean, realistically, efibootmgr should be able to do the same thing. However, I did find at least one report (and a very recent one) of it failing to change the boot order in one very particular case. You may want to ubuntu-bug efibootmgr and create a bug report describing how you could not change your boot order. I don’t think the details of your installation are relevant to that bug report, I might add.
If you want to dig a little bit deeper, you might want to use efivar as the bug reporter uses. You can list all your variables with efivar --list so you could probably look for any variables that seem to deal with boot order by doing something like efivar --list | grep -i order. If you find one ending in “DefaultBootOrder,” that may well be the issue. In fact, if ANY of the variables aren’t in the UEFI specification, that could well be the issue, too.
I tested things in a live 24.04 virtual machine running in EFI mode and got the following variables:
efivar --list
(It's kind of a long list)
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
eb704011-1402-11d3-8e77-00a0c969723b-MTC
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0004
d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0001
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0000
04b37fe8-f6ae-480b-bdd5-37d98c5e89aa-VarErrorFlag
8be4df61-93ca-11d2-aa0d-00e098032b8c-Lang
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000
4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14-FirmwareFeaturesMask
4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14-FirmwareFeatures
d9bee56e-75dc-49d9-b4d7-b534210f637a-certdb
f0a30bc7-af08-4556-99c4-001009c93a44-SecureBootEnable
d719b2cb-3d3a-4596-a3bc-dad00e67656f-db
8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK
8be4df61-93ca-11d2-aa0d-00e098032b8c-PK
605dab50-e046-4300-abb6-3dd810dd8b23-MokListTrustedRT
605dab50-e046-4300-abb6-3dd810dd8b23-SbatLevelRT
605dab50-e046-4300-abb6-3dd810dd8b23-MokListXRT
605dab50-e046-4300-abb6-3dd810dd8b23-MokListRT
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformRecovery0000
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
8be4df61-93ca-11d2-aa0d-00e098032b8c-LangCodes
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
7c436110-ab2a-4bbb-a880-fe41995c9f82-boot-args
4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14-BackgroundClear
8be4df61-93ca-11d2-aa0d-00e098032b8c-VendorKeys
d9bee56e-75dc-49d9-b4d7-b534210f637a-certdbv
8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
8be4df61-93ca-11d2-aa0d-00e098032b8c-SignatureSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
Specifically looking at the bootorder:
efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootOrder"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 04 00 00 00 01 00 02 00 03 00 |.......... |
It may not be obvious with the zeroes between them, but that refers to a boot order of 4,0,1,2,3.
You can see this in the way we’ve been doing:
sudo efibootmgr (note I didn’t use the -v switch because that level of detail isn’t all that necessary at this point)
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0002,0003
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0){auto_created_boot_option}
Boot0002* UEFI VBOX HARDDISK VB8a779753-ab3c19d0 PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0){auto_created_boot_option}
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Ubuntu HD(1,GPT,aa15bd26-5f3a-4ec8-809d-59be22fbb3c3,0x1000,0x96000)/File(\EFI\ubuntu\shimx64.efi)
I can change this to the reverse with:
sudo efibootmgr -o 3,2,1,0,4
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0003,0002,0001,0000,0004
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0){auto_created_boot_option}
Boot0002* UEFI VBOX HARDDISK VB8a779753-ab3c19d0 PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0){auto_created_boot_option}
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Ubuntu HD(1,GPT,aa15bd26-5f3a-4ec8-809d-59be22fbb3c3,0x1000,0x96000)/File(\EFI\ubuntu\shimx64.efi)
And it’s reflected elsewhere:
efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
Name: "BootOrder"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 03 00 02 00 01 00 00 00 04 00 |.......... |
The firmware GUI only shows 2 entries:
Ubuntu
UEFI: INT13(RAID,0x80)
I guess I’m gonna use as is for now and see if I encounter any other issues.
Thank you again so much for all your help.
For what it’s worth, that error should not prevent you from booting, but it does add an annoying delay.
Sorry I couldn’t help more.