Disclaimer: I would like to note that I am relatively new to Linux, so I am not sure if this is a well-known issue. I fixed my issue with the help of Google Gemini, so while the solution works for me, I cannot guarantee the correctness of the analysis and the effectiveness of the solution.
I wanted to share a critical caveat I discovered while trying this grub2-reboot method on my Fedora 43 and Windows 10 dual boot system, as detailed in Grub one time boot of a different entry . My /boot partition is formatted as Btrfs, and using grub2-reboot caused an infinite boot loop into the selected secondary OS (Windows 10 in my case).
The Issue (Gemini): The grub2-reboot command works by writing a next_entry variable to the grubenv file. When I tried to reboot, GRUB reads this variable, boots the selected OS (Windows 10 in my case), and then attempts to delete the variable so the next boot returns to default. However, GRUB’s bootloader drivers for Btrfs and XFS are read-only. This means GRUB can read the command to “Boot Windows,” but it fails to delete that command afterward. As a result, the “one-time” boot instruction remains in the file forever, and you get stuck booting into that OS until you manually clear the variable from within Linux.
My solution: I bypassed GRUB entirely and used efibootmgr to instruct the BIOS directly.
- Find Boot Manager ID for the secondary OS (look for the 4-digit hex code, e.g.,
0001):sudo efibootmgr - Use a script like this to set the “BootNext” variable in the firmware:
#!/bin/bash # Replace 0001 with your actual Windows Boot Manager ID sudo efibootmgr -n 0001 sudo shutdown -r now
This worked perfectly (for me) because the BIOS itself clears the BootNext variable automatically after one boot, avoiding the filesystem permission issues entirely.