GRUB bootloader and BIOS weirdness

I’ve been experiencing some very strange behavior with either the bootloader, or the BIOS not recognizing the bootloader.

The issue seems to occur under the following circumstances.

  1. Using DD under linux, I copy a W10 ISO downloaded directly from microsoft’s website over to a USB drive.
  2. I physically remove the M.2 drive from the computer (which contains my arch linux install, and the GRUB bootloader), so it is not plugged in.
  3. With no drive inserted, I boot up the computer using a Windows 10 installer from USB.
  4. I go through the process of trying to install windows on another USB drive, which of course windows doesn’t like. (the purpose of which is to try and update the firmware since LVFS isn’t ready yet)
  5. I stop the installation process when, for whatever reason, the windows installer complains about a missing driver and can’t even find the other USB drive I’d plugged in. It can’t even find it when I look for it in the command line, listing the drives. Note that at this point, I haven’t made any changes to any of the drives or done much of anything except click the “next” button 2 times to try to start the install process (I haven’t selected a drive yet or anything). The installer will not let me continue until I find whatever driver it’s looking for (it doesn’t tell me what driver specifically).
  6. I turn off the computer, unplug the W10 install USB and the USB drive I intended to install windows on. Then I plug the M.2 drive back in that has my main OS install.
  7. I let the computer sit like this for a period of several hours, (this is my second attempt at trying different things to get the firmware flashed, and because I’m kind of tired of trying to get it to work, I let the computer sit for a while before touching it again)
  8. I power up the computer, only to be greeted by a message about a missing boot device.

This is the second time I’ve had this happen to me. When the first time it happened, I had left the M.2 drive out of the computer overnight, then plugged it back in the next day which is the only difference.

The only way to get it to boot from the M.2 drive again is to plug in an arch install USB, then re-install the bootloader using this guide: How to Reinstall the Boot Loader in Arch Linux

Then after doing this, it boots back up fine, again, and continues to work after multiple reboots.

I don’t know what’s causing this to happen. Maybe the W10 installer is having some kind of weird interaction with the computer firmware which is making it not recognize the bootloader on the M.2 drive anymore.

I’m pretty sure there’s nothing wrong with the drive itself, since this only happens when I go through the above W10 installer steps. I can confirm that secure boot is disabled on the laptop. I don’t think this is happening because of a system update for the main OS install, as it’s never been an issue before and only happens when I go through the above sequence.

Here’s the bottom half of the pacman output from an update I ran just now (everything after updating of specific packages).

[2021-11-04T01:36:06-0700] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: ‘default’
[2021-11-04T01:36:06-0700] [ALPM-SCRIPTLET] → -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2021-11-04T01:36:06-0700] [ALPM-SCRIPTLET] ==> Starting build: 5.14.16-arch1-1
[2021-11-04T01:36:06-0700] [ALPM-SCRIPTLET] → Running build hook: [base]
[2021-11-04T01:36:06-0700] [ALPM-SCRIPTLET] → Running build hook: [udev]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [autodetect]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [keyboard]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: xhci_pci
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [keymap]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [modconf]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [block]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [filesystems]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [fsck]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] ==> Creating zstd-compressed initcpio image: /boot/initramfs-linux.img
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] ==> Image generation successful
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: ‘fallback’
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] ==> Starting build: 5.14.16-arch1-1
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [base]
[2021-11-04T01:36:07-0700] [ALPM-SCRIPTLET] → Running build hook: [udev]
[2021-11-04T01:36:08-0700] [ALPM-SCRIPTLET] → Running build hook: [keyboard]
[2021-11-04T01:36:08-0700] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: xhci_pci
[2021-11-04T01:36:09-0700] [ALPM-SCRIPTLET] → Running build hook: [keymap]
[2021-11-04T01:36:09-0700] [ALPM-SCRIPTLET] → Running build hook: [modconf]
[2021-11-04T01:36:09-0700] [ALPM-SCRIPTLET] → Running build hook: [block]
[2021-11-04T01:36:09-0700] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: aic94xx
[2021-11-04T01:36:10-0700] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: wd719x
[2021-11-04T01:36:10-0700] [ALPM-SCRIPTLET] → Running build hook: [filesystems]
[2021-11-04T01:36:11-0700] [ALPM-SCRIPTLET] → Running build hook: [fsck]
[2021-11-04T01:36:11-0700] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2021-11-04T01:36:11-0700] [ALPM-SCRIPTLET] ==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-fallback.img
[2021-11-04T01:36:12-0700] [ALPM-SCRIPTLET] ==> Image generation successful
[2021-11-04T01:36:12-0700] [ALPM] running ‘90-packagekit-refresh.hook’…
[2021-11-04T01:36:12-0700] [ALPM] running ‘dbus-reload.hook’…
[2021-11-04T01:36:12-0700] [ALPM] running ‘gtk-update-icon-cache.hook’…
[2021-11-04T01:36:12-0700] [ALPM] running ‘texinfo-install.hook’…
[2021-11-04T01:36:12-0700] [ALPM] running ‘update-desktop-database.hook’…

I’ve been watching the output of pacman -Syu more closely after it happened the first time, the only thing that stands out to me is mention of possibly missing firmware (toward the bottom of that log), but I can confirm the computer still reboots just fine right now after this update. The output for the previous update looks identical.

Edit: I’ve found mention that these missing firmware modules aren’t important for most people. mkinitcpio - ArchWiki

Edit 2: If I had to guess, the W10 installer is either corrupted somehow by using dd to install the image onto the flash drive, or it could be that W10 doesn’t play nicely with the BIOS and wants to be the sole OS install on the computer. (Though this is very strange since the M.2 drive is physically not attached to the drive during the process, so it can’t even touch the M.2 drive, and no one else has had issues with dual boot as far as I’ve read).

Has anyone else experienced any kind of similar issue?

2 Likes

I don’t have my framework yet (sadly) but if I remember correctly, Windows 100% overwrites the existing bootloader with its own. If you use a live linux disk like Ubuntu and run grub-repair, you should be able to put GRUB back on and it will recognize both OSs.

Well, I had physically removed the M.2 drive so that windows installer couldn’t even access it. How can it override the bootloader if there is no bootloader for it to touch?

I was trying to install windows on one of the expansion cards, not the M.2 drive, but wasn’t even able to do that because it complained about a missing driver (which it would not tell me what the driver needed was), so I had to cancel the install process because it would not let me proceed without it. It must be doing something to the BIOS to prevent the removed drive from being boot-able upon plugging it back in.

Regardless, I more or less did what you described, but by just manually regenerating the bootloader with an arch install USB drive.

1 Like