bootctl is used by systemd-boot. It you don't have it installed / don't use it, then I don't expect bootctl to show a reasonable status because GRUB does not use it or rely on it.

(In reply to Marta Lewandowska from comment #1)

Perhaps, we could make an issue upstream, with bootctl, to detect when systemd-boot is not the default bootloader? It wouldn't need to detect the presence of others; merely that *it* isn't the default.

(In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #2)
> (In reply to Marta Lewandowska from comment #1)
> 
> Perhaps, we could make an issue upstream, with bootctl, to detect when
> systemd-boot is not the default bootloader? It wouldn't need to detect the
> presence of others; merely that *it* isn't the default.

I like and support this proposal; it's clean and simple. "Don't use it" is rather harsh advice, especially coming from RHT.

(In reply to DACBARBOS Brand from comment #3)

> I like and support this proposal; it's clean and simple. "Don't use it" is
> rather harsh advice, especially coming from RHT.

Thank you. I've filed https://github.com/systemd/systemd/issues/38834#issue-3388249429.

(In reply to DACBARBOS Brand from comment #3)
> (In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #2)
> > (In reply to Marta Lewandowska from comment #1)
> > 
> > Perhaps, we could make an issue upstream, with bootctl, to detect when
> > systemd-boot is not the default bootloader? It wouldn't need to detect the
> > presence of others; merely that *it* isn't the default.
> 
> I like and support this proposal; it's clean and simple. "Don't use it" is
> rather harsh advice, especially coming from RHT.

Hi, I didn't write "don't use it" as advice. I wrote that if you don't have sd-boot installed or (/) you don't use it, then bootctl will not show a reasonable status.

(In reply to Marta Lewandowska from comment #5)

> Hi, I didn't write "don't use it" as advice. I wrote that if you don't have
> sd-boot installed or (/) you don't use it, then bootctl will not show a
> reasonable status.

Per https://github.com/systemd/systemd/issues/38834#issuecomment-3265211899, my comprehension of this differs, in that the problem appears to be due to a misconfiguration by RedHat, which has violated the BLS. If correct, the title of issue should likely be rescoped to specify that, since although upstream can feasibly add support for variables in paths, RH can also remove it until then, or wait for that.

(In reply to Marta Lewandowska from comment #5)
> (In reply to DACBARBOS Brand from comment #3)
> > (In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #2)
> > > (In reply to Marta Lewandowska from comment #1)
> > > 
> > > Perhaps, we could make an issue upstream, with bootctl, to detect when
> > > systemd-boot is not the default bootloader? It wouldn't need to detect the
> > > presence of others; merely that *it* isn't the default.
> > 
> > I like and support this proposal; it's clean and simple. "Don't use it" is
> > rather harsh advice, especially coming from RHT.
> 
> Hi, I didn't write "don't use it" as advice. I wrote that if you don't have
> sd-boot installed or (/) you don't use it, then bootctl will not show a
> reasonable status.

Hi Marta, I apologize if I misread your comment. While a simple `dmesg | grep secureboot` would provide the fastest answer to the question of whether or not Secure Boot is in use on a given system, I very much like the verbose, well-formatted, and complete output of the `bootctl` command. Its man page highlights the shortcoming (hopefully) addressed by the newly raised upstream issue. Under the is-installed (sub)command, the `bootctl(1)` manual states regarding checking: "...neither whether it is the default". Due to the fact that `bootctl` is part of the systemd project, which major distributions adopted long ago, using it (regardless of whether or not sd-boot is/was installed or chosen as default) comes naturally. Actually, I came here after reading this one-year-old thread: https://discussion.fedoraproject.org/t/default-boot-entry-is-broken/135311. There was an even older thread about moving from GRUB to systemd-boot here: https://discussion.fedoraproject.org/t/moving-from-grub-to-systemd-boot/82760/12. With that said, we should focus on the issue at hand. Thank you.

(In reply to DACBARBOS Brand from comment #7)
> Hi Marta, I apologize if I misread your comment. While a simple `dmesg |
> grep secureboot` would provide the fastest answer to the question of whether
> or not Secure Boot is in use on a given system, I very much like the
> verbose, well-formatted, and complete output of the `bootctl` command. Its
> man page highlights the shortcoming (hopefully) addressed by the newly
> raised upstream issue. Under the is-installed (sub)command, the `bootctl(1)`
> manual states regarding checking: "...neither whether it is the default".
> Due to the fact that `bootctl` is part of the systemd project, which major
> distributions adopted long ago, using it (regardless of whether or not
> sd-boot is/was installed or chosen as default) comes naturally. Actually, I
> came here after reading this one-year-old thread:
> https://discussion.fedoraproject.org/t/default-boot-entry-is-broken/135311.
> There was an even older thread about moving from GRUB to systemd-boot here:
> https://discussion.fedoraproject.org/t/moving-from-grub-to-systemd-boot/
> 82760/12. With that said, we should focus on the issue at hand. Thank you.

No problem. ;) I didn't want you to think anyone was being hostile, that's all!

When it comes to Secure Boot, you can also use mokutil commands:
# mokutil --sb-state
to show if it is enabled, and a variety of other commands to examine, import, export Secure Boot keys, set sbat policy, etc.

But I understand that you want bootctl to work, and it looks like Zbyszek is already working on getting this fixed in the issue Mr. Beedell filed... I don't really want to open the sd-boot can of worms here, but one huge reason that we can't just move to that from GRUB is that it only supports UEFI and has no plans to support anything else. If your machine is UEFI, you are welcome to use sd-boot though. ;)

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This persists in F44, too, so please update it.

(In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #10)
> This persists in F44, too, so please update it.

I hereby confirm this statement. No change, so far. Just (re)tested!

dacbarbos@vivobookone:~$ hostnamectl
     Static hostname: vivobookone.internal
           Icon name: computer-laptop
             Chassis: laptop 💻
   Chassis Asset Tag: DACBARBOS
          Deployment: development
            Location: Romania, non-fixed (movable)
          Machine ID: 1fa1d932ed2f42f382d4a8455c1cb58e
             Boot ID: 38613ed1ab4146d4870bc67ed08cedd0
    Operating System: Fedora Linux 44 (Workstation Edition)
         CPE OS Name: cpe:/o:fedoraproject:fedora:44
      OS Support End: Wed 2027-05-19
OS Support Remaining: 1y 1w                                
              Kernel: Linux 7.0.4-200.fc44.x86_64
        Architecture: x86-64
     Hardware Vendor: ASUSTeK COMPUTER INC.
      Hardware Model: VivoBook_ASUS Laptop X505ZA_X505ZA
    Hardware Version: 1.0
    Firmware Version: X505ZA.313
       Firmware Date: Tue 2020-02-25
        Firmware Age: 6y 2month 2w 1d                      
dacbarbos@vivobookone:~$ 
dacbarbos@vivobookone:~$ sudo bootctl status
[sudo] password for dacbarbos: 
systemd-boot not installed in ESP.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-0-rescue.conf:6: Unknown line 'grub_users', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-0-rescue.conf:7: Unknown line 'grub_arg', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-0-rescue.conf:8: Unknown line 'grub_class', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-6.19.14-300.fc44.x86_64.conf:6: Unknown line 'grub_users', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-6.19.14-300.fc44.x86_64.conf:7: Unknown line 'grub_arg', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-6.19.14-300.fc44.x86_64.conf:8: Unknown line 'grub_class', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-6.19.14-200.fc43.x86_64.conf:6: Unknown line 'grub_users', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-6.19.14-200.fc43.x86_64.conf:7: Unknown line 'grub_arg', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-6.19.14-200.fc43.x86_64.conf:8: Unknown line 'grub_class', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-7.0.4-200.fc44.x86_64.conf:6: Unknown line 'grub_users', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-7.0.4-200.fc44.x86_64.conf:7: Unknown line 'grub_arg', ignoring.
/boot/loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-7.0.4-200.fc44.x86_64.conf:8: Unknown line 'grub_class', ignoring.
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: firmware only, driver unavailable
  Measured UKI: no
  Boot into FW: supported

Current Boot Loader:
       Product: GRUB 2.12
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✗ Multi-Profile UKIs are supported
               ✗ Loader reports network boot URL
               ✗ Support Type #1 uki field
               ✗ Support Type #1 uki-url field
               ✗ Loader reports active TPM2 PCR banks
     Partition: /dev/disk/by-partuuid/53e0b5b5-e6e9-4f2e-adba-363d99d11f3c

Random Seed:
 System Token: not set
       Exists: no

Available Boot Loaders on ESP:
          ESP: /boot/efi (/dev/disk/by-partuuid/53e0b5b5-e6e9-4f2e-adba-363d99d11f3c)
         File: ├─/boot/efi//EFI/BOOT/BOOTIA32.EFI
               ├─/boot/efi//EFI/BOOT/BOOTX64.EFI
               ├─/boot/efi//EFI/BOOT/fbia32.efi
               └─/boot/efi//EFI/BOOT/fbx64.efi

Boot Loaders Listed in EFI Variables:
        Title: Fedora
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/53e0b5b5-e6e9-4f2e-adba-363d99d11f3c
         File: └─/boot/efi//EFI/FEDORA/SHIMX64.EFI

        Title: Fedora
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/53e0b5b5-e6e9-4f2e-adba-363d99d11f3c
         File: └─/boot/efi//EFI/FEDORA/SHIM.EFI

Boot Loader Entry Locations:
          ESP: /boot/efi (/dev/disk/by-partuuid/53e0b5b5-e6e9-4f2e-adba-363d99d11f3c)
       config: /boot/efi//loader/loader.conf: No such file or directory
     XBOOTLDR: /boot (/dev/disk/by-partuuid/8b231836-553c-453b-ba32-8c6858e9d0bd, $BOOT)
        token: fedora

Default Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: Fedora Linux (7.0.4-200.fc44.x86_64) 44 (Workstation Edition)
           id: 1fa1d932ed2f42f382d4a8455c1cb58e-7.0.4-200.fc44.x86_64.conf
       source: /boot//loader/entries/1fa1d932ed2f42f382d4a8455c1cb58e-7.0.4-200.fc44.x86_64.conf (on the Extended Boot Loader Partition)
      version: 7.0.4-200.fc44.x86_64
        linux: /boot//vmlinuz-7.0.4-200.fc44.x86_64
       initrd: /boot//initramfs-7.0.4-200.fc44.x86_64.img $tuned_initrd (No such file or directory)
      options: root=UUID=7c8d038f-d200-4db0-957e-ebc0206240a7 ro rootflags=subvol=root rd.luks.uuid=luks-3a54ebee-d20c-4f27-b0dd-cb0787f4c170 rhgb qui>

WARNING: default boot entry is broken
dacbarbos@vivobookone:~$

Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

You didn't update the https://bugzilla.redhat.com/page.cgi?id=fields.html#version.

The issue is further tracked under (linked) BZ2486955, as a follow-up for F44 (current release).
As it turned out, the culprit seems to be a param injected by tuned scriptlets.
Please refer to the new ticket. This has been closed due to EOL condition.

I'd re-close this as a duplicate of that ticket. Generally, if a ticket is EOL'd, one just re-opens it with the latest version applied, instead.