Not detecting Bootable external drive (USB or SD Card or HDD) in Boot Menu or in BIOS-Boot option

SazzAspire3 said:

[...] found that this is very generic issue with all Acer laptop range and can be fixed by following some steps in Bios [...]

That's... an odd thing to recommend, it wouldn't be my first thought after reading about your problem. Just like you said, all of a sudden after 2 years of it working it doesn't seem likely that the fix has anything to do with changing anything in the firmware settings.

SazzAspire3 said:

[...] At this stage I have run out of options and just came across some more threads which suggested that Acer is on purpose blocking other OS use through BIOS firmware. [...] 

I'm not an expert on Acer systems by any metric, but I find it's just like with any other brand (excluding Apple that is). Newer computers for example can't switch to legacy, so whatever you want to boot has to support the current standard, UEFI.

Its Secure Boot option being optional makes it easy to boot anything that's unsigned (like custom kernels for example), but I've noticed that Acer requires a supervisor password to be set in order to modify the Secure Boot setting. Not a big deal after all.

The main problem with newer models is the SATA operation mode for Intel hardware, but that has more to do with Intel than with the manufacturers. Its RST mode of operation for the storage controllers complicates things in Linux. Per the official documentation when RST is selected it behaves as a software RAID of some sort, and yet in my system for example (10th gen, Comet Lake based) mdadm is unable to see anything connected to the controller ports. It is detected, it perfectly recognizes the Intel RAID controller but states that nothing is in there. Makes me wonder what's going on, but because I can easily switch the SATA operation mode to AHCI, the previous standard in the firmware settings I can access the internal M.2 drive from Linux easily.

They (Acer) did hide the SATA operation mode under a key combination for some models, in the A515-54G that I have the change happened after the 1.11 revision of the firmware; to see it you have to press Ctrl+S in the Main tab. So all in all things continue to be amicable for running OSes other than Windows (and Ubuntu for example has its booting structure signed, so there's no need to disable Secure Boot even).

---

Anyway, now that we're on topic, before addressing Linux I'd like to talk a bit about the problem you were having, not being able to boot into Windows. Assuming you're running under UEFI, you'd need to have an special partition in a GPT based disk.

It's called an EFI/ESP partition, formatted as FAT32, I think Windows sets it to be 100 MB in size, but you can have it larger if you want. Some Linux distros recommend 350 MB for example. The thing is that unlike any other FAT32 partition this one has to have some flags set, in parted/GParted terms it's the esp flag (which sets another on its own), but since we're talking Windows for now I'm going to be addressing it using its native partitioning tools.

That's is where the boot code resides, if a disk is GPT partitioned but lacks that partition or it is corrupted it won't appear in an UEFI boot menu. We'll come back to this partition when we talk about Ubuntu, but for now, know that it can be deleted and re-created from a Windows installation USB for example without major problems.

These would be the steps, assuming you have booted a Windows live environment of some kind (either WinPE, WinRE, or installation media):

1. Access a command prompt, if it's installation media you have booted from press Shift+F10 and one will appear.
2. Then get into the DiskPart program to handle partitions, in the screenshots below whatever is highlighted in yellow is the input you need to type.
   
3. List the disks and select the one that you're unable to boot from, in my case it's disk 0, then show its partitions:
   
   
   
   
4. That will show you the partition structure of the disk, what you see in the picture above is the typical setup for a current Windows version. There's the EFI partition first (#1), one very little reserved for whatever Microsoft needs it to (#2), the main one (#3), and a 4th one which is where the recovery environment resides.
   
   Acer machines may have other partitioning schemes, same as with other manufacturers, what that picture shows is the default for a clean Windows installation anyway.
   
   We're interested in the first one, the EFI partition, it's generally protected you'll see that I'll try to delete it now and it'll tell me niet, unless I know what I'm doing and I use the "override" switch. We're going to mount it instead, assigning it a letter to gain access to it. By the way, the "det" command inside of DiskPart is able to show you details of what you ask it for. For example, "det disk" or "det part" once you have it selected:
   
   
   
   
5. So now the EFI partition is accesible through the letter e in this case, but because of the kind of partition it is you won't be able to see it as a non admin, that rules out the typical File Explorer access, but not from an admin command prompt which is what we need anyway to re-create the boot files. These would be its usual contents for a Windows only installation:
   
   

   E:\
   └───EFI
       ├───Microsoft
       │   ├───Boot
       │   │   │   BCD
       │   │   │   boot.stl
       │   │   │   bootmgfw.efi
       │   │   │   bootmgr.efi
       │   │   │   kdnet_uart16550.dll
       │   │   │   kdstub.dll
       │   │   │   kd_02_10df.dll
       │   │   │   kd_02_10ec.dll
       │   │   │   kd_02_1137.dll
       │   │   │   kd_02_14e4.dll
       │   │   │   kd_02_15b3.dll
       │   │   │   kd_02_1969.dll
       │   │   │   kd_02_19a2.dll
       │   │   │   kd_02_1af4.dll
       │   │   │   kd_02_8086.dll
       │   │   │   kd_07_1415.dll
       │   │   │   kd_0C_8086.dll
       │   │   │   memtest.efi
       │   │   │   winsipolicy.p7b
       │   │   │
   
       ... Internationalization stuff ...
   
       │   │   ├───Fonts
       │   │   │       chs_boot.ttf
       │   │   │       cht_boot.ttf
       │   │   │       jpn_boot.ttf
       │   │   │       kor_boot.ttf
       │   │   │       malgunn_boot.ttf
       │   │   │       malgun_boot.ttf
       │   │   │       meiryon_boot.ttf
       │   │   │       meiryo_boot.ttf
       │   │   │       msjhn_boot.ttf
       │   │   │       msjh_boot.ttf
       │   │   │       msyhn_boot.ttf
       │   │   │       msyh_boot.ttf
       │   │   │       segmono_boot.ttf
       │   │   │       segoen_slboot.ttf
       │   │   │       segoe_slboot.ttf
       │   │   │       wgl4_boot.ttf
       │   │   │
       │   │   └───Resources
       │   │       │   bootres.dll
       │   │       │
       │   │       └───en-US
       │   │               bootres.dll.mui
       │   │
       │   └───Recovery
       │           BCD
       │
       └───Boot
               bootx64.efi
   

   
   
6. So, the interesting part after all, recreating that whole structure, it can be done with a single command (outside of DiskPart already, but still in an admin prompt. I'm not going to run it right now but it has this structure where 'X' is the letter assigned to the main partition where Windows is installed and 'E' is the letter assigned to the EFI partition:
   

   X:\Windows\System32\bcdboot.exe X:\Windows /f UEFI /s E:

   There's another switch, /v if you wanted to see it being more verbose but it's not necessary. The ones I used /f is to specify that the boot files to be created are to be for an UEFI system, and /s is to specify the location where the files are to be created, the EFI partition itself.
   
   
7. After that, we'll need to go into DiskPart one more time to remove access to the EFI partition, just for good measure:
   
   
   
   
8. And that's it, as long as the Windows installation is in a healthy state you should have no trouble booting into it. It will appear in the boot manager as expected.

---

One thing that has me intrigued is what caused those files to be missing, or corrupted in the first place. It's a hidden partition, not mounted by default and inaccessible unless you go through several steps. I do not know what Acer Care does to check the health of the disk, or whether it's able to detect faults in the connection layers, but we could try looking at the disk health ourselves.

Several programs to read SMART data, one that works on both Windows and Linux (I'm attaching a Windows build to this post just in case) is GSmartControl. In the attributes section you can see if there are any sectors that have been relocated, or if there were uncorrectable errors during transmissions, and the statistics tab complements that information.

You can also run disk self-tests from it:

---

Now, Ubuntu... finicky stuff we have here. Its installer is tricky to get working when the SATA operation mode is set to RST. I found that it will not install into an external disk unless it is able to access the EFI partition of the internal disk when run under UEFI.

It seems to be a requirement because instead of creating an EFI partition in the external media, and put there its boot code and loader (GRUB or whatever you choose) it modifies the one in the internal disk. So in effect you'll have an installation that can only be booted in that machine, because when that drive is plugged in some other there'd be no bootloader installed on it.

Assuming that EFI partition of the internal disk is actually accesible, if the problem in your case stems in the connection between the disk and the machine itself you're out of luck. Maybe that's why you couldn't boot Ubuntu any way other than the live way.

Other Linux distributions do things differently, and it's certainly no requirement to have a disk structured with GPT to be bootable under UEFI, it's perfectly possible to use the traditional MBR partition table with a FAT32 active (boot flag enabled) partition and the boot code placed in there. Even for Windows! And that's usually the one that complains the most about how it likes to be run.

I'm afraid at the moment I wouldn't know how to guide you to have Ubuntu installed in an external drive that works in other systems. I'm an Arch guy and because installation there is manual it's easy to first create the partition structure, set the mountpoints and install the OS, but on Ubuntu because ubiquity automates things last time I checked I had to delve into its code to get it work and I desisted.

There is however a way, that should work with Ubuntu too, but since I haven't tried it myself I can't say it for sure. You'd install Ubuntu on a virtual machine, any kind, it doesn't really matter the virtualization software you use, but it does need to be an UEFI virtual machine. Once installed, ubiquity would have created the necessary partitions in the virtual disk for it to be bootable.

The next step would be to connect the external drive or SD card to the virtual machine and clone the internal disk, using Clonezilla for example, to the external one. One could even then expand the filesystems so it makes use of all of the disk space, but because there'd be a proper ESP partition there, if I were to hazard a guess I'd say that external disk or SD card would show up in any UEFI boot menu.

I hope it helps somehow and doesn't add to the craziness you have already experienced, in any case I'll be following this thread, I'm curious to know what happened to that disk.

I was writing as I was thinking and, as usual, didn't give it a second reading, I would have changed some things and fixed some typos now haha 😅

There is at least one more thing we didn't cover though, if the Windows installation was done with the SATA operation mode set to RST switching to AHCI (and vice versa) requires further steps to make Windows boot. Reinstalling is not necessary but a trip to Safe Mode is, so keep that in mind @SazzAspire3 if you play with that option.

I remember years ago when it was the other way around @billsey, when a Windows update would override the MBR of the disk to reinstall its own and get rid of GRUB or Syslinux if they were installed in dual boot scenarios. It would bother me so much at one point with several machines that I just resorted to go the other way around, instead of using a Linux bootloader to chainload into Windows I'd use the Windows BCD to chainload into Linux. No more headaches after updates

But now (well, since Windows 8 I think) there's some prefetching before the boot menu is shown in Windows unless the boot policy is set to legacy, so going that route (if it's even possible, I haven't tried) is a waste if one usually runs Linux, because the machine is actually rebooted after the non-default option is chosen. As if Windows expects to be chosen, but when you choose something else it goes "okay, okay, I'll just discard all I have preloaded and reboot into what you want", even if it is a different Windows installation in another partition.

Aaaaaand I also forgot to attach to that post the Windows build of GSmartControl, tsk tsk... I'm getting forgetful of late. It's pretty much the official one with an updated database for drives, just in case.