Dual boot / Better support in Anaconda for existing EFI setup

[richard-gravy]

This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla or in upstream (preferred for GNOME projects) and not in this issue tracker.

Describe the bug Though this is a known issue, after hoping against hope that some progress might have been made on this since F34, anaconda once again fails to install Silverblue F36 onto a computer with one or more existing operating systems properly and stops before the EFI boot configuration is correctly written. I have tried to repair the boot configuration myself, but I was not certain what layout anaconda would have used. At the moment, the root mount is a btrfs subvol ("root-0"). There are no other subvols. I can manually copy the GRUB boot commands from another machine to boot, but hit another problem as the root is mounted read only, which includes the /boot directory. Subsequent updates to the boot entries fail for this reason.

Is there a reference somewhere that I can use to understand the default mount layout in Silverblue? Do I need another subvol to mount /boot rw?

To Reproduce Please describe the steps needed to reproduce the bug:

1. Download F36 image and write to USB flash memory storage.
2. On a computer with EFI firmware and an existing OS, boot from the storage.
3. Start the installation.
4. Press Ctrl+F2 to access a shell and do not attempt automount.
5. Mount the EFI partition in a directory under /mnt, rw.
6. Rename the 'EFI' directory to 'EFI2'. (This is a suggested mitigation for the issue)
7. Unmount the partition and press Ctrl+F5 to return to the anaconda GUI.
8. Manually configure a new btrfs partition and subvol from free space in blivet-gui, assigning the mount point '/'. Set the existing EFI partition as mount point '/boot/efi'.
9. Press 'Done' and continue the installation.

Expected behavior Congratulations! Silverblue is successfully installed. Instead of a dialog box indicating a fatal error completing an "ostree admin" command.

[jkonecny12]

https://bugzilla.redhat.com/show_bug.cgi?id=2167086 -- tracking this in BZ. The old bug from a duplicate have different error raised.

[travier]

This is likely to be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1575957

[00sapo]

Same issue with Fedora Kinoite. I even tried to format the existing EFI partition but it failed in the same way. Also tried the other tricks about moving the fedora and/or EFI folder before running the installation but didn't work.

[secretmango]

I can reproduce this too, on Kinoite and also ublues ISO installer

[biscotty666]

Unable to install the latest SB without reformatting efi, which nixed my NixOS install. The workaround of creating a new efi failed, although I used that approach effectively in the past with Kinoite.

[LukeShortCloud]

This issue seems to be specific to existing non-Windows installations. I was able to install Fedora Silverblue after installing Windows. Tested with all combinations of: Fedora Silverblue 37 and 39, Windows 10 21H2 and Windows 11 23H2. Both manual partitioning (re-using the "EFI System Partition" from Windows as /boot/efi ) and automatic partitioning works.

[fedora-mahdi]

This issue seems to be specific to existing non-Windows installations. I was able to install Fedora Silverblue after installing Windows. Tested with all combinations of: Fedora Silverblue 37 and 39, Windows 10 21H2 and Windows 11 23H2. Both manual partitioning (re-using the "EFI System Partition" from Windows as /boot/efi ) and automatic partitioning works.

@LukeShortCloud : Could you please elaborate on how you succeeded to install Silverblue after installing Windows (or with Windows 10/11 already installed) I have SecureBoot on and couldn't get it done

If you could please detail your partitionning scheme either manual (what you meant by re-using the "EFI System Partition" from Windows as /boot/efi ?) or automatic partionning.

Thank you for your insights

[fedora-mahdi]

Hello,

I am sorry, I do not quite understand what user you are and what exactly you are referring to...

I commented on this thread " Dual boot / Better support in Anaconda for existing EFI setup #284 " the following message

Please expand/detail your answer by mail, I lack the context related to my answer

Thanks !

[image.png]

Le lundi 12 février 2024 à 1:28 PM, OpenSauce @.***> a écrit :

On F39 Silverblue I can't install even when reformatting the EFI partition in Anaconda

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[LukeShortCloud]

By manual format, I mean that I selected the 260 MiB FAT32 partition from Windows (used to store the EFI partition) and assigned it to the manual mount point of /boot/efi during installation on Fedora Silverblue. Alternatively, selecting the automatic partitioning in the Fedora Silveblue installer also worked.

I tested using Virtual Machine Manager (virt-manager) with the QEMU KVM back-end. TPM 2.0 and UEFI Secure Boot were both enabled for the virtual machine. Windows was installed first. Then Silverblue second.

[latenightdef]

I successfully installed Kinoite in a dual boot with Windows 11, using a second ESP.

Starting with a machine with an existing Windows 11 installation, here's the partition layout I have.

• 100MB ESP
• 16MB Microsoft reserved partition
• 200GB NTFS for Windows C:\
• [free space]

I used Fedora Media Writer to create a bootable Kinoite installation media - which also works with secure boot enabled. Here's my working partition layout:

• 100MB ESP
• 16MB Microsoft reserved partition
• 200GB NTFS for Windows C:\
• 500MB ESP mounted at /boot/efi
• 1GB ext4 mounted at /boot
• 50GB btrfs mounted at /
• [free space]

This way, the installation was successful, but Windows did not show up in GRUB yet. I had to run sudo grub2-mkconfig -o /etc/grub2-efi.cfg to update the GRUB configuration and this time it found my Windows installation.

At this point I have a working Kinoite + Windows 11 setup with secure boot enabled.

[andrabt]

Hi there!

I have installed Silverblue 40 dualboot with NixOS, and it works after 4th trial with automatic configuration from Anaconda. 😊

[f0nzie]

I have my MSI laptop, originally with Windows 11, booting three OSes: Windows 11, Ubuntu 22.04, and Fedora Silverblue Bluefin-DX, all from one physical 2 TB Nvme SSD.

Before I installed Silverblue, I read the documentation which specifically recommends to install it in a different disk. But it did not satisfactorily explain why. So, I decided to install Silverblue anyway. With UEFI is much easier because during the manual installation (manual partitioning) you are given the choice to create the EFI partition for Silverblue (350 MB), as well as boot (1024 MB). Additionally, I created separate Btrfs partitions for /root (40 GB), /home, and /var.

The only difference with my previous Ubuntu 22.04 installation is that Fedora Silverblue requires to be selected as the boot manager in the UEFI setup, which is fine with me. I still have the boot options for Windows 11 and Ubuntu 22.04 in the Silverblue/Bluefin-DX boot menu.

Another OS that I tried in the same MSI laptop, and also requires to be the boot manager, is Manjaro. After some tests I removed the OS. The instructions to install Manjaro in a dual-boot disk is well explained in YouTube videos. It is somewhat different to an Ubuntu installation because Manjaro and Silverblue call for the creation of an EFI partition.

My Bluefin-DX is very stable after installing it as a second-boot OS. It was actually the third try at installing and testing the Fedora Silverblue installer until I got it right, partition size-wise, volume type (fixed vs automatic), and type (Btrfs). The installer is very friendly.

[mahdiaqallal]

Thank you for detailled answers , regarding partitionning @LukeShortCloud @latenightdef and @f0nzie

As I understand I, when installing Silverblue/Kinoite as second OS after Windows 10/11 there are two possibilities using Anaconda:

1. Using the existing EFI/ESP partition managed by Windows, described in @LukeShortCloud 's comment

By manual format, I mean that I selected the 260 MiB FAT32 [size might by more 600MiB nowadays] partition from Windows (used to store the EFI partition) and assigned it to the manual mount point of /boot/efi during installation on Fedora Silverblue. Alternatively, selecting the automatic partitioning in the Fedora Silverblue installer also worked.

Which options in Anaconda blivet @LukeShortCloud have to be activated to that the mount point of /boot/efi is assigned to the existing EFI without erasing/formatting it's existing Windows content ?

2. Creating a new EFI/ESP described in @latenightdef 's comment

I successfully installed Kinoite in a dual boot with Windows 11, using a second ESP.

and

run sudo grub2-mkconfig -o /etc/grub2-efi.cfg to update the GRUB configuration and this time it found my Windows installation.

Could you please @latenightdef share the relevant updated grub.cfg menuentry configuration ? Specifically on how Windows gets jump started from GRUB ?

With SecureBoot on and TPM on, (and Bitlocker in Windows is also on) I get an SecureBoot error from by EFI firmwre boot setup. The following boot sequence is accepted: Power on => UEFI firmware => UEFI Boot NVRAM variables => Windows EFI => Windows is booted

But this sequence fails: Power on => UEFI firmware => UEFI Boot NVRAM variables => GRUB => grub.cfg => Menuentry for Windows => UEFI error for SecureBoot policy violation

[latenightdef]

Here's the relevant menuentry part

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-FAC2-D830' {
    insmod part_gpt
    insmod fat
    set root='hd0,gpt1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  FAC2-D830
    else
      search --no-floppy --fs-uuid --set=root FAC2-D830
    fi
    chainloader /efi/Microsoft/Boot/bootmgfw.efi
}

This worked at least with a UEFI QEMU virtual machine

[    0.000000] efi: EFI v2.7 by EDK II
[    0.000000] efi: SMBIOS=0x7e9d5000 SMBIOS 3.0=0x7e9d3000 ACPI=0x7eb7e000 ACPI 2.0=0x7eb7e014 MEMATTR=0x7ca72018 MOKvar=0x7e980000 
[    0.000000] secureboot: Secure boot enabled

[artur-sannikov]

I tried installing both Fedora Kinoite and UBlue (Aurora) and was failing when using dual-boot with Win 11 at bootloader writing step (Failed to write boot loader configuration). I disabled Secure Boot and first installed Win 11, and then Aurora (Kinoite also works) with partitioning settings suggested by @latenightdef. Re-enabling Secure Boot later and enrolling the keys worked successfully.

[JamesMcMahon]

Trying to follow all the details in this thread.

If you are in a position where Anaconda has already wiped your existing EFI boot partition for Windows, it seems like the only way forward is to use a Windows recovery USB to reestablish the Windows EFI boot and then use the work around suggested by @latenightdef in this comment.

Am I understanding that correctly?

[DarkGhostHunter]

It seems so. Personally, I used these instructions (not exactly but very close) some months ago but through the Windows 11 installer (shift + F10).

Personally I have rEFInd to handle the booting process between Windows and Bluefin. I have reinstalled Windows 11 (by formatting only the NTFS partition) without problems, as rEFInd is untouched.

[JamesMcMahon]

Appreciate the reply.

Is there way to fix the issue and reinitialize the atomic boot partition without doing a full reinstall?

[DarkGhostHunter]

Appreciate the reply.

Is there way to fix the issue and reinitialize the atomic boot partition without doing a full reinstall?

On Bluefin, while is technically a full reinstall, I reinstalled by creating new subvolumes and leaving those old intact, and then swapping the subvolumes in /etc/fstab. YMMV.

[JamesMcMahon]

I hope this isn't too off topic, but for posterity and the folks looking to repair this error. What I ended up doing was booting into a Windows USB recovery drive, selecting command line and running bootrec /rebuildbcd. Then I backed out and selected "Start-up Repair" and that fixed it. I can now select in my bios either the Windows or Fedora boot EFI.

The article linked above had a bunch of commands that didn't work and I was able to simplify it by quite a bit.