1

How can I change the 'timeout' setting of the EFI boot manager? I am trying to dual-boot Windows 8 and Ubuntu and I would like to be able to choose one or the other OS at my machine boot time.

I already tried to use sudo efibootmgr -t 10 from within Ubuntu, but that didn't work for me as I don't see a list to choose from when my computer loads but boots directly to grub.

Here are more details:

$ efibootmgr -v
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000,0002
Boot0000* debian        HD(13,GPT,007a058a-8e5e-45df-8d97-6575b66b5355,0x1afa9000,0x113000)/File(\EFI\debian\grubx64.efi)
Boot0002* Windows Boot Manager  HD(13,GPT,007a058a-8e5e-45df-8d97-6575b66b5355,0x1afa9000,0x113000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................

$ bootctl status
systemd-boot not installed in ESP.
System:
     Firmware: n/a (n/a)
  Secure Boot: disabled
   Setup Mode: user

Current Boot Loader:
      Product: n/a
     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
               - Boot loader sets ESP partition information
          ESP: n/a
         File: `-n/a

Random Seed:
 Passed to OS: no
 System Token: not set
       Exists: no

Available Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355)
         File: `-/EFI/BOOT/bootx64.efi

Boot Loaders Listed in EFI Variables:
        Title: debian
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355
         File: `-/EFI/debian/grubx64.efi

        Title: Windows Boot Manager
           ID: 0x0002
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355
         File: `-/EFI/Microsoft/Boot/bootmgfw.efi

Boot Loader Entries:
        $BOOT: /efi (/dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355)

0 entries, no entry could be determined as default.

Is it because of the systemd-boot not installed in ESP?

UPDATE:

Here is my status after carrying out the tasks in Peter's answer.

$ efibootmgr -v
BootCurrent: 0000
Timeout: 6 seconds
BootOrder: 0001,0000,0002
Boot0000* debian        HD(13,GPT,007a058a-8e5e-45df-8d97-6575b66b5355,0x1afa9000,0x113000)/File(\EFI\debian\grubx64.efi)
Boot0001* Linux Boot Manager    HD(13,GPT,007a058a-8e5e-45df-8d97-6575b66b5355,0x1afa9000,0x113000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0002* Windows Boot Manager  HD(13,GPT,007a058a-8e5e-45df-8d97-6575b66b5355,0x1afa9000,0x113000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................

$ bootctl status
System:
     Firmware: n/a (n/a)
  Secure Boot: disabled
   Setup Mode: user

Current Boot Loader:
      Product: n/a
     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
               - Boot loader sets ESP partition information
          ESP: n/a
         File: `-n/a

Random Seed:
 Passed to OS: no
 System Token: set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355)
         File: `-/EFI/systemd/systemd-bootx64.efi (systemd-boot 245.4-4ubuntu3.1)
         File: `-/EFI/BOOT/bootx64.efi (systemd-boot 245.4-4ubuntu3.1)

Boot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355
         File: `-/EFI/systemd/systemd-bootx64.efi

        Title: debian
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355
         File: `-/EFI/debian/grubx64.efi

        Title: Windows Boot Manager
           ID: 0x0002
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355
         File: `-/EFI/Microsoft/Boot/bootmgfw.efi

Boot Loader Entries:
        $BOOT: /efi (/dev/disk/by-partuuid/007a058a-8e5e-45df-8d97-6575b66b5355)

0 entries, no entry could be determined as default.

$ cat "$(bootctl -x)/loader/loader.conf"
#timeout 3
#console-mode keep
default f1439fc415644fedb2360e6691283080-*

timeout 5
console-mode max
editor yes
auto-entries yes
auto-firmware yes
random-seed-mode always

$ bootctl status | grep f1439fc415644fe | wc
      0       0       0

So Peter,

  • where does the default f1439fc415644fedb2360e6691283080-* comes from in the /loader/loader.conf file and what does it means? And what did you mean when you put default Windows there?
  • and most importantly, I now can see that EFI Boot list/menu, just it has Windows Boot Manager and the Reboot into firmware your mentioned, but it doesn't have the Linux / debian menu that I want. what I'm missing?
3
  • The string after default is a UUID generated when your distribution is installed that's basically guaranteed not to match any other possible install, which allows you to have two installations of Debian or Debian and a derivative like Ubuntu that may share some identifiers and differentiate them without first forcing you to "name" them and then remember the names later. I suggested to swap it out with just Windows more or less to illustrate that's how you would change the OS that boots at the end of the timeout period if no choice was made; it's just a substring match with any entry. Sep 6, 2021 at 22:59
  • I found the missing step that left you without a Debian entry, and man, I'm sorry for giving you a half answer; I got this all configured right when systemd absorbed Gummiboot ~6.5 years ago and totally forgot that I automated part of it with apt hooks. What you need to do is use the kernel-install command to copy your kernel to the ESP, that's gonna look like: sudo kernel-install add "$(uname -r)" and then the path to your kernel image (usually named <something>-vmlinuz in the /boot directory). I'm reviewing those apt hooks I made back then and will edit my answer to explain them. Sep 6, 2021 at 23:13
  • Please do Peter, as I tried to find out how to make use of kernel-install, but didn't find much useful hits, and all of my previous installing Linux kernel experiences only limit to linstalling the inux-image-xxx packages, and when it fails, use update-initramfs. that's it. So appreciate your clear instruction and your editing your answer to explain them. thx.
    – xpt
    Sep 12, 2021 at 20:15

1 Answer 1

0

Well, to your question of whether the behavior you're experiencing is because systemd-boot isn't installed in the ESP, the answer is..."Not really?" Haha, this is a tough one for me, because I happen to know quite a bit about the whole EFI boot process and the various ways to manage it, and actually systemd-boot is playing no part in it right now. GRUB is the mechanism that Ubuntu has always turned to for managing the boot process, irrespective of whether you have other operating systems that you want to retain access to. I could guide you through a few methods to likely get it to behave more in line with your expectations, and that's probably the more professional way to answer your question, to be fair.

That's not what I'm going to do, though, because I gotta tell you, GRUB is such a massive pain in the butt that I wouldn't wish it on Hitler, let alone a stranger like you. So take my advice with whatever weight you deem appropriate, I'm going to present a couple options you have close at hand already to manage the boot process, both of which I like a lot more than GRUB even when it's actually behaving itself. Since you brought up systemd-boot (which I still think of by its original, pre-Red Hat name, "Gummiboot" because it's more fun), let's start there.

Gummiboot

Fair warning, while it really like it for its insane speed of operation and how handy it is sometimes to have a boot manager that's basically just an add-on module for the Linux init process...Christ almighty, is it ever ugly. I hate the look of GRUB and it manages to make GRUB look halfway sexy somehow. If you're cool with that, though, let me show you how quickly you can fix this issue you're having by using it instead. Start the timer, I think I can get you to a successful reboot in under four minutes.

  1. To start, let's install it to your ESP (EFI System Partition, where all the boot loaders/managers live) along with GRUB and the Windows Boot Manager, worst case scenario, you'll just ignore it in the future like you do the WBM as you use your preferred solution. Pull up a terminal, if you'd be so kind, and execute this command to install Gummiboot on the ESP and add it to the BootOrder: sudo bootctl install. You should see a flurry of activity for a second, and a message telling you that systemd-boot is installed on the ESP and at the top of the boot order. While tempting to bank the easy winner on the stopwatch since most times it works just fine without a configuration, let's do a couple more things to improve the odds while we're at it. First, in case we don't get back to a terminal before trying a reboot, execute sudo bootctl random-seed. It's super-trivial, but it's adds a minor improvement to your security at boot-time and it costs only the time it takes to type, so we'll take it.

  2. In whatever way suits you best, fire up a text editor that will permit you to edit files owned by root (I'm always partial to the ol' sudo mcedit [filename], but you do you) and open this file with it: "$(bootctl -x)/loader/loader.conf" If you're gonna use a GUI editor and need to know the exact path in order to navigate to the file, just slap an echo in front of it in the terminal and hit Enter and it'll print out the actual location. Since I don't know what version of systemd/Gummiboot you're rockin', I'll just tell you the things that should be in there and let you do the rest. Here goes...

    default Windows
    timeout 15
    console-mode max
    editor yes
    auto-entries yes
    auto-firmware yes
    random-seed-mode always
    

Feel free to leave whatever random string is already there as the default if you want to load Ubuntu if no selection is made before the menu timeout is reached, I just wanted you to see how to change it if necessary. Likewise, whatever timeout value you want to set is your business. The rest of it should go in as shown though, it's all good stuff.

Once that's done, if you want to settle your nerves you can check the output of sudo bootctl status in the terminal again, or just haul off and reboot, you should be good to go. A few quick pointers from a Gummiboot elder for you:

  • At the menu, heathens typically make a selection with the / keys and use or Enter to confirm it. A true pimp will simply press the number key on the keyboard corresponding to the entry they want from the list as though they were numbered top to bottom, with 1 being the topmost entry. Or if there is only one entry for Windows, MacOS or a Linux distribution present, pressing the letters w, a or l will instantly start booting that one from a single keystroke. It makes the girls bite their bottom lip every time.
  • That auto-firmware yes line in the file should make sure that one of the options in the list is "Reboot into firmware"...and if things go south, choose it and you'll find yourself in the BIOS settings, where you can manually rearrange the boot order and put Windows or "debian" in the top spot for salvation. It's exceedingly unlikely you'll need it, but in case you do, maybe you won't be cursing my existence afterwards. Life is short, and I don't need any more bad juju.

Conclusion

You should be rockin' and rollin' at this point, my friend. I know I said I'd give you a couple potential solutions, though, so if this doesn't get you unstuck from neutral or you find you're flirting with nihilism as a way of life from how unattractive it is visually, then without reservation, my advice would be: use rEFInd. It's in the Ubuntu repositories and configures itself, so it's always just a sudo apt install refind away, and it's the Shelby Cobra of boot managers. The documentation's great and it's smart as a whip, so if you go down that route I have no doubt you'll be fine.

My work here is done; go knock 'em dead, kid.

2
  • 1
    Haha, you have a fun writing style and it was quite an amusement reading it, and I'm glad that I asked here, as after sleeping on it, I thought it was my Asus' firmware's problem, :). And we do share the same opinion on grub. As a matter of fact, before this EFI booting fiasco of mine, I had been a happy extlinux user for decades.
    – xpt
    Sep 6, 2021 at 13:23
  • Just use this chance to rant on grub2. I love the original grub and grub4dos but really really hate grub2. The silly mistake I made in unix.stackexchange.com/questions/667910 was purely because of the S/N ratio of the generated boot menu entries file /boot/grub/grub.cfg, which really looks like a childish design, like people littering & spreading all kinds of fancy decorations in the html file, while in fact those fancy decorations and complexity should be hide in the css files, instead of making the html file as complex as hell.
    – xpt
    Sep 6, 2021 at 20:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .