Uefi Boot Sequence Empty

0 views

Skip to first unread message

Tancredo Dori

unread,

Aug 3, 2024, 10:55:56 AM8/3/24

to predkosamprol

I have a Dell Inspiron 5000 with Windows 10 preinstalled. I attempted to install a Linux distro (OpenSuse 42.2) on it (dual booting), but now the BIOS will not recognise my hard drive. I should note this is my first time dealing with UEFI, so I'm a fair bit out of my depth here. I'll list everything I did.

The bootloader would not recognise the DVD drive with the Linux DVD as a bootable device, so I went to the BIOS settings and disabled secure boot, enabled legacy option roms and finally changed the boot list options from UEFI to legacy. I was then able to boot from the Linux DVD and install to a new partition. When installing I left all bootloader settings default. I noted that it used Grub2 and not Grub2-efi.

Upon rebooting the computer couldn't find any bootable device; it went through to some diagnostic checking. I rebooted to the bootloader menu, and under the Legacy heading I was able to select my hard drive which launched Grub. However Grub only showed options for OpenSuse, nothing for dual booting Windows. So I went back to the BIOS settings and changed the settings to how they were before: UEFI, no legacy and secure boot enabled. When I then rebooted to the bootloader menu the legacy heading had vanished along with all options to boot from the hard drive.

I went to the BIOS settings again, and in Boot Sequence the boot sequence was completely empty. So I clicked "Add Boot Option" to add the hard drive as an option. However an error dialogue popped up saying, "Warning: File System Not Found!" This error persisted whether I enabled legacy, UEFI or secure boot.

First off, Legacy Boot (i.e. BIOS mode) is mutually exclusive with "new" UEFI boot mode. A version of Windows installed while the system is in one mode is, to say the least, aggravating to make work in the other mode.

For the moment if Windows is what you care about then we can ignore Linux. As a first step you need to disable the legacy boot option. Your copy of Windows was installed in UEFI mode and so its bootloader is set up differently from a "legacy" BIOS bootloader.

If Windows boots then awesome, if not then you need to break out a bootable Windows USB stick. Microsoft's Media Creator will do this for you. There is an option to do a boot repair in there, it should hopefully fix any problems you might have.

Once Windows is back up and running then we can look at Linux again. Do not switch back to legacy boot. If Linux won't boot in the new UEFI mode then you need to find a distro that will, or find a better way of writing the downloaded ISO file to a USB stick. I've had good luck with both UNetbootin as well as Pendrivelinux in the past. Create a new bootable stick and see if it boots, if it doesn't then try a different distro. When I tried a few years ago Ubuntu refused to boot from USB on my laptop while Xubuntu was fine, same versions supposedly. YMMV. Newer versions of Linux should hopefully be fine.

If, on the other hand, you don't care about your current copy of Windows and booting Linux in non legacy mode refuses to work then you will have to bite the bullet, switch to Legacy mode, format the hard drive as MBR, reinstall Windows, reinstall Linux and carry on that way.

One of the reasons Windows will not boot in Legacy Mode is because Windows is limited to GPT partitioned disks for UEFI mode, and the BIOS (Legacy) mode cannot boot from GPT partitions. Linux can kludge around it, but it's not great for dual booting.

Mokubai's analysis is correct, and I agree that disabling the BIOS/CSM/legacy boot support is a necessary part of recovering. (Well, there are alternatives, but they're likely to be awkward and inferior.) I simply want to offer an alternative means of recovery:

As a side note, some tools for creating bootable Linux installers omit the BIOS-mode or EFI-mode boot loader. This can make them unbootable in one mode or the other. Many people, when confronted with such problems, make the mistake you did of enabling BIOS/CSM/legacy support in the firmware -- but that just creates a bigger problem down the line, as you discovered. Using a tool that creates a bootable medium for your computer and in the desired boot mode is the appropriate response. See this page of mine for my experiences on this topic; however, be aware that there are differences from one distribution to another and from one computer to another, so what works for me with Ubuntu on my computer or for some random person with Fedora on her computer might not work for you with OpenSUSE on your computer. Thus, you might need to try two or three tools or methods before you find one that works.

I have run into this when the drive controller is set to something other than Generic in the image build. If Dell changed the controller hardware then Windows will loose its mind and not know what to do. Go into your base image Device Manager and make sure the Storage Controller(s) are set to Generic.

When you get to the point in Windows Setup where you select where to install it, make sure the entire target disk is shown as unallocated space, with no existing partitions. If you see partitions, delete them so that Windows installs onto an empty disk and can create the desired partitions appropriately.

I have been using SmartDeploy with my current and previous jobs. They have the Driver packs already made (just need to download them) and then create your image in a VM, shut it down, then capture it. Then you create the answer file. From there you create the deployment package with the answer file and driver pack(s). Then you boot it off USB and boom done.

Recently I had some problems with Windows Bitlocker: every time I open Windows I am prompted to enter the Bitlocker password. In trying to solve this, I accidentaly clicked Ubuntu in the "Delete Boot" option in the boot sequence. Now the laptop boots directly to Windows without first loading the Grub menu.

Luckily, when I restarted the system and clicked "add boot option" I found the efi folder in which the Ubuntu folder is present. In Ubuntu there is fwgrupx64.efi, grubx64.efi, grub.cfg, shimx64.efi, mmx64.efi, and BOOTX64.CSV. On clicking grubx64.efi it shows "Boot name not found".

When I create a new config file from an 820 G3, edit it and then import it into a freshly installed 820 G3, I behave the same issue again. The UEFI boot order in the BIOS remains empty. But when I drag a config form the client it shows the boot order correctly in the config file, only apparently it ignores it if some clients still boots from network first.
When I reset the BIOS Settings after a basic installation via BCU, I have entries inside the UEFI boot sequence, but not quite in the order we need, 1pv6 must also be deactivated. If I apply the config again after the reset, it stays empty again.
I use the latest BCU.
The BIOS and the frimeware are also up to date.

I have studied the user guide from the bcu and still get the error. In the log he also writes that he is making the entries.
I hope I could explain what my problem is, english is not my mother tongue.
Any help much appreciated

Occasionally my Ubuntu 10.04 PC won't boot properly. It gets past Grub and then stops at a blank screen and blinking cursor. From what I've read, this blinking cursor screen is presented by Ubuntu itself and not Grub, so I assume the boot process gets halted for some reason. Has anyone any guidance on how to diagnose this issue or what the cause is likely to be? Normally I need to press the reset button to reboot the PC and often it will reboot fine. The fact that it is intermittent is what confuses me.

It's been a while, mainly because my server has been up for a long time. It looks like I've captured a recurrence of this issue, I copied the messages file and the dmesg file and had a look where processing seems to have stopped and found the messages below. I'm going to do some research on Google etc. but figured I'd put it up here in case anyone can help and wants to earn themselves some points. I should mention that the ondemand governor failed message happens on successful boots but the other two don't appear to.

In my case, the blinking cursor was all I would ever get. No boot. It was upon installing a fresh Ubuntu Minimal. I figured out that during the GRUB installation step, it was installing GRUB onto the wrong drive, the "first" drive (/dev/sda).

So, when formatting with a partition table of "mbr" on my 120GB drive, I did the normal 117GB of bootable ext4 and 3GB of swap. On the GRUB installation step, DO NOT choose Yes to put GRUB onto the "first" drive. Choose NO. This will bring up another screen that allows you to input /dev/sdX. In my case, I tried /dev/sdb and /dev/sdb1, but the installer would give me a fatal error every time, which still makes no sense.

Finally, I had to format my 120GB drive with a partition table of "gpt". With GPT, you have to manually create a GRUB partition. That's the way things are done with GPT. So, the first partition I made for GRUB was 32.0 MB formatted for "boot or something (forget wording)". Second partition was my 3.0 GB formatted for "swap", at the "end". Third partition was the remaining space formatted as "ext4".

Now, when choosing NO during the GRUB installation step, manually input /dev/sdb, not /dev/sdb1 surprisingly, and it then works. GRUB installs into the 32MB boot partition on the correct drive and the system boots normally. YAY!

BTW, you have to choose Expert install from the menu at the beginning of the installation to do all this and format your HDD "manually" not "guided". Guided will always choose /dev/sda as the first drive and blinking cursor/no boot will result if /dev/sda isn't your OS drive.

I had a similar issue in the past using the recommended version of a proprietary nVidia driver with a certain video card. The solution was to boot into recovery mode, run the xfix option, then boot into the desktop. Once in the desktop, I would go into the hardware drivers screen and select an older version of the driver.