after switching to systemd-boot and removing grub2-packages only initrd get generated but no kernel and no boot-entry - at least "grub2-tools-minimal" is needed and to get rid of some obscure warning "grub2-tools" too and what is creating this stuff? grub_users $grub_users grub_arg --unrestricted grub_class generic /efi/loader/entries/f2e61df948714ed49f14eac2840bc3f3-5.19.14-200.fc36.x86_64.conf:7: Unknown line "grub_users", ignoring. /efi/loader/entries/f2e61df948714ed49f14eac2840bc3f3-5.19.14-200.fc36.x86_64.conf:8: Unknown line "grub_arg", ignoring. /efi/loader/entries/f2e61df948714ed49f14eac2840bc3f3-5.19.14-200.fc36.x86_64.conf:9: Unknown line "grub_class", ignoring.
(In reply to Harald Reindl from comment #0) > after switching to systemd-boot and removing grub2-packages only initrd get > generated but no kernel and no boot-entry - at least "grub2-tools-minimal" > is needed and to get rid of some obscure warning "grub2-tools" too Sorry, but this is too vague to be actionable. Which steps did you follow to set up systemd-boot? Which grub2 packages did you remove? Also, it would be nice to get the output of # sh -x kernel-install add `uname -r` /lib/modules/`uname -r`/vmlinuz > and what is creating this stuff? > > grub_users $grub_users > grub_arg --unrestricted > grub_class generic /lib/kernel/install.d/20-grub.install , coming from grub2-common.
* copy /boot contents to ESP on a live-system * delete all grub specific on the ESP * mv /boot /boot-old *Ü ln -s /efi /boot * bootctl install what is vague here? normally you should be able to remove all packages with the name "grub" when you use systemd-boot which is a single binary on the ESP and "kernel-install" shiped with "systemd-boot" should still work "dnf remove" all grub2-packages you can install and than run "dnf upgrade" and you will see no kernels on the ESP
(In reply to Harald Reindl from comment #2) > what is vague here? Let me show you how I read the original description: "I did something I think is needed to switch to systemd-boot. After that I removed some grub2 packages. As a result of these unspecified steps, an initrd has been generated somewhere but kernel and boot entry has not."
i did not something i think - i switched to systemd-boot and it boots so common sense told me "i am done with grub on that machine" logical next step i removed the grub2 packages by common sense the i tried "dnf upgrade kernel\*" and wondered why there was no kernel instaleld but only a inird generated and keep your "an initrd has been generated somewhere" for yourself - it's where it belongs to at /efi and even if it would be installed to /boot no problem because in my case /boot is just a symlink to /efi the point is that as soon as you remove grub2 packages because you no longer use rgub2 kernel-install don't install keernels
(In reply to Harald Reindl from comment #4) > and it boots But you did not mention this. > the i tried "dnf upgrade kernel\*" Nor this. > and keep your "an initrd has been generated somewhere" for yourself - it's > where it belongs to at /efi Good. But you did not mention that either. > and even if it would be installed to /boot no > problem because in my case /boot is just a symlink to /efi Which is another thing you omitted. I'm sorry, but I can only evaluate a bug report based on the information provided by it. And the original description is particularly lacking in information. > > the point is that as soon as you remove grub2 packages because you no longer > use rgub2 kernel-install don't install keernels Yes, I've got that after reading comment 2. And I'm not too surprised. As I said in bug 2133294, nobody has done the work to provide first-class support for systemd-boot in Fedora. Patch(es) welcome.
the "after" in "after switching to systemd-boot" implies a finished transition which is prerequisite for "and removing grub2-packages" which one would only do after a successfull boot with systemd-boot > nobody has done the work to provide first-class support for systemd-boot in Fedora given that systemd-boot and kernel-install are shipped by systemd it could be expected that both work together
tl;dr: things work in F37. If not, please open a new bug. Long version: The story is complicated because of history and backwards-compatibility requirements. systemd provides /usr/lib/kernel/install.d/90-loaderentry.install. That file will create a boot loader entry. But it contains a check that layout=bls, where layout is configured by /etc/kernel/install.conf or autodetected. I assume you don't have layout specified in /etc/kernel/install.conf, so autodetection needs to be performed. 'bootctl install' creates loader/entries.srel, and if that file is present, kernel-install will autodetect layout as 'bls'. That code was added in systemd-251. Options to get 90-loaderentry.install to work: 1. add 'layout=bls' in /etc/kernel/install.conf 2. make sure that loader/entries.srel is present Also, things will only work properly in F37. At this point we don't want to backport things to F36-. It is possible that things are broken there, but the risk for regressions if we try to change anything is just too high. On the other hand, if something does now work in F37, then it is a bug that should be reported. In that case, please open a new bug or reopen this one. Please include the package versions of relevant packages (i.e. at least systemd* and grub*), and also the output from 'kernel-install -v add …'. I'll also report a bug against /usr/lib/kernel/install.d/92-crashkernel.install, since it spews errors if grubby is not installed.
> I'll also report a bug against /usr/lib/kernel/install.d/92-crashkernel.install, since it spews errors if grubby is not installed. Actually, the bug is already open: #2121912.
> I assume you don't have layout specified in /etc/kernel/install.conf this file don't exist on machines installed 10 years ago and upgraded with yum/dnf at all > make sure that loader/entries.srel is present F36 has systemd-250 so it wasn't created by "bootctl install" will both be created after upgrade to F37 next year and running "bootctl update" and if not what they are supposed to contain?
*** Bug 2133294 has been marked as a duplicate of this bug. ***