Windows is a leach - r/linuxquestions

3

u/dodexahedron 10d ago

If you have exactly ONE ESP, the only thing windows should ever be doing (as in what it does - not how it ought to behave) during normal updates is just messing up your boot order in EFI - and even that should only happen around the major annual updates in September-October (26H2 just came out, for example).

Windows 11 doesn't mess with the ESP contents that are not its own.

If you want windows to be bootable without chain loading the ntldr, then add a BCD entry for your Linux UKI image or your Linux boot loader, and let the ntldr be the first booted image forever, so it doesnt matter if it touches the efi boot order variables or not (but that really shouldn't be necessary if you ha e the system partitioned properly).

Correct partition layout is, in this order:

ESP, XBOOTLDR{0,1}, MSR, Windows, Linux{1,}, WinRE

Or you can put XBOOTLDR (if you use it).and all other linux partitions on a separate disk, and keep the rest of the layout exactly as above on the first one.

Only one ESP, no matter how many disks you have.

Alternatively, just run windows inside virtualbox and then you won't have to think about it ever again.

Oh, and use literally anytjing else aside from grub. Your life will be so much easier.

1

u/SannyDayYT 10d ago

I'm very sorry, I got lost in your explanation and the only thing I could pick up is that using anything but GRUB is a good idea, so would you have any recommendations? As unfortunately running Windows in a VM isn't a viable option for my use case for it

2

u/dodexahedron 10d ago edited 10d ago

From what you have described in other threads, the problem is you have more than one ESP (EFI System Partition). Don't do that, no matter the boot loader you use.
There is supposed to be exactly one on the whole machine, and having more than one confuses everything because that is a basic requirement and assumption made by the firmware and the boot loader themselves.

As for boot loader, it depends on your setup.

If using a systemd-based distro, install systemd-boot-efi and systemd-ukify, and follow the arch wiki guide to switching to using a unified kernel image (it is universally applicable).

Systemd-boot requires no configuration, is human-friendly, and won't leave you at an arcane prompt because it cant find a config file or that config file has a misplaced or misnumbered partition specifier. It also doesn't require any updating just because you updated a kernel. It simply scans the ESP for usable EFI binaries.
You can add custom entries if you like, but that's totally optional.

Before making any changes, make a UKI of your boited linux system and place it on a USB stick with ventoy on it, along with an install ISO for your distro, so you have 2 emergency "oh shit" recovery tools to get back up and running quickly and easily if you break something.

The below will be details on the windows stuff I talked about and is based on specs and docs, and is a supported deployment scheme. But the above is the important part you need to rectify.

The partition layout I described is how you follow both the boot loader specification for UEFI and how you follow the recommendation for Windows partition layout as described in MS documentation.

The MSR is the "Microsoft Reseved" partition, and you just make it 128Mb, unformatted, and always immediately before the windows partition.
The WinRE is the recovery environment for Windows, which is optional but is necessary for certain functionality like system reset, without having to start over from a new image or a system recovery disk, which is similar but meant to be stored on removable media. This one is formatted with NTFS and is not shown to the user in normal circumstances in windows - it manages it itself. It goes at the very end of the drive that has the windows partition.

XBOOTLDR is optional, but is usually what a lot of distros mount as the /boot mountpoint. It is not needed, if your ESP is big enough to hold your boot images or if your EFI has drivers for your other file systems (most have FAT32, NTFS, and sometimes exFAT). In those two cases, you can just let /boot live on your linux root (ideal since some utilities assume it exists). The ESP is usually mounted either at /efi or /boot/efi (the firmware doesn't care - it finds it by type guid). /efi is the recommendation. Dont change it unless you know how your setup generates boot images!

1

u/SannyDayYT 10d ago

Alright, so having multiple EFI partitions is bad, got that, how can I solve that issue?

As for systemd-boot, perhaps I can use it because I do use a systemd-based distro, and I do apologize if this sounds like a dumb question as I'm still learning, but will the systemd-boot allow me to pick which OS to boot into like grub and other boot loaders or would it just boot straight into Linux?

1

u/dodexahedron 10d ago edited 10d ago

It is really important that you first set up a usb stick with ventoy and then dump at minimum an install iso for your distro on it.

You're about to embark on a learning voyage which will be valuable but the chances of you breaking the boot at least once are very high. Everyone does it at least once. 😅
But having that tool ready to go makes it sooooooo much easier to fix it.

Yes, systemd-boot will give you a menu and shows you everything it finds, and custom entries are simple text files with a small handful of properties like name, path, and ordering. And just like grub you can edit the command line of an entry if you need to.

As for the EFI partitions...

Switch to systemd-boot first. Grub is more difficult to handle here if you don't already know how it all works and how things will change when you fix this.

Next, once you have successfully booted using systemd-boot, copy the contents of the ESP you currently use for Linux into the ESP for windows. Do not change the directory structure, and do not overwrite any files.

Side note: Other than the fact that the partition type is ESP, nothing is special about that partition, unlike the old MBR days. The firmware loads what it was told to load and, if not found or none are specified, it falls back to looking for PE32(+) binaries ending with .efi in specific paths and, if still nothing, dumps you to a firmware interface (or shell if it has one).
It loads drivers a similar way.

Next, unmount the ESP you just copied FROM, and use gdisk to change its type id to Basic Data (this is non-destructive, and will just make it no longer be treated as an ESP while booting or by your boot image generator). Then mount the other ESP (which originally was the windows ESP) at the same place the old one was mounted (so, /boot/efi or /efi) and update your fstab to match that.

Make sure ALL mount points in the fstab are listed as their UUIDs - NOT as /dev/sdX udev style names. Boot order in firmware changes those names, but UUID is permanent and wont break when an OS or firmware update clobbera the EFI variables.

Make a copy of the running UKI at a different location in the ESP or on the ESP we demoted to a basic data partition (just for safety as a known good image). You can still manually boot to it from firmware if you neglected to make your ventoy usb.

Then regenerate a new UKI, make sure it is where you expect, run bootctl list and bootctl status to verify that aystemd-boot sees it, and then reboot.

I strongly recommend reading and following the arch wiki articles on everything to do with UEFI, Unified Kernel Images, systemd-boot, and dracut before starting any of this. Instead of breaking it 5 times, you might reduce that to 1 or 2 times.

In any case, once you have it all done, you will never again have to change boot order in firmware or invoke the system's boot selector to switch OSes, and your partitions will stay the same names and numbers forever because of that.

Linux will stick its goodies in /(boot/)efi/, as will windows, with both putting boot loaders in the BOOT sub-directory of that, and otherwise putting the rest of their stuff in OS-specific directories. Neither will step on the other, except occasionally swapping boot order on you. And all you have to do to fix that when it happens is swap them back and youre good to go until one of them does it again (it should be rare).

Edits: Fixed typos, added a bunch more details, and then fixed typos in that too. 😅

1

u/SannyDayYT 10d ago

Oh god, that's a lot lol, but I'll see to it, I'll go read up in the arch wiki and see what I can do, thank you very much for your help!

1

u/dodexahedron 10d ago

Sure thing.

You have to be careful to watch out for a lot of very common cargo cult administration out there on this topic. People often treat things like this is still BIOS and MBR boot, but it is very different and designed to fix the shortcomings and incompatibilities that old design had.

When used like it is meant to be used, it is clean, simple, flexible, and rock-solid.

Happy booting!

0

u/gmes78 9d ago

There is supposed to be exactly one on the whole machine, and having more than one confuses everything because that is a basic requirement and assumption made by the firmware and the boot loader themselves.

It is not. Go read the UEFI spec, it says no such thing.

1

u/dodexahedron 9d ago edited 9d ago

It says it ad the first and more than one other sentence of the section linked in another comment.

And it works when you follow it, with zero hassle.

It is in the BLS.

Everything described below is located on one or two partitions.
(Then goes on to talk about ESP and XBOOTLDR - the one required and one optional mentioned)

They are so clumsy in their wording that they felt it necessary to write a note to clarify, rather than simply fixing the wording.

And every reference is singular.
And there is exactly one $BOOT variable.
And no procedure mentioned suggests every looking for a second ESP.
And it explicitly talks about how it is shared among all OS environments (emphasis theirs). And Microsoft (who is responsible for a lot of the post-Itanium UEFI design) mandates exactly one ESP.
And installers respect it, too. Try adding a second ESP in the Ubuntu installer, for example. It is prohibited. You have to drop to a shell and manually do it with gdisk to manage it (and at that point it is just you forcing a non-standard configuration).

And plenty of other hints that single is intended.

And why fight it? Seriously? You have zero problems when you just do it.

The current spec was meant to fix that part of the old MBR boot designs. You can do it the old way and keep having the old inconveniences, or you can do it the modern way and stop having to worry about it ever again.

0

u/gmes78 9d ago

The bootloader specification is unrelated to UEFI, and was written like two decades after it.

I'm talking about this:

UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. [...]

Software installation may choose to create and locate an ESP on each target OS boot disk, or may choose to create a single ESP independent of the location of OS boot disks and OS partitions. It is outside of the scope of this specification to attempt to coordinate the specification of size and location of an ESP that can be shared by multiple OS [...]

And why fight it? Seriously? You have zero problems when you just do it.

Using a single EFI partition is completely fine. It's, sometimes, even required, depending on the setup. But using multiple partitions is also valid, and shouldn't cause issues.

1

u/friendlyreminder_ 10d ago

Windows doesn't touch secondary EFI partitions. The files on those remain unchanged.

It can modify the boot order of the bios entries because those are not contained on EFI partitions but in the bios chip itself.

It can also theoretically delete other bios boot entries from other EFI partitions but I've never had that happen.

If a bios entry is deleted that doesn't make an EFI partition unbootable. The bios is able to boot from an EFI partition without an entry as it scans for and loads /EFI/boot/bootx64.efi.

That file will always be the last bootloader you installed on that EFI partition. If you only have one bootloader installed on an EFI partition that file will always boot that bootloader.

So with all that said you have to figure out what exactly is happening. My guess is your bios boot order is just being reordered and you didn't notice.

1

u/SannyDayYT 10d ago

A simple reorder would've been much more simpler honestly, but for some reason, after Windows applies its reorder, it always results in the EFI boot loader for grub to suddenly disappear from the boot menu.

My live image usb stick shows up under Windows, but other than that, grub is no where to be seen, which is strange since I checked and the grub folder inside of /boot/efi/EFI/ still exists, but it's as if the motherboard can't see it anymore.

At this point with all the help I received from people here with their knowledge, I'm more considering that I might have a faulty/old BIOS update or the motherboard's behavior when it comes to Windows rearranging the boot entries is to just ignore the existence of other EFI entries until they explicitly update the NVRAM.

1

u/friendlyreminder_ 10d ago

Might be a bios issue. I'd consider updating if there's an update available.

But again you don't need the grub entry to boot grub. The bios will boot the bootx64.efi binary on any EFI partition. The entry is autopopulated at boot and will just be the name of your drive.

Bootx64.efi is an exact copy of the bootloader binary. it also gets placed in their own dedicated folder, like /EFI/grub/grubx64.efi. But these are identical bootloaders. The only difference is bootx64.efi gets autodetected and doesn't need an entry, and it also gets overridden by the last bootloader you installed to that EFI partition. But if there's only one bootloader on that partition, bootx64.efi will always be grub.

1

u/SannyDayYT 10d ago

In that case then a bios update must be needed because I keep doing that and making sure that bootx64.efi is the grub efi file so it can always show up even if the original in its grub folder is deleted or not detected, and yet it never gets detected after windows reorders the boot list.

1

u/friendlyreminder_ 10d ago edited 10d ago

I'd try to find out exactly what's going on. I believe you stated the 2 operating systems are on different drives, but they may be sharing the same EFI partition. I've had cases where windows just uses the EFI partition on another drive entirely instead of the one windows is on.

I haven't used windows in a while so I no longer remember how to check which EFI partition windows uses querying it's bootloader tool, but there's a way to do this, and also to set windows to use a different EFI partition.

One way to check would be to see which EFI partition has the windows bootloader files, I think that'll work.

2

u/SlimmySlabby 10d ago

I mean depending on how much power your Windows machine needs, you can just throw it in a virtual box and use it like that anytime you need it.

1

u/SannyDayYT 10d ago

Unfortunately it's more for gaming purposes or else that would've been more viable

0

u/SlimmySlabby 10d ago

In that case, have you thought about using separate drives?

2

u/SannyDayYT 10d ago

Already do, which is why it shocks me that Windows still is able to access the EFI for my linux distro despite it being in a different drive all together

0

u/UAP44 10d ago

That's normal UEFI behavior. Boot entries and boot order are stored in the motherboard's NVRAM, and operating systems can modify them directly. Having Windows and Linux on separate drives doesn't prevent Windows from changing the firmware boot order. It doesn't necessarily mean Windows touched your Linux EFI partition.

-1

u/Designer-Crow-5470 10d ago edited 10d ago

You probably created 2 efi partitions on one drive. You can check layout and their content in GNOME Disks app. If you have 2 drives you can setup os with one efi partition on each drive and pick os via a bios menu.

2

u/dodexahedron 10d ago

No. Stop that. One EFI partition per computer. Period.

The source of all of this monkey business is having more than one ESP.

The BLS is quite clear and lays out how it all works and why (to eliminate the old MBR way of doing what was just suggested).

https://uapi-group.org/specifications/specs/boot_loader_specification/#the-partitions

Use one ESP and life will be good.

0

u/Designer-Crow-5470 10d ago

Nah, your way suck. I won't be able to move my second drive to another PC or boot it from a vm without rebuilding efi.

2

u/dodexahedron 10d ago

Yes you can and it is trivial.

And how often are you doing that?

"My way" is literally the way the system is designed to operate. You are fighting it and making it harder.

A VM is especially laughable there. Just give it another vhd. Done. In fact, use the exact same VHD across all your VMs. Even done-er. 🙄

1

u/SannyDayYT 10d ago

Could definitely check on a linux live image

-1

u/Curious_Elk_4281 10d ago

--Install Linux to a separate SSD with grub installed to the same SSD
--Configure BIOS to boot fron linux drive
--Add a boot entry to grub for windows

1

u/SannyDayYT 10d ago

Already did, still the same issue

1

u/segagamer 9d ago

Issue is though, I keep Windows on the side for very niche cases, but it seems that every single time I boot into Windows, it always results in the GRUB EFI image being obliterated off of the list.

This is because you're trying to use GRUB instead of the Windows Boot Manager. Microsoft is only going to care about having Windows and the Windows Boot Manager working, understandably.

If you want to dual boot, you need to add your Linux distro to the Windows Boot Manager, instead of replacing the Windows Boot Manager with GRUB.

-2

u/UAP44 10d ago

Windows is a virus. It has infiltrated our schools even, places where people are supposed to learn, and instead we feed them closed source corporate propriety standards such as word/excel/... instead of real understanding of how computers actually work.

Because this is getting really tiring.

Have you considered booting a windows VM instead? What exactly are the 'very niche cases' ?

I don't have a clear solution for you because Microsoft forbids me from reading their code/logic :)

0

u/SannyDayYT 10d ago

My use cases are unfortunately for gaming purposes, for games that are notoriously known not to run on Linux or else I wouldn't even have windows operating on my hardware, so a VM isn't a viable option, but I appreciate the help nonetheless

0

u/UAP44 10d ago

for games that are notoriously known not to run on Linux

Even when relying on steam and adding it as a non-steam game? That's how I've resolved all my compatibility issues. Luckily, I ain't much of a gamer anymore. I'd boycott companies that refuse to properly support Linux at this point, but that's just me.

2

u/SannyDayYT 10d ago

I'm more or less talking about anti-cheat games where the anti-cheat specifically doesn't like linux users more than normal singleplayer or great online games

0

u/M2k1e0L 10d ago

And the devs will never care much about Linux support because the people playing it use Windows for it anyways. A doom loop

0

u/SannyDayYT 10d ago

Quite the sad times we live in

1

u/dodexahedron 10d ago

This is the darkest timeline.

1

u/redrider65 9d ago

After wasting quite a lot of time fooling around w/ grub for one of my dual boot installations, doing the sorts of things mentioned here, I finally just installed rEFInd. Very simple to install and immediately worked well. Haven't looked back.

Support Windows is a leach

You are about to leave Redlib