General Suggestion : Installer should create dedicated ESP for each multi-boot installation

Project Discussion
,
1

I suggest changing the installer behavior for multi-boot.

Currently, the Anaconda installer shares the existing ESP ( EFI System Partition ) if user chosed the Share disk with other operating system. This should be changed. By default, it should create a new ESP for each new installation.

In other words, each new OS installation should have a dedicated ESP.

This dedicated ESP has several advantages.

  1. We can isolate the Windows from Fedora.
  2. Each OS intallation has dedicated GRUB.
  3. We can solve the Kinoite dual-boot installation problem immediately.

We can isolate the Windows ESP from Fedora

Many people complain that Windows updates mess with the Linux ESP. Whether this is true or not, a dedicated ESP for each installation will solve this issue.

We can make GRUB free from the multi-boot menu

Recently, the GRUB menu shows not only the OS installation, but also the OS version.

The default file system of the Fedora workstation is BTRFS. some people are using it grub-brtfs to manage the brtfs snapshots.

The Fedora Kinoite is using GRUB to select the old version to rollback.

To use these functionality, we need dedicated GRUB for each
OS installation. The dedicated ESP can make it happen.

We can solve the Kinoite dual-boot installation problem immediately

Summary

Having dedicated ESP for each OS installation has grate benefit for both Fedora Workstation and Fedora Atomic Desktop.

I appreciate if the deveoppers concider of this modification seriously.

2

I thought that only one esp can exist on a disk, a limitation of the UEFI?
Only on systems with multiple disks could this work?

3

I believe removable devices are supposed to have only one ESP according to the spec, but there’s no stipulation for fixed disks. Personally I dual boot with two ESPs on one disk - it works fine on my system and avoids mixing GRUB and sdboot in the same ESP, which has been problematic for Fedora in the past.

That said, we don’t know what every UEFI implementation does, and it’s conceivable that some of them don’t like multiple ESPs.

1 Like
4

I don’t think we could guarantee this. For example, what if MS change their installer / upgrade code so that it deems any non-Windows ESP to be malware and erases it?

5

FYI I have not seen this is a while. When I updated a pair of Dell laptops that dual boot, nothing broke going to 25H2(26H2). Also no issues on my desktop that dual boot using a pair of disks.

6

This would probably be the main problem, and there’s definitely systems out there with improperly implemented firmware.

At least one other issue is that the spec does point out that firmware isn’t required to check beyond the first ESP for update capsules, which would have to be checked with fwupd to make sure it handles the fedora ESP not necessarily being the one that should be used for updates. I’m sure other corner cases also exist.

1 Like
7

I don’t think we could guarantee this. For example, what if MS change their installer / upgrade code so that it deems any non-Windows ESP to be malware and erases it?

That’s right. We can not guarantee. But it is not a problem.

There is no guarantee that OSS itself will function correctly; certainly, there is no obligation to ensure that other software operates properly in the future.

Improvement of current situation is just enough.

8

That is an interesting and important point.

10

Personally, I think fewer partitions is the way to go. I’d even configure MS Windows to install on a Btrfs subvolume rather than create another partition for it. It is much easier to reallocate space between subvolumes than it is to move partitions around.

3 Likes
11

Oooh, I haven’t seen this before! How do you do it?

12

The NVMe Namespace idea is intriguing, thank you!

This might be a way of making systemd-gpt-auto-generator (as used in Atomic Desktops) more multiboot friendly. It has problems currently when the disk has more than one partition of a given type, but that would be mitigated if it searched for partitions only within the distro installation’s namespace rather than the whole disk.

13

While some UEFI implementations do support multiple ESP, others simply select the first (I suspect there are a few edge cases that throw up their hands, too, and stop, but I don’t know of any myself). You can claim those implementations are wrong, but as a default, one should create only one ESP to be safe (there is nothing to prevent one from choosing to not follow the defaults, but that has to be a decision by each user, hopefully knowing what they are doing).

1 Like
14

What’s tricky is that there are situations where using only one ESP is not safe - indeed, we know it won’t work.

For example, two Fedora installations trying to share the same disk - if they use the same ESP, the second one will stomp on the first one’s ESP files, particularly grub.cfg.

There are other potential solutions to this, but at the moment the installer by default will go ahead and apply this broken setup without warning the user.

People often accuse Microsoft (with some good reasons) of not being a good dual-boot citizen, but in fact Linux/Linux dual boot is often more difficult than Linux/Windows.

1 Like
15

I have one computer that just refuses to boot if a disk has more than one ESP type partition. Most I’ve seen just ignore every ESP after the first one detected, though.

16

I haven’t done it. I’ve just seen it mentioned online and thought it sounded like the way to go (if you must have MS Windows that is :slightly_smiling_face:).

I don’t think adding more ESPs really solves anything. The operating systems just need to cooperate and not stomp on each other’s files. That and the ESP needs to be large enough. I know MS Windows creates a very small ESP by default, but IIRC, there is a small partition manager hidden away at one point in the installation where you can manually specify the partitions and their sizes. If you install MS Windows first, you just need to make sure you make the ESP plenty large.

17

I think it’s 260MB these days by default? That should be enough for most scenarios, unless maybe you have very big firmware capsules. Just going by what we see on Ask Fedora, I think it’s pretty rare for that to be a problem.

That would be the ideal. I mean, even before cooperating with any other OS we could improve Fedora/Fedora multibooting.

18

Microsoft has no support for btrfs in Windows and the UEFI has not support for btrfs.
How where you seeing this working?

19

It’s just something I’ve seen mentioned. It is not something I’ve tried.

Edit: I’m just searching a little more about this. Appearently the Quibble bootloader is the key to making it all work:

It looks like that repo hasn’t had any updates for about 2 years, so maybe it didn’t pan out?

1 Like
20

While the specifications allow for multiple ESP’s [1] it isn’t defined how multiple ESPs on a single disk should be handled by firmware and thus the implementations vary wildly. Some only look at the first, some merge them all together, others crash out and cry.

It doesn’t seem worth it to consider (allowing users to do this via Anaconda/by default) doing this for the not-so-big benefit (in my opinion) it offers.

[1]: 10. Protocols – Device Path Protocol — UEFI Specification 2.11 documentation

1 Like
21

At the moment, the benefit is being able to multiboot different installations of Fedora, which otherwise stomp on files in each other’s /EFI/Fedora.

If Anaconda continues to impose one EFI partition per disk, is it viable to solve the problem another way, e.g. by having each installation have its own /EFI/Fedora-{uuid} or something like that?

1 Like