brent As you said, Tom, I have the 1 (Solus) and 2 (W10) boot orders set so maybe I will be fine if I have success later.

Yes, and if your computer runs okay the way it is currently set up, with Linux Boot Manager first, Windows Boot Manager second, and a mess of other bootloaders down the list, it might make sense to just leave it alone. Don't fix what isn't broken, and all of that. I wouldn't feel any pressure to clean up the bootloaders unless/until you need to do so. I'm a bit nuts about running the cleanest build possible on every computer (too many years in IT, most likely), and it is probably overkill to spend much time trying to clean up bootloaders if the computer is working okay.

brent BUT----I am seeing ways to accomplish this in CMD---but CMD is nowhere as forgiving as the linux terminal for me.

If you haven't used it in a while, it can seem forbidding. But it isn't rocket science.

In Windows 10, here is what you do:

(1) Right-Click on the "Start" button.
(2) From the menu that opens, select "Windows PowerShell (Admin)".
(3) Windows will ask you if you want to give PowerShell rights to make changes to your computer. Click "OK".
(4) When the PowerShell window opens, type "bcdedit /enum firmware".
(5) That will give you a list of your bootloaders.
(6) To delete a bootloader, run this command: "bcdedit delete {identifier}" (the squiggle brackets are important).
(7) Repeat as needed, running "bcdedit /enum firmware" after each delete to refresh the list.

This is a sample from my Solus dual-boot computer. It has two bootloaders -- Linux Boot Manager and Windows Boot Manager.

Please note that the "Firmware Boot Manager" has a ""displayorder" entry. That lists all of the installed bootloaders in order of call. In my case there are only two, but in your case there should be many. After the "Firmware Boot Manager" section, you will see a series of sections describing each bootloader listed in the "displayorder" entry, not necessarily in any recognizable order (I think that the sections are ordered by date of creation, but I'm not sure).

I've highlighted the "identifier" for Windows Boot Manager and the Linux Boot Manager as well as the "description" of each boot manager. You could also just take the identifiers off the "displayorder" list in the "Firmware Boot Manager" if you want to do that. The "identifier" might be a short description like {bootmgr} or a long string of letters and numbers or a grub entry. Each will be unique.

The only trick to this in your case is to leave the Linux Boot Manager, and Windows Boot Manager untouched.

        tomscharbach The only trick to this in your case is to leave the Linux Boot Manager, and Windows Boot Manager untouched

        I'm up for the challenge! Great tutorial. Will boot into 10 and give this a whirl later. Thanks again.

          tomscharbach Strangely, Solus' efibootmgr --verbose saw the same 4 drives as Win10....maybe my BIOS always showing a dozen entries from 'usb uefi, 'usb key' 'dvd hd'--------maybe these permanent dozen entries are generic anticipators for boot order and not relics of the past?
          I misjuged efibootmgr and misinterpreted these dozen entries in ambios. Apparently.

          Anyways, for your perusal:
          PS C:\Windows\system32> bcdedit /enum firmware

          Firmware Boot Manager

          identifier {fwbootmgr}
          displayorder {bootmgr}
          {9d47e795-7c05-11ec-8ca0-448a5bd1fd6d}
          {7c330c4e-7b87-11ec-a13f-448a5bd1fd6d}
          {7c330c4d-7b87-11ec-a13f-448a5bd1fd6d}
          {7c330c4c-7b87-11ec-a13f-448a5bd1fd6d}
          timeout 1

          Windows Boot Manager

          identifier {bootmgr}
          device partition=\Device\HarddiskVolume1
          path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
          description Windows Boot Manager
          locale en-US
          inherit {globalsettings}
          default {current}
          resumeobject {7c330c51-7b87-11ec-a13f-448a5bd1fd6d}
          displayorder {current}
          toolsdisplayorder {memdiag}
          timeout 30

          Firmware Application (101fffff)

          identifier {7c330c4c-7b87-11ec-a13f-448a5bd1fd6d}
          description UEFI: Built-in EFI Shell

          Firmware Application (101fffff)

          identifier {7c330c4d-7b87-11ec-a13f-448a5bd1fd6d}
          description CD/DVD Drive

          Firmware Application (101fffff)

          identifier {7c330c4e-7b87-11ec-a13f-448a5bd1fd6d}
          description Hard Drive

          Firmware Application (101fffff)

          identifier {9d47e795-7c05-11ec-8ca0-448a5bd1fd6d}
          device partition=\Device\HarddiskVolume1
          path \EFI\Microsoft\Boot\bootmgfw.efi
          description Windows Boot Manager
          PS C:\Windows\system32>

          ....so there is no linux bootloader because I've never dual booted yet.
          I don't know what displayorder is.
          As for the 4 firmware entries, the built in uefi shell is ambios' "terminal" for lack a better word. I need to keep this, right?
          Next, optical drive. I use it regularly and have booted isos in it. Do I need it?
          Next, I don't know what this "hard drive" is. Solus was not plugged in so I can remove this.
          Lastly, WIN is looking at its own boot partition? Keep it, right?
          Thanks Tom.

              brent If I understand you correctly, both Windows Powershell /enum firmware and Solus efibootmgr --verbose show identical UEFI/EFI bootloaders, but your BIOS shows additional bootloaders. I'm not sure what the reason for this might be, but perhaps the additional bootloaders are not UEFI/EFI bootloaders. I just don't know.

              Of the bootloaders listed above, {bootmgr} is the current Windows Boot Manager.

              I think that the last entry -- identifier {9d47e795-7c05-11ec-8ca0-448a5bd1fd6d} -- is an old Windows Boot Manager from the original Windows 10 installation on the computer, but I am not sure about that. It is entirely possible that it is a repeat of {bootmgr} although I don't think so. I would not remove it and take the chance of bricking your Windows installation.

              The others -- {7c330c4e-7b87-11ec-a13f-448a5bd1fd6d}, {7c330c4d-7b87-11ec-a13f-448a5bd1fd6d}, and {7c330c4c-7b87-11ec-a13f-448a5bd1fd6d} -- all seem to be related to the computer's system components that you use at present.

              The displayorder shows that the computer will try to boot from the various bootloaders in this order:

              (1) {bootmgr} -- Windows Boot Manager (current)
              (2) {9d47e795-7c05-11ec-8ca0-448a5bd1fd6d} -- (probably the original W10 bootloader)
              (3) {7c330c4e-7b87-11ec-a13f-448a5bd1fd6d} -- Hard Drive (the drive connected to the SATA 0 slot)
              (4) {7c330c4d-7b87-11ec-a13f-448a5bd1fd6d} -- CD/DVD Drive
              (5) {7c330c4c-7b87-11ec-a13f-448a5bd1fd6d} -- UEFI: Built in EFI Shell

              In other words, the computer will look down the list until it finds something that is bootable, and then it will boot from that ...

              If it were my computer, I would leave well enough alone at this point -- that is, don't delete any of them.

              And since (a) neither Windows Powershell /enum firmware nor Solus efibootmgr --verbose show any of the other bootloaders that BIOS shows, and (b) you can't get at them through BIOS settings, I think you will just have to live with them.

              In short, put your Solus drive back into the computer, set the boot order (using BIOS) so that Linux Boot Manager is at the top of the list, Windows Boot Manager is second on the list, and the rest fall where they may, and start enjoying your dual-boot computer.

              Thank you for working with me this long discussion. It has been interesting and I've learned from the discussion and from you.

                  tomscharbach If I understand you correctly, both Windows Powershell /enum firmware and Solus efibootmgr --verbose show identical UEFI/EFI bootloaders, but your BIOS shows additional bootloaders. I'm not sure what the reason for this might be, but perhaps the additional bootloaders are not UEFI/EFI bootloaders. I just don't know.

                  You understand this correctly in every way including the nuances. If the entries weren't empty templates then these additional bootloaders makes sense based on anecdote: computer store owner said this was his very own gaming rig (I'm not a gamer, just wanted something better) and likely a rig he tested on as well.

                  tomscharbach I think you will just have to live with them.

                  I think so, too.

                  tomscharbach The others -- {7c330c4e-7b87-11ec-a13f-448a5bd1fd6d}, {7c330c4d-7b87-11ec-a13f-448a5bd1fd6d}, and {7c330c4c-7b87-11ec-a13f-448a5bd1fd6d} -- all seem to be related to the computer's system components that you use at present.

                  this is what I'm taking away as well. Sata 1 is Solus, but the circuit board type is so small I'm not sure I have a SATA 0. But well enough alone.

                  tomscharbach Thank you for working with me this long discussion. It has been interesting and I've learned from the discussion and from you.

                  ^^^ This is reverse. I'm grateful you can see the things I'm trying to say and get them right. I trip over my tongue a lot.

                  Will check in tomorrow . Eager to see it work in the morning and turn the box upright and get this monitor out of my face!

                  SOLUS MODS AND OP: thanks for letting me run with this without complaint. OP and Tom and Bruce made me realize (they didn't know it) I am probably playing a reckless game having only one operating system for the last 3 years and putting all eggs in one basket as far as hardware and OS goes...this thread made me think I might need a backup plan since internet is part of my commerce...and had to make it happen.

                          tomscharbach I finally did this and it worked. Thanks for helping me bring peace of mind (a backup OS) back into my life. It's not a true dual boot with a splash screen and unified boot, but it's something subtle and better: two independent entities controlled by F11 (bios boot order window) on startup.
                          Again, thanks for your help.

                              brent I finally did this and it worked. Thanks for helping me bring peace of mind (a backup OS) back into my life. It's not a true dual boot with a splash screen and unified boot, but it's something subtle and better: two independent entities controlled by F11 (bios boot order window) on startup.

                              I'm glad it worked out for you. After numerous attempts to implement traditional (dual-drive but shared boot partition) dual boot, which never seemed to remain stable for long, I set up the dual-boot, dual-drive, dual-partition on my Solus computer about four years ago, and it has been stable since then. I didn't invent the method. I read about it somewhere and thought "This makes sense ..." so I tried it.

                              I can see how the method I use might not work well for folks who switch back and forth ten times a day (no splash screen, no boot menu every startup), and it almost certainly wouldn't work for anyone booting into three or more operating systems, but it works well for folks like me who use Solus 90-95% of the time, booting into Windows only occasionally (we don't have deal with a boot menu every time we boot -- just boot and Solus opens, no fuss, no bother).

                              A caution to keep in mind: Windows updates on "Patch Tuesday" (the second Tuesday of every month), and the Patch Tuesday updates almost always require a reboot. I'm careful to always F12 (F11 in your case) into Windows on restart. It doesn't seem to do any harm when I forget (Windows picks up with installing the update when I next boot into Windows) but I think that it is the better practice to let Windows complete the update process before returning to Solus.

                              I'm glad we had the opportunity to dig into the issues (including your computer's locked-down BIOS). I learned a lot from your experiences. Thanks for sticking with it and sharing.

                                  tomscharbach and it almost certainly wouldn't work for anyone booting into three or more operating systems

                                  in theory? unless distros were perfectly installed alongside solus? curious.

                                  tomscharbach but it works well for folks like me who use Solus 90-95% of the time, booting into Windows only occasionally (we don't have deal with a boot menu every time we boot -- just boot and Solus opens, no fuss, no bother).

                                  Exactly my case as well. 5%. (Scribus, the best open source desktop publisher, still cant hold a candle to proprietary desktop pubishers like quark and affinity so that would be my 5%---I loathe being that guy but sometimes you need what you need). Thanks for the patch Tuesday info.

                                  tomscharbach . I learned a lot from your experiences. Thanks for sticking with it and sharing.

                                  Me as well. Appreciate it.

                                          brent tomscharbach and it almost certainly wouldn't work for anyone booting into three or more operating systems

                                          in theory? unless distros were perfectly installed alongside solus? curious.

                                          I was just musing, I guess. The folks who install more than a single distro and Windows seem to install a lot of distros, bouncing back and forth between them with frequency. That's just my impression, though, based on folks on this and other forums who talk about the half dozen distros they've installed and use. I guess my method would work if the person used one distro almost all of the time, but using a unified loader would make more sense if the person flipped back and forth between several distros in the course of daily work. That's all I was thinking.

                                              tomscharbach The folks who install more than a single distro and Windows seem to install a lot of distros, bouncing back and forth between them with frequency.

                                              That's one of the best arguments for virtual machines I've ever heard. One could have 20 or 30 VMs with all kinds of distros, and just start them up one or two at a time, as needed. No rebooting required. No complicated bootloaders required.

                                                  WetGeek That's one of the best arguments for virtual machines I've ever heard.

                                                  I agree. VMs are the way to go -- easy install, easy remove, no mucking around with the hardware at all. As I see things, bare metal installations are for operating systems used as daily drivers (in my case Solus and Windows), VMs for everything else.

                                                    a year later