Is your feature request related to a problem? Please describe.
I'm always frustrated when using different distributions that use different versions of systemd-boot, that all get installed in same place in the ESP.
Describe the solution you'd like
An easy and non-desruptive way to test/use different versions of systemd-boot side-by-side.
Describe alternatives you've considered
See my solution below.
To ease testing different systemd-boot versions, i would suggest to create sub-directories under ESP\EFI\systemd per version used. (and checked by bootctl)
eg:
<ESP>
|--EFI
|--systemd
|-- Combined 'boot.csv'
|--${build-version} (fe. "245.xxx-${distro's vendor name}")
|-- The efi binar(ies) used. (eg. shim, systemd-boot, etc)
|-- Per version 'boot.txt' that gets combined/concatenated in the parent dir's 'boot.csv'.
That way people will be able to both test different versions and fallback to another version in case of bugs...
It's similar to specifing an efi binary in a sub-directory as it is to specifing one in a sub-sub-directory for use 😉
eg:
- In a boot-entry, using
\EFI\systemd\<build-version>\efibin instead of \EFI\systemd\efibin
- and in CSV-file, using
<build-version>\efibin instead of plain efibin.
I'm currently using this same logic for the boot-loaders of per-distribution-flavors side-by-side without them interfering with each other... (*ubuntu flavors, suse flavors, etc) (See: here and here)
Is your feature request related to a problem? Please describe.
I'm always frustrated when using different distributions that use different versions of systemd-boot, that all get installed in same place in the ESP.
Describe the solution you'd like
An easy and non-desruptive way to test/use different versions of systemd-boot side-by-side.
Describe alternatives you've considered
See my solution below.
To ease testing different systemd-boot versions, i would suggest to create sub-directories under ESP\EFI\systemd per version used. (and checked by
bootctl)eg:
That way people will be able to both test different versions and fallback to another version in case of bugs...
It's similar to specifing an efi binary in a sub-directory as it is to specifing one in a sub-sub-directory for use 😉
eg:
\EFI\systemd\<build-version>\efibininstead of\EFI\systemd\efibin<build-version>\efibininstead of plainefibin.I'm currently using this same logic for the boot-loaders of per-distribution-flavors side-by-side without them interfering with each other... (*ubuntu flavors, suse flavors, etc) (See: here and here)