For what it’s worth… I find myself in the Windows installer at least once every two weeks (comes with the career) and have never seen it replace a boot loader without me asking it to, either by installing Windows or by running BCDBOOT from the diagnostic command prompt. UEFI generally makes the bootloader “fighting” mess a non-issue.
@User1209 I’m somewhat curious, though . . . you used the Windows 10 installer to install a firmware update with the M.2 drive removed, right? It seems much more likely that the firmware noted that the original boot device was totally missing and removed any registered bootloaders that happened to live on it. It would be wasteful for it to keep them around(^1).
(1): There’s a few variables in the firmware’s NVRAM store that explain how to boot the machine. One of them is BootOrder, and it contains numbers (0000, 0001, 0002, …). The entries it specifies are tried, in-order, until one succeeds. The others are Boot0000, Boot0001, (…) and they contain physical device and file paths. When it’s booted with the device missing, what should it do? Under one school of thought, those entries are stale and will never be valid again. Booting a machine without some of its fixed hardware suggests that that hardware is unlikely to return. Replacing it with a new SSD would cause the same issue, sometimes, because those boot entries occasionally contain device IDs rather than “locations”.
I find myself in the Windows installer at least once every two weeks (comes with the career) and have never seen it replace a boot loader without me asking it to
Lucky you. The Winblows 8 install on my Miix 700 runs an uncommanded chkdsk and self-repair every instance of the once or twice a year I have to go to it. Maybe it’s a Lenovo customization, but I doubt it. This chkdsk / self initiated boot partition restore (overwrites MBR?) kills grub2 almost every time. rEFInd seems to be more resistant to this (or possibly because my rEFInd boot partition is no longer the first on the disk).
Winblows also changes the system clock to local, and borks up USB power regulation, just to be an extra jerk too. All of this and the fact that I can’t reboot the machine without waiting large portions of an hour for updates I don’t / want need to install… Yeah, I avoid MS like the plague now.
Also, as a warning to anyone who does this, my linux boot became unbootable after going through this process, due to the issue I mentioned in this thread:
That’s what happened to me running Windows To Go on my desktop system recently. It rendered my Linux Mint install unbootable.
This was for a firmware update to the WD SN850 SSD which I have to do in my Framework and which I’ll have to do again in both eventually. This is why SSD manufacuters (Sabrent, WD) making firmware updates Windows-only and not publishing the firmware .bin or using LVFS is such a problem.
Simply not buying drives that have Windows-only updaters isn’t an option. They all do this now.
I’m somewhat curious, though . . . you used the Windows 10 installer to install a firmware update with the M.2 drive removed, right?
The two times I booted the W10 installer mentioned in the other thread I linked, I did it without having the drive physically installed in the computer. For the firmware update I just did, I left the drive installed, so it happened in both scenarios (with/without drive installed).
This does not happen at all when I boot up arch install usb stick I’ve been using (it doesn’t mess with any settings at all unless I explicitly tell it to).
I finally got around to doing this. It worked perfectly.
Updating the BIOS was fairly quick. I was not expecting the updating EC/updating PD1/updating PD2 procedures and these took long enough to make me uncomfortable, but they completed and everything’s fine.
And Windows did not mess up my bootloader!
Now I wonder if my SSD updater .EXE will work this way?
I had a similar experience with @User1209. BIOS and other images were installed correctly. However, a new directory was created by this process named /boot/EFI/Insyde, which wasn’t there before, and the grub got nuked. I followed his recommendation and re-installed grub from a live arch linux installation medium with the following command found at wonderful arch wiki:
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
Please make sure you run this command after chrooting in your system and not from the installation medium. I had a LUKS encrypted drive, there were a few more steps that took me an hour or so to figure out in total.
Hope this helps to the next individual who may experience this issue.
I have a question on this.
So framework does use insyde bios, right? I happen to have a Lenovo Yoga notebook and I am also looking for a solution to update my bios without having to install Windows.
So my question is: is the update program from framework a GUI application or is this just a “dos-like” application? Can you even start graphical programs from Windows Installer command line? Because Lenovo is shipping the updates with a GUI that looks like a program from 1995.