You are not logged in.
Hello guys,
I'm new in Arch (was using Ubuntu, Mint & Manjaro previously) and so its the first time I use systemd-boot as bootloader.
Yesterday I did (systemd-boot) Boot from another disk to setup the Windows entry. Worked fine.
Today, at startup, the Windows entry didn't work and go back to selection. I launched EFI Shell and then do "map" just to find the disk with the PARTUUID of the Windows entry changed its FS Alias.
So I changed the /boot/loader/entries/windows.conf and it worked fine, then I rebooted to try again and, of course, the FS Alias changed again.
I can't seem to find the issue on internet, and I don't really know what to do now. I could try and switch for GRUB which always worked fine, but I would like to try and stick to systemd-boot and learn new things if possible.
So, if someone as an idea, I'll be grateful.
=== EDIT : Solved and what I did===
Maybe someone will have the same issue as me in the futur, so I will detail what I did to solve the issue.
It may not work on your setup and it may break your system, so try only if you understand what you're doing and how to prevent complete breakup!
use one ESP on one of the drives and boot both OS from it
> Which I understood as "copy the Windows ESP on the drive systemd-boot boot from" (even if now I don't really see why)
1. Launched GParted-Live to reduce the /home partition of my Arch drive (I took 1GiB from it, it's way to much since windows esp takes about ~50Mo, I would recommend a ~100Mo partition)
2. Booted on my Windows OS and used the BCDBoot command to move my ESP to the new partition I just created (the partition needs to be mounted)
2.1. Exact command for me was : (please look the documentation just above before trying anything)
bcdboot C:\Windows /l fr-fr /s G: /f UEFI /v /p3. Rebooted to my Arch OS, edited the esp/loader/entries/windows.conf just to remove the "BLK7:" (will be different for you, look at systemd documentation) just before the "EFI\Microsoft\Boot\Bootmgfw.efi"
And now it just works, I rebooted several times and no problem. To be sure I looked at the map on the UEFI Shell to be sure the ESP partition never had the same FS Alias, and it did not. So, I didn't fixed the "not persistent FS Alias", but I got around the problem.
Thanks for the help !
=================================
Last edited by Azel (2024-08-05 15:21:54)
Offline
from what's given I assume you have two drives with an ESP each and want to chain the other drive from the one you boot arch of
I'm not sure about if this is a systemd-boot issue or a bad uefi implementation as it seems the order of drives is not persistent
a workaround would be to
- use one ESP on one of the drives and boot both OS from it
- use the uefi boot menu to select between tge OS (as thst's the intented design)
- try a different boot manager like grub or refind to check wether it's an issue of the boit loader or the systems firmware
- do the reverse and chain arch from windows (although you to refer to the MSDN for help)
Offline
I assume you have two drives with an ESP each and want to chain the other drive from the one you boot arch of
You understood correctly yes
- use one ESP on one of the drives and boot both OS from it
Do you mean moving the Windows ESP to the Arch/systemd drive ? I didn't knew one can do that, I'll look into it thanks
Offline
It would be easier to simply share the Windows ESP with Arch. Windows will probably sulk if you try to mess with it's configuration.
Jin, Jîyan, Azadî
Offline
Thanks @Head_on_a_Stick, I guess you're right... Tho I did mess up with Windows, and it seems to have fixed my issues (for now :finger_crossed:)
So, @cryptearth whether or not I understood your idea correctly, it seemed to have worked as now systemd-boot doesn't need the drive id or fsalias to launch Windows, I will detail what I dit in a EDIT on the original post, thank you for helping !
Offline
although I'm not sure about the specific forum rules about posting the answer as a new reply instead of edit it into the starting I'd lije to quote a mod from the coderanch forums: "Please avoid edit after reply - it makes others replies look stupid (fixing typos is ok, tho)".
anyway - that's up to the mods
first: thanks for replying back with a proper explanation instead of just useless "got it fixed" - although it's quitee off from what I had in mind
second: I'm not sure how far I'm allowed to go into windows' boot process as similar topics got closed at such point (aside from one where a user somehow ended up with an unbootable system - no reply to that one since, tho) - but to keep it general: windows, too, works quite similar to most linux bootloaders: it has it's first stage boot manager bootmgfw.efi which loads its BCD config (which is about the same as a grub.cfg: a list of entries) and then chains the OS loader - which in case of windows is \windows\boot\winload.efi
hence: one can use windows' bcdedit to modify the current used bcd config and add an entry to any other efi image on any readable filesystem - so in the end one might use windows' boot manager to chain grub, refind, systemd or even a UKI - although I don't know how this will affect the boot process and might could cause issues
unfortunately windows has the bad habit of thinking it's the only rightful OS on a system - hence no matter how often you delete it on the next boot it will restore its bootentry and a copy in the fallback path no matter of other bootloaders or OSs (fun fact: this even causes issues when installing two windows instances along eachother cause both fight to be the primary one) - so maybe when dual-booting with windows one might set windows' bootloader as default as it will do that itself anyway
one can also modify the bcd's default entry to chain a linux bootloader instead of bootmgfw and then strap winload.efi directly - but according to tests this does cause issues because windows just doesn't like it when winload gets started directly by anything else than boitmgfw
Offline
windows, too, works quite similar to most linux bootloaders: it has it's first stage boot manager bootmgfw.efi which loads its BCD config (which is about the same as a grub.cfg: a list of entries) and then chains the OS loader - which in case of windows is \windows\boot\winload.efi
hence: one can use windows' bcdedit to modify the current used bcd config and add an entry to any other efi image on any readable filesystem - so in the end one might use windows' boot manager to chain grub, refind, systemd or even a UKI - although I don't know how this will affect the boot process and might could cause issues
Oh, ok. That's a lot of knowledge, thanks ! I guess I just dis the opposite then
. Since I'm not having any issue right now I won't change anything, but I keep that in mind.
although I'm not sure about the specific forum rules about posting the answer as a new reply instead of edit it into the starting I'd lije to quote a mod from the coderanch forums: "Please avoid edit after reply - it makes others replies look stupid (fixing typos is ok, tho)".
Oh, yeah, I see the potential issue. I'm not quite used to OS forums, more gaming ones
. I won't change it now unless I need too (because then it'll make your response look weird, kinda) but I'll keep it in mind for the next posts.
Offline