I can't escape to interactive mode with autoboot_delay="0" after pressing any key

[nxjoseph]

I don't want to wait any seconds on the loader but have a chance to escape to single-user mode if i need to. The manpage of loader.conf(5) states that I could escape to interactive mode if i press any key while system is loading, tried it but could not enter to it.

autoboot_delay
                   If set to “0”, no delay is inserted, but any keys pressed
                   while the kernel and modules are loaded will enter
                   interactive mode.

 

[Phishfry]

Try setting it to -1

 

[nxjoseph]

Try setting it to -1

But:

                   If set to “-1”, no delay will be inserted and loader.conf
                   starts interactive mode only if autoboot has failed.  In
                   combination with the beastie_disable option, this option
                   prevents users with console access from being able to
                   interrupt the autoboot process and escape to the loader
                   prompt.  To use the autoboot_delay option in this manner,
                   beastie_disable must be set to “YES”.

 

[mer]

I don't have an answer to this, but I hate when the delay is set too short. 99% of the time I don't care, but that 1% "it's <insert your favorite curses here> short". For me 3 or 5 secs is acceptable delay on booting. Short enough I don't really feel it, long enough for me to hit the "any" key.

Everyone is different, everyone has their own requirements. My systems stay up until updates so extra time during boot becomes noise.

Above just my opinions on what works for me

 

[fmc000]

I have 1 and it works just fine, a good compromise IMHO.

 

[tembun]

I would guess that maybe with '0' you should be hitting the key really fast enough for it to trigger the interactive mode. I remember I desired the system to be loading as fast as it even possible and I also tried both '0' and '-1' for autoboot_delay. However, I don't remember exactly what was the case, but a) I once had a nasty problem (probably that was when I tested one of my custom kernels) when I needed a boot menu and I could not do this due to '-1', and b) I got sort of tired of constantly hitting the keyboard in order to escape to single user mode. So I set autoboot_delay to '2' - you virtually don't feel it during regular boot and at the same time it's plenty when you know you're going to escape to boot loader. So, I second that short delay is a good compromise, as fmc000 said.

 

[nxjoseph]

The main problem is here is that the loader does not behave as the manpage says. I've looked at /usr/src/stand/common/boot.c, i don't know if it's the right file but i could not figure it out.

 

[Emrion]

I think the files of interest are /usr/src/stand/lua/menu.lua, /usr/src/stand/lua/core.lua and /usr/src/stand/common/boot.c.

I don't know lua but reading it seems not that difficult.

menu.lua calls core.boot quickly, but before it leaves one execution of the loop inside the menu.autoboot function that is looking for Enter, Space,... and the choices available in the menu. It's maybe too fast to actually works.

After that, the execution is given to core.boot and I see no detection of keystroke. I see nothing in boot.c as well, if timeout is zero.

 

[SirDice]

The manpage of loader.conf(5) states that I could escape to interactive mode if i press any key while system is loading, tried it but could not enter to it.

It was written at a time when loading the actual loader(8) was done by the boot code. And that took some time. Is this an UEFI booting system? That probably loads loader.efi(8) and execute so fast you might be missing the window of opportunity.

 

[nxjoseph]

Is this an UEFI booting system? That probably loads loader.efi(8) and execute so fast you might be missing the window of opportunity.

Yes, it is UEFI. I see, this might be one of the cases, too.

% sysctl machdep.bootmethod
machdep.bootmethod: UEFI

 

[SirDice]

Yeah, UEFI booting basically skips stage 1 and 2 of the 'traditional' BIOS boot, back then loader(8) was stage 3. Nowadays, with UEFI boot it directly loads and executes loader.efi(8).

Chapter 15. The FreeBSD Booting Process

An introduction to the FreeBSD Booting Process, demonstrates how to customize the FreeBSD boot process, including everything that happens until the FreeBSD kernel has started, probed for devices, and started init

docs.freebsd.org

 

[SirDice]

One thing might work, turn the machine on and immediately keep the spacebar pressed down. You may also get a "Keyboard error" that way as it might think a key is stuck, but that might also give you a bit of extra time

 

[nxjoseph]

One thing might work, turn the machine on and immediately keep the spacebar pressed down. You may also get a "Keyboard error" that way as it might think a key is stuck, but that might also give you a bit of extra time

Haha, that didn't work either

 

[bsdimp]

The main problem is here is that the loader does not behave as the manpage says. I've looked at /usr/src/stand/common/boot.c, i don't know if it's the right file but i could not figure it out.

I should change the man page because the modules aren't loaded and then the key press checked anymore. the menu comes up, and autoboot_delay regulates how long it waits for an automatic boot. With UEFI, the best you can do, alas, is 1s since it's very very difficult to hit the small window between when the device is opened up in the loader and the check. Buffered keys often don't do the job, thanks to the UEFI BIOS. I should likely remove the '0' entry from the manual page. But I've had OK luck holding down the space key sometimes... I settled on a delay of 3, but 1 also works OK enough...

Looking at the code now, it would appear that if you have the menu enabled, it behaves a little differently than if you have it disabled. If you have it disabled, it looks like it would behave like is documented. With the menu, we loop waiting for the key and timeout to expire. We only go through the loop once, so if the key isn't there when the menu finishes drawing, you lose your chance. There's also a 1 second granularity, so on the average, we'll wait 1/2 second less than the number of seconds specified. We do loop with a delay of 50ms, but we're effectively just waiting for the second to tick. It could be much better, but we'd have to build out sub-second support in the rest of libsa on all the platforms...

It's true even for our BIOS loader, though there there is a chance to get some characters into the buffer, but it's also far too easy to screw up the boot and wind up not knowing what to type to get your /boot/loader loaded...

So the real problem is menu has different behavior than cli, and the man page documents the cli.

 

[bsdimp]

I just committed the following change to the loader.conf.5 man page:

-no delay is inserted, but any keys pressed while the kernel and modules are
-loaded will enter interactive mode.
+no delay will be inserted and the boot will proceed immediately unless a key
+has already been pressed, which may be practically impossible.

which matches your experience.