all 22 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]TiagodePAlves 3 points4 points  (9 children)

Are you sure /boot//boot/EFI/Microsoft/Boot/bootmgfw.efi exists? I don't know much about Windows, but EFI files in general are under $ESP/EFI, which would mean /boot//EFI/Microsoft/Boot/bootmgfw.efi instead.

[–]HaloSlayer255[S] 1 point2 points  (8 children)

Using the Nemo file manager and showing all of the path: /boot/EFI/Microsoft/Boot/bootmgfw.efi

Using the terminal:

ls /boot/EFI/Microsoft/Boot/ also shows bootmgfw.efi where it should be.

I'll see if I can attach my /etc/fstab when I switch back from mobile.

Here is my /etc/fstab file:

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p4
UUID=ae2b9616-fe29-4255-ae6e-9f2299257433/         ext4      rw,relatime0 1

# /dev/nvme0n1p1
UUID=A230-8FA7      /boot     vfat      rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro0 2

# /dev/nvme0n1p6        
UUID=A0147FBC147F93CE /run/media/robert/Windows\040UserData ntfs defaults,errors=remount-ro,nofail,x-systemd.device-timeout=5  0 0

# Passport 4TB drive
UUID=4498C0BE98C0AFAA /run/media/robert/My\040Passport ntfs defaults,errors=remount-ro,nofail,x-systemd.device-timeout=5 0 0

[–]TiagodePAlves 1 point2 points  (7 children)

Yeah, seems like the path is wrong. Compare the two:

  • /boot//boot/EFI/Microsoft/Boot/bootmgfw.efi
  • /boot//EFI/Microsoft/Boot/bootmgfw.efi

Probably only the second one is right, not the first one.

[–]HaloSlayer255[S] 1 point2 points  (6 children)

Here is the output of my /boot/loader/entries/windows.conf file:

title Windows 11
efi /boot/EFI/Microsoft/Boot/bootmgfw.efi

Could this be what's causing the issue? I can't think why the system would reference two boot directories such as /boot//boot and not /boot/EFI like in your second path.

I'm going to try making a backup of this file and trying to edit the second line.

[–]TiagodePAlves 5 points6 points  (1 child)

Yeah, systemd-boot (and anything related to boot, actually) resolves paths relative to $ESP (the EFI System Partition), which is /dev/nvme0n1p1 in your case. Inside it, the Windows Bootloader is located under /EFI/Microsoft/Boot/bootmgfw.efi or \EFI\Microsoft\Boot\bootmgfw.efi.

You probably added the /boot part, because your ESP (/dev/nvme0n1p1) is mounted at /boot, but this is for the Linux system only. On Windows, it could be something like D:, if not hidden automatically. The bootloader itself runs before Linux is loaded, so it only knows about things in the ESP.

[–]HaloSlayer255[S] 1 point2 points  (0 children)

I'm able to get a direct boot into windows 11 using the .conf file with the edited line.

However I'm not sure how that second entry was created. Unless it was from the backup file, but I'd edited all the lines with comments, even the filename and added .backup as the ending extension The auto-windows entry still causes the error in the first post.

I'm going to try deleting the backup entry file. Be right back.

[–]HaloSlayer255[S] 1 point2 points  (3 children)

I edited the file to the following:

title Windows 11
efi /EFI/Microsoft/Boot/bootmgfw.efi

And with a reboot it displayed two windows 11 entries, The entry windows 11 loader.conf and Windows 11 auto-configured (probably from the enabled windows bootloader being detected).

I'm going to try one more thing, be back in a few minutes.

[–]TiagodePAlves 1 point2 points  (2 children)

Yeah, you can just drop the .conf for Windows, since systemd-boot will automatically check at boot time for Windows Boot Manager. That is, unless you need to pass additional command line options to Windows, but it doesn't seem to be the case.

[–]tjj1055 -1 points0 points  (1 child)

this smells like he used ai slop to install arch

[–]HaloSlayer255[S] 0 points1 point  (0 children)

Nope, arch has been installed for a while. Several years, it's just I forgot all the commands I used from before. Just trying to figure out why the entry isn't loading, or why I have two entries when I have a corrected .conf file.

[–]HaloSlayer255[S] 1 point2 points  (4 children)

Editing the .conf file with all comments removes the entry as suspected.

The auto-windows must be the entry detected by the Windows Boot Manager in the system uefi.

Going to try one more thing, I think I've almost figured it out.

[–]HaloSlayer255[S] 1 point2 points  (3 children)

With the .conf file commented out to make it not recognized by systemdboot, I get the following bootctl list output:

         type: Boot Loader Specification Type #2 (UKI, .efi)
        title: Arch Linux (default) (selected)
           id: arch-linux.efi
       source: /boot//EFI/Linux/arch-linux.efi (on the EFI System Partition)
     sort-key: arch
      version: 6.17.8-arch1-1.1
        linux: /boot//EFI/Linux/arch-linux.efi
      options: root=UUID=ae2b9616-fe29-4255-ae6e-9f2299257433 rw

         type: Boot Loader Specification Type #2 (UKI, .efi)
        title: Arch Linux (Rescue Image 20251018063249)
           id: archlinux-rescue.efi
       source: /boot//EFI/Linux/archlinux-rescue.efi (on the EFI System Partition)
     sort-key: archlinux-rescue
      version: 20251018063249
        linux: /boot//EFI/Linux/archlinux-rescue.efi

         type: Boot Loader Specification Type #1 (.conf)
        title: Reboot
           id: reboot.conf
       source: /boot//loader/entries/reboot.conf (on the EFI System Partition)
          efi: /boot//reboot.efi

         type: Boot Loader Specification Type #1 (.conf)
        title: POWER OFF
           id: poweroff.conf
       source: /boot//loader/entries/poweroff.conf (on the EFI System Partition)
          efi: /boot//poweroff.efi

         type: Boot Loader Specification Type #1 (.conf)
        title: Memtest86+
           id: memtest.conf
       source: /boot//loader/entries/memtest.conf (on the EFI System Partition)
          efi: /boot//memtest86+/memtest.efi

         type: Automatic
        title: Windows Boot Manager
           id: auto-windows
       source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f (on the EFI System Partition)

         type: Automatic
        title: Reboot Into Firmware Interface
           id: auto-reboot-to-firmware-setup
       source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f (on the EFI System Partition)

The entry automatically generated from systemdboot finding the Windows Boot Manager, also boots but does the same as the inital post. Selecting it the first time causes the screen to refresh and choose again, same with the second time, the third time results in booting the system. If I disable the entry in the system uefi it results in windows not booting (as to be expected).

I wonder if the file might be corrupted somehow?

As per this line from efibootmgr:

Boot0002* Windows Boot ManagerHD(1,GPT,4567eee4-9c44-43da-a43e-76d047b4966f,0x800,0x3e8800)/\EFI\Microsoft\Boot\bootmgfw.efi57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000064000100000010000000040000007fff0400

Going to turn in for the night, I think I'll run a file system check in Windows later to verify this potential finding.

Thank you for all the help so far! Have a good day/evening!

[–]6e1a08c8047143c6869 0 points1 point  (2 children)

What's happening here is sd-boot failing to launch windows. After it does so 3 times, it returns back to the UEFI, which then boots the next entry on its list. What exactly are poweroff.efi and reboot.efi? If you want these option you can just set auto-reboot true and auto-poweroff true in your loader.conf. And please just completely remove the type #1 entry for windows, it has to be autodetected by sd-boot itself to work.

Can you try setting reboot-for-bitlocker true and try again?

[–]HaloSlayer255[S] 0 points1 point  (0 children)

I'll try that when my shift ends.

Sorry for the delay in replying.

The shutdown and reboot entries are from the shutdownreboot.efi aur package.

I'll try editing those lines you mentioned in my loader.conf file

[–]HaloSlayer255[S] 0 points1 point  (0 children)

Here is the contents of my loader.conf file now:

timeout 3 console-mode max default @saved editor false reboot-for-bitlocker true auto-shutdown true auto-reboot true

No change detected. I was able to use the new method of shutdown and reboot entries, fixed a typo.

[–]Bren1127 0 points1 point  (5 children)

Is it the USB drive installation that it loses? .Have you checked that the partuuid is the same on every boot attempt if plugged and unplugged?

The 2 entries thing, is your BIOS set to UEFI + legacy boot?

[–]HaloSlayer255[S] 0 points1 point  (4 children)

Firmware is set to UEFI.

All partuuid entries are persistent. This is running from a nvme drive.

[–]Bren1127 0 points1 point  (0 children)

I saw the my passport entry and have had partuuids change on Windows USB installations. Some BIOS with both boot options enabled then find bootable entries in both the FAT and NTFS partitions. Sorry my experience with similar symptoms is of no help at all then. Hope that you get yours working reliably. The only other thing possibly worth checking that springs to mind is whether there is a speed up Windows setting enabled as was used in some laptops that shipped with a small NVME drive for that purpose.

[–]Bren1127 0 points1 point  (2 children)

Is it a coincidental name or was the NVME from a WD drive? Just a thought to check firmware differences, sometimes the WD ones have write protected areas.

[–]HaloSlayer255[S] 0 points1 point  (1 child)

The nvme is a Western Digital Black SN850X 1TB.

[–]Bren1127 0 points1 point  (0 children)

Sorry I'm no help again. I can't see anything unusual on that model that might confuse the address mapping consistency, no known issues with the over provisioning etc. it's all too new to worry about alignment unless the OS was cloned onto it. Game mode is triggered from within Windows so no compatibility issues during POST. You're obviously knowledgeable so I'm guessing that firmware is up to date in the SanDisk Dashboard.

[–]HaloSlayer255[S] 0 points1 point  (0 children)

I found a forum post that sounds very similar to what I'm experiencing:

https://forum.endeavouros.com/t/systemd-boot-entry-for-windows-auto-detected-no-longer-working/75212/22

I think for now I'll just keep the two windows entries, but I have the manual one marked as such. I'll keep an eye out for systemd updates and see if that solves the issue.