I was facing an issue with systemd-boot during my last install, i had selected /boot as mount point and installed boot loader when i was trying to complete the installation it was giving me message that boot loader is not installed, it tried few times then finally gave up and installed grub
Oh, your boot partition were nor flagged as boor and ESP!
my boot partition was flagged as /boot and i tried sd-boot when it didn’t work then i changed the boot partition flag to /boot/efi and installed grub
Flagged is appending a specific byte that tells the BIOS to boot from this partition. 
That was exactly the problem I had.
For an UEFI boot you don’t need to flag any partition as “boot” because the UEFI bios will check all drives and partitions and use the first (or configured in bios) ESP partition to boot from.
ESP partitions have an unique GUID…
Flagging a partition as “boot” is only needed for Legacy/MBR boot’s.
That’s a point that needs a change actually, because it is much more workable if one could use /efi as the mount point in that case and bind-mount a subdirectory of it as /boot (eg. /efi/Manjaro -> /boot)
But yes that’s the starting point with which i had a working encrypted root also…
If you use that bind-mount “trick” i wrote, you will end-up with all needed files (to boot) in the ESP and that setup will work for any bootloader plus keep kernels+ramdisks separated from other distro installs…
Selecting the mount point as /boot (sd-boot) or /boot/efi (grub/rEFInd) is part of manjaro architect installation process.
I know… that’s why i suggest it to be changed to:
-
$ESP = /efiin combination with/efi/Manjaro -> /boot(bind mount).
This will work forsd-bootplusothers
Pull requests are welcome. The could be a third option in the installer.
You can often just ignore that warning, the bootloader check is overzealous and does not always detect the bootloader.
I would be trying in due time to do that, but at moment im still too new to be familiar enough with the Manjaro installer to fiddle with it to accomplish that…
Plus i would not know where to head to to get started with contributing at source level…
Exactly why i suggested /efi which is mentioned in the documentation there
This placeholder file system shall be determined during installation time , and an fstab entry may be created. It should be mounted to either
/boot/or/efi/. Additional locations like/boot/efi/, with/boot/being a separate file system, might be supported by implementations. This is not recommended because the mounting of$BOOTis then dependent on and requires the mounting of the intermediate file system.
This is the repo
This is the function to install systemd-boot. Current implementation uses sdboot-manage, so you can also contribute there if you want.
This is where efi partition is mounted.
It’s just bash, if you can do a cli-installation, then this is easy to hack. And it is easy to test changes since you don’t need to compile it between tests.
less than a minute of looking over and i already spot some wrong things…ahh well i’ll sure try to contribute in due time…
Will take some time for me to familiarize with the code base first… 
PS:
@Chrysostomus, Until the author of sdboot-manage changes his standpoint wrt. wiping old boot entries as default, it will be very hard for me to try fiddling with this all.
I would have to create a VM to make sure it does not render my whole system useless, because that behaviour eliminates the possibility of installing alongside other installs…
Depends on who you ask
https://github.com/systemd/systemd/issues/16089
It also perfectly supports x86 and ARM. You just need the right binary of course.
https://github.com/systemd/systemd/issues/10139
A real downside if any is that network boot and mixed efi is not supported
Very much true, but that’s kind of the /efi design, isn’t it?
Sd-boot is very good at hitting firmware bugs.
A shitton lot? Seriously, it’s not even like this was clear linux.
Once upon a time the thus installer did actually offer this choice graphically.
Laughs in 14nm++++ cpus and broken Koomey’s law
Shim is by red hat.
If any Ubuntu is probably big enough of a distribution that they don’t need to pass through their facilitated signature.
1 Like
As you can notice, that issue is only flagged as RFE eg. as a feature request so others who are willing to implement it could provide a PR for it
(Dated June 8, with no change or reply)
Ok i stand corrected and pleased to hear that you know of other binary types of it.
See the answer of poettering is equal to mine also
Plus it has been 2 years with no actual implementation by anyone.
Network boot (eg. PXE boot) is another type of booting using as the name says another boot loader, hence not the duty of sd-boot but more of the image loaded using the PXE server and or the kernel+ramdisk image that is used by sd-boot like poettering answered.
When it comes to “mixed efi” you mentioned, seems like that discussion is ongoing who knows what the final result will become…
Any reference to that claim?
I know they use an OID from RH wrt “kernel-module-signing only” permission for the Mok-Key.
Because they (RH) came up with the idea of that flag, which can/will be replaced by a general one (and more standard wrt OID’s) in due time i’m sure…
It’s only a binary number afterall and only used by the Linux kernel, it has nothing todo with being big or small enough, it all boils down to who came up with an idea first.
Going by that last part, you should have mentioned the Author of that OID instead of RH 
(Nevermind me i have an antipathy vs RH similar to M$)
Besides in that quote im talking about the solution as a whole, not the separate utils used in that solution
These are shim’s sources.
If you are a small distro, you can have “transparent” booting with no action required for free, by asking to them to chainload your signature.
Otherwise you either request to the users to manage themselves their keys (or disable SB altogether), or you have to buy an EV certificate and ask microsoft.
Thanks for the link to the shim source.
For the rest its easier to just use the signed shim binary (no matter which) to start chainloading instead of asking for approval by any commercial company.
(Seems that chainloading of certificate idea bleed to death reading that link)
But now i at least understand why shim is so slow in fixing it’s bugs, it’s the price the community pays when interacting with commercial parties…
(Fast innovation vs power of hard-headed-ness)
I did not read the whole thread because it is too long so did someone find out why systemd-boot is replacing GRUB?