bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)

[Dridi Boukelmoune]

On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
<snip>
>  This makes the assumption, which was also made earlier in the
> thread,
>  that it's somehow impossible to check what bootloader is installed.
>  Why? My bootloader is happy to tell me its version:
>  $ bootctl
>           ...
>  Current Boot Loader:
>        Product: systemd-boot 241-565-g43d51bb
>       Features: ✓ Boot counting
>                 ✓ Menu timeout control
>                 ✓ One-shot menu timeout control
>                 ✓ Default entry control
>                 ✓ One-shot entry control
>           File: /EFI/systemd/systemd-bootx64.efi
>           ...
>  Nowadays it's gives the exact git commit it's built from, in the past
>  it was just the release version, but either is enough. Therefore
>  'bootctl update' can fairly reliably *update*, i.e. do the installation
>  if the thing we have is newer than the version already installed. 
That's news to me, and unfortunately it doesn't look as nifty on my system:

...
Current Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
          ESP: n/a
         File: └─n/a

Available Boot Loaders on ESP:
          ESP: /boot/efi (/dev/disk/by-partuuid/$UUID)
         File: └─/EFI/BOOT/BOOTIA32.EFI
         File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loaders Listed in EFI Variables:
        Title: Fedora
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/$UUID
         File: └─/EFI/fedora/shimx64.efi

        Title: Linux Firmware Updater
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/$UUID
         File: └─/EFI/fedora/shimx64.efi
...

Where $UUID is the same for all three occurrences.

Dridi

[Lennart Poettering]

On Mo, 06.05.19 09:20, Dridi Boukelmoune (dridi.boukelmoune(a)gmail.com) wrote:

>  On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  <snip>
>  > This makes the assumption, which was also made earlier in the thread,
>  > that it's somehow impossible to check what bootloader is installed.
>  > Why? My bootloader is happy to tell me its version:
>  > $ bootctl
>  >          ...
>  > Current Boot Loader:
>  >       Product: systemd-boot 241-565-g43d51bb
>  >      Features: ✓ Boot counting
>  >                ✓ Menu timeout control
>  >                ✓ One-shot menu timeout control
>  >                ✓ Default entry control
>  >                ✓ One-shot entry control
>  >          File: /EFI/systemd/systemd-bootx64.efi
>  >          ...
>  > Nowadays it's gives the exact git commit it's built from, in the past
>  > it was just the release version, but either is enough. Therefore
>  > 'bootctl update' can fairly reliably *update*, i.e. do the installation
>  > if the thing we have is newer than the version already installed.
>
>  That's news to me, and unfortunately it doesn't look as nifty on my system:
>
>  ...
>  Current Boot Loader:
>        Product: n/a
>       Features: ✗ Boot counting
>                 ✗ Menu timeout control
>                 ✗ One-shot menu timeout control
>                 ✗ Default entry control
>                 ✗ One-shot entry control
>            ESP: n/a
>           File: └─n/a 
That only works properly on distros that implement the boot loader
spec and the boot loader interface properly:

https://systemd.io/BOOT_LOADER_SPECIFICATION
https://systemd.io/BOOT_LOADER_INTERFACE

Unfortunately, Fedora/grub do not support either.

(Which is a pity of course, since it also means there's no working
"systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl
kexec" support).

Lennart

--
Lennart Poettering, Berlin

[Dridi Boukelmoune]

Hi,

>  That only works properly on distros that implement the boot loader
>  spec and the boot loader interface properly:
>
>  https://systemd.io/BOOT_LOADER_SPECIFICATION
>  https://systemd.io/BOOT_LOADER_INTERFACE 
Thanks for the links, I looked briefly when you replied but figured
I'd need a quiet setup since this is unfamiliar territory. I have
finally read both documents, and they are very accessible even to
someone without prior knowledge.

>  Unfortunately, Fedora/grub do not support either.
>
>  (Which is a pity of course, since it also means there's no working
>  "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl
>  kexec" support). 
I see. Do I understand from reading the specification that it was put
together during the Fedora 18 days? Do I understand from reading the
boot loader interface documented that systemd supported all this in
the f18 days too?

Thanks,
Dridi

[Lennart Poettering]

On Sa, 10.08.19 12:18, Dridi Boukelmoune (dridi.boukelmoune(a)gmail.com) wrote:

>  Hi,
>
>  > That only works properly on distros that implement the boot loader
>  > spec and the boot loader interface properly:
>  >
>  > https://systemd.io/BOOT_LOADER_SPECIFICATION
>  > https://systemd.io/BOOT_LOADER_INTERFACE
>
>  Thanks for the links, I looked briefly when you replied but figured
>  I'd need a quiet setup since this is unfamiliar territory. I have
>  finally read both documents, and they are very accessible even to
>  someone without prior knowledge.
>
>  > Unfortunately, Fedora/grub do not support either.
>  >
>  > (Which is a pity of course, since it also means there's no working
>  > "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl
>  > kexec" support).
>
>  I see. Do I understand from reading the specification that it was put
>  together during the Fedora 18 days? Do I understand from reading the
>  boot loader interface documented that systemd supported all this in
>  the f18 days too? 
Well, it went through many revisions, and some of the bits are very
recent. For example, the pre-boot random seed stuff has been added in
v243, of which we only posted an -rc1 so far,

However, the basics have been around very early on, yes.

Lennart

--
Lennart Poettering, Berlin

[Dridi Boukelmoune]

>  Well, it went through many revisions, and some of the bits are very
>  recent. For example, the pre-boot random seed stuff has been added in
>  v243, of which we only posted an -rc1 so far,
>
>  However, the basics have been around very early on, yes. 
Well, from someone not versed in bios, efi and bootloaders the spec
looks reasonable. Now I'm wondering why Fedora doesn't implement the
interface. Is it only a matter of someone driving the change? Was
there some push-back? Or is it more complicated because it needs to
involve the installer and a dozen other components?

Dridi

[Chris Murphy]

On Thu, Aug 15, 2019 at 9:14 AM Dridi Boukelmoune
<dridi.boukelmoune(a)gmail.com&gt; wrote:
>  > Well, it went through many revisions, and some of the bits are very
>  > recent. For example, the pre-boot random seed stuff has been added in
>  > v243, of which we only posted an -rc1 so far,
>  >
>  > However, the basics have been around very early on, yes.
>
>  Well, from someone not versed in bios, efi and bootloaders the spec
>  looks reasonable. Now I'm wondering why Fedora doesn't implement the
>  interface. Is it only a matter of someone driving the change? Was
>  there some push-back? Or is it more complicated because it needs to
>  involve the installer and a dozen other components? 
Implementing the interface needs to happen in the bootloader. Someone
would need to do the work in GRUB in a way that GRUB upstream will
accept. And then Fedora will get it when rebasing.

-- 
Chris Murphy