# Reboots or Boots stops at  AUTOBOOT in 10 seconds



## nero (Mar 31, 2021)

Unless I hit enter on the console keyboard. My machine will not reboot. I am not sure where this setting would be.

Thanks,
T


----------



## nero (Mar 31, 2021)

fixed this by putting autoboot_delay="0" in /boot/loader.conf

Still not sure why it was waiting there and not just doing the 10 second count down.

Cheers,
T


----------



## Mjölnir (Mar 31, 2021)

Please tell which FreeBSD version & the hardware you were using.  We'd like to know the output of
`uname -aU` & `freebsd-version` (or if you downloaded an install image, which one).


----------



## SirDice (Mar 31, 2021)

Spacebar stuck? If you hit the spacebar during the countdown, the countdown stops and will wait forever.


----------



## nero (Mar 31, 2021)

So, tested the space bar and it is not stuck. 

This is a Dell Laptop that I am using temporarily as a local webserver for development purposes. So, no X11; just console.

FreeBSD ***************** 12.2-RELEASE-p3 FreeBSD 12.2-RELEASE-p3 GENERIC  amd64

i7 - 4000 something CPU
16Gigs RAM

Cheers,
T


----------



## SirDice (Mar 31, 2021)

nero said:


> So, no X11; just console.


Not relevant for the boot menu in any case. 

I'm wondering if it might be stuck in a loop trying to find boot environments or old kernels. Can you post a picture of the screen when it just sits there?


----------



## nero (Mar 31, 2021)




----------



## SirDice (Mar 31, 2021)

Ok, no boot environments and it doesn't seem to have a problem listing the kernels. That's strange. If you set the `autoboot_delay` to 0 or "NO" it boots just fine? What if you set it to 3 seconds? Will it then be stuck at 3 seconds?


----------



## nero (Mar 31, 2021)

Yeah, so set to 0 it boots just fine.

And it seems like the oddest thing to me as well. Because it is not halting at an error or anything.

I am not in a position to test right now with 3 secs; but I will report back later on today when I can test that.

Cheers,
Tamer


----------



## SirDice (Mar 31, 2021)

Maybe it has something to do with timers. When you get the chance, check the timer settings in the BIOS too. Make sure it's set to HPET or have it enabled if there's a BIOS setting for it.


----------



## Mjölnir (Mar 31, 2021)

You could look up if there's a BIOS update available for that box.


----------



## nero (Apr 1, 2021)

So, I just tried a few things. FIrst: 

There is absolutely nothing in the bios about Timers and HPET.

When I set the time to 3 it returned to the old behavior where it stopped there. Only difference was it now said Boot in 3 seconds.

And trying to figure out the bios upgrade...Will report back.

Cheers,
T


----------



## nero (Apr 1, 2021)

and bios is up to date!

T


----------



## Snurg (Apr 1, 2021)

Got curious how the new boot loader looks.

As far as I can see from a short peek, there is no keyboard queue flush before the menu is called (function menu.process in /boot/lua/menu.lua).
If my suspicion is correct, every bad OEM keyboard that sends a spurious nonsense scancode at initializing will stop the boot loader.

But maybe this is "intentional behaviour", so one can press a key without having to wait for the boot menu to appear?

Edit:
Now, having looked a bit more at the new bootloader, I am quite sure that this should be categorized as a bug, unless people claim it's a feature.
I cannot find anything that clears the keyboard queue before the first menu call, and any key that does not have a function assigned makes the bootloader wait in the menu.

So, what do you think? Bug or feature?


----------



## nero (Apr 1, 2021)

I am not sure. This is the laptop's keyboard. But I do have another USB keyboard attached. Let me disconnect that and see what happens


----------



## nero (Apr 1, 2021)

Disconnecting the external keyboard did not fix the issue.

T


----------



## Snurg (Apr 1, 2021)

Well then it is possibly your laptops' keyboard that is "bad".
At least "bad" in the sense that it sends some nonsense scancode that confuses any boot loader, which does not clear the keyboard queue before entering its menu.

Or there is another key stuck that causes the problem?
To verify this, you could write a small loop in loader.lua that clears the keyboard queue before calling menu.

Either way, I think this should be considered a bug.
Because, any keyboard with stuck key(s) could prevent a server to start up.

SirDice, what do you think?


----------



## richardtoohey2 (Apr 1, 2021)

Snurg said:


> Either way, I think this should be considered a bug.
> Because, any keyboard with stuck key(s) could prevent a server to start up.


Hmmm, maybe.  If it's got stuck keys I might want to fix that before it starts up rather that a possibly stuck key selecting an option that I don't want.


----------



## Snurg (Apr 1, 2021)

richardtoohey2 said:


> If it's got stuck keys I might want to fix that before it starts up rather that a possibly stuck key selecting an option that I don't want.


Have you also experienced stuck keys that weren't obviously stuck?
I mean, keys that report "stuck" but not visibly.
Hammering (quite) hard on that key on my laptop helped to get the key "loose" and working again.

(Btw, this is why I hate laptops. They have no real keyboard.)


----------



## richardtoohey2 (Apr 1, 2021)

You said server so I was thinking about that specific scenario.  But most of the servers I look after are "headless" anyway.


----------



## Snurg (Apr 1, 2021)

richardtoohey2 said:


> You said server so I was thinking about that specific scenario.


I'd be curious to know how many old laptops with sticky keys are being put to a last use as low-power home server, WLAN hotspot etc, like the OP plans to


----------



## SirDice (Apr 1, 2021)

I don't think it's a stuck key, that would show up when the machine's booted too. The countdown being stuck is certainly something I've never seen happening before, so I'm shooting in the dark here.


----------



## balanga (Apr 1, 2021)

Mjölnir said:


> Please tell which FreeBSD version & the hardware you were using.  We'd like to know the output of
> `uname -aU` & `freebsd-version` (or if you downloaded an install image, which one).


Never come across the -U option to uname() before...

Is see that it stands for:



> *-U* Write the FreeBSD version of the user environment.


...but not sure what that means


----------



## Mjölnir (Apr 1, 2021)

balanga said:


> Never come across the -U option to uname() before... Is see that it stands for: ...but not sure what that means


DO NOT TRY IT OUT!  That's very dangerous, because it will irreversibly _Write the FreeBSD version of the user environment_ to the stdout(4). EDIT Then you can only can get rid of it by pressing <ENTER> until it scrolls off, or close the terminal.  The latter is considered bad style on any UNIX box; it is commonly accepted _best practice_ to always have at least one terminal open.


----------



## Mjölnir (Apr 1, 2021)

Try with TPM/TPP disabled in BIOS.


----------



## Snurg (Apr 1, 2021)

SirDice said:


> I don't think it's a stuck key, that would show up when the machine's booted too.


Did some tests with installer CD (slow boot, enough time to press keys before boot menu is displayed).
There is indeed no keyboard queue clearing.
And it also depends which key(s) are pressed.
For example PgDn stops, End does not.
Furthermore, these non-printable keys also are not shown.

Again the question: _Is it good practice to not clear the keyboard queue?_

The key seems that the countdown is not being displayed in case there is something in the keyboard queue.

So I guess the bug that affects the OP consists in using the tickless HPET timer instead of the traditional timer.

nero, could you please try this setting in /boot/loader.conf?

```
kern.eventtimer.periodic = 1
```


----------



## Snurg (Apr 2, 2021)

There also could be more timer issues. No idea whether nero 's problem might be related to this.


----------



## nero (Apr 3, 2021)

I will try this when back near the device as I am remote right now. WIll do and report back.

Cheers,


----------



## _martin (Apr 3, 2021)

What is the contents of your /boot/loader.conf ? Any chance you have some sort of serial device connected to this book?


----------



## nero (Apr 3, 2021)

Mjölnir said:


> SirDice said:
> 
> 
> > I don't think it's a stuck key, that would show up when the machine's booted too. The countdown being stuck is certainly something I've never seen happening before, so I'm shooting in the dark here.
> ...






Mjölnir said:


> Try with TPM/TPP disabled in BIOS.


Will give this a try when local to the machine. However, I am fairly sure that is disabled as there is no TPM module installed on the machine. So, fairly sure that is not on and remember being off the last time I looked in the bios.

The machine is a Laptop; but it is an i7 4xxx series with 2 NVME SSDs and 16G RAM. So, it is pretty much better than most cloud VMs I have used. LOL ...


----------



## nero (Apr 3, 2021)

FYI...here is the content of the boot/loader.conf

security.bsd.allow_destructive_dtrace=0
efi_max_resolution="1920x1080"  # Set the max resolution for EFI loader to use:
autoboot_delay="0"
accf_http_load="YES"
accf_data_load="YES"


----------



## _martin (Apr 3, 2021)

I asked about serial device (serial console, etc.) because I had problems with these before. During reboot the other side of the connection sent random data aborting the boot process (as if somebody pressed a key).


----------



## nero (Apr 3, 2021)

_martin said:


> I asked about serial device (serial console, etc.) because I had problems with these before. During reboot the other side of the connection sent random data aborting the boot process (as if somebody pressed a key).


Yeah, there are no serial devices at all. And after removing the external USB keyboard; no external peripherals at all. Just RJ45 & Power connected and nothing else.

T


----------



## zirias@ (Apr 3, 2021)

Snurg said:


> Again the question: _Is it good practice to not clear the keyboard queue?_


IMHO good practice, otherwise you can't set a very low delay and still intervene if necessary.


----------



## Snurg (Apr 3, 2021)

Zirias said:


> IMHO good practice, otherwise you can't set a very low delay and still intervene if necessary.


You completely misunderstood me.
It is about clearing the keyboard queue from any leftover garbage _before_ reading the menu input, _when_ the menu is been displayed.

Imagine a dialog menu "Delete the HDD and install XYZ on it" appearing, and some key still in the keyboard queue hasn't been cleared, so that the dialog just briefly flashes up and proceeds with deleting the HDD. Good or not?
So personally, I think that not clearing the keyboard buffer before running interactive dialog applications in principle is a mistake.
When computers were slower than today, this was even more important.


----------



## zirias@ (Apr 3, 2021)

Snurg said:


> You completely misunderstood me.
> It is about clearing the keyboard queue from any leftover garbage _before_ reading the menu input, _when_ the menu is been displayed.


Nope, that's exactly the scenario I'm talking about.

Pretty much the same as every BIOS I know will recognize the keys for entering setup or invoking the boot menu, even if pressed some time before the hint is displayed.



Snurg said:


> Imagine a dialog menu "Delete the HDD and install XYZ on it" appearing, and some key still in the keyboard queue hasn't been cleared,


That's a _different_ scenario. Potentially harmful actions should never be triggered based on some keyboard buffer contents.


----------



## Snurg (Apr 4, 2021)

Zirias said:


> Nope, that's exactly the scenario I'm talking about.
> 
> Pretty much the same as every BIOS I know will recognize the keys for entering setup or invoking the boot menu, even if pressed some time before the hint is displayed.


You are, as we Germans say, comparing pears with apples.
The FreeBSD bootloader has a configurable delay, in case the default 10 seconds are deemed insufficient.
Many consumer board BIOSes behave like you said, but this is not the case with workstations and servers. There it can take minutes until the keyboard flashes up and you have perhaps two or three seconds to hit the Setup key.

Again, what I said is about potential stuck keys or spurious scancodes from bad keyboards. Not all BIOSes stop when detecting stuck keys, leading to the risk that the FreeBSD bootloader can potentially prevent servers from restart. This is the scenario, which I consider as potential harmful.

And now I am very curious what nero will report about his tests with various timer sources etc!


----------



## zirias@ (Apr 4, 2021)

Snurg I was pretty explicit about the scenario: I want to set a very short timeout and still be able to intervene. That's what _*I*_ expect. Therefore, I think not clearing the input buffer for a bootloader is a good thing. You're thinking the opposite, not really hiding it, and it seems you were looking for confirmation. That's ok, but please accept my opinion is different.


----------



## nero (Apr 9, 2021)

So, I had completely lost track of this discussion. My apologies. I am back at the machine's location and can run any tests that anyone may be interested in. I am just not sure where it was left of and if anyone wanted me to try anything else. I was even considering disabling the keyboard somehow; but unable to find a none-destructive way.

At this point I just keep the autoboot_delay="0" which seems to work well enough.

Cheers,
T


----------



## seb101 (Apr 8, 2022)

Hi.  I am having this exact same issue on FreeBSD 12.  Hardware is a SuperMicro X11SSL with Xeon E3 processor.

The autoboot timer freezes at whatever is set in the boot loader config.  The only way to ensure a boot is to set the timer to 0.

Did this ever get resolved?


----------



## seb101 (Apr 8, 2022)

OK, might have solved this.  Trawling through the BIOS looking for relevant settings I noticed that the BIOS clock was stuck at 00:00:00 00/00/0000, odd because the system time was working fine inside the OS. 

Manually setting the clock in the BIOS seemed to 'unfreeze' it.  Now the countdown works in the boot screen too.

So it seems the autoboot countdown relies on the RTC rather than a CPU frequency timer?


----------



## seb101 (Apr 8, 2022)

It further appears I have some sort of BIOS corruption on this board that stops the clock persisting over reboots, despite the rest of the BIOS settings persisting.  Replacing the CMOS battery and resetting the CMOS did not fix this.

I can now reliably reproduce the error and fix however. 

Scenario 1:
If I boot the system normally the BIOS clock shows 00:00:00 00/00/0000 and the FreeBSD auto-boot timer freezes. 

Scenario 2:
If I boot the system, enter the BIOS and manually set the clock, then boot FreeBSD the auto-boot timer works as expected.

So it's fairly certain this issue is related to the RTC.


----------



## jbo (Apr 8, 2022)

Just out of personal curiosity: In scenario 2, does the clock actually advance/run afterwards? I'd be curious to know whether FreeBSD is unable to boot when the clock is zero vs. whether the clock is not running at all.


----------



## seb101 (Apr 8, 2022)

jbodenmann said:


> Just out of personal curiosity: In scenario 2, does the clock actually advance/run afterwards? I'd be curious to know whether FreeBSD is unable to boot when the clock is zero vs. whether the clock is not running at all.


Once the clock is set in the BIOS it runs normally, I can't force a situation where it freezes on anything other than 00:00:00.  I would guess that any 'frozen' clock state would stop the autoboot timer from advancing, but can't be sure.


----------



## Erichans (Apr 8, 2022)

When still in warranty: contact your supplier. If out of warranty and if the RTC consistently cannot hold its value after a reboot and/or powercyle (even with a new battery), I'd consider contacting Supermicro Europe for possible diagnosis and or repairs.


----------



## jbo (Apr 8, 2022)

In case you can´t get a replacement/repair from your supplier/vendor/manufacturer and you don´t have a (local) repair shop feel free to drop a PM - not the first time we´d be reworking mainboards. Obviously no promises - would need more information first.


----------



## seb101 (Apr 9, 2022)

Quick update on this.  The issue was an odd one and almost certainly a BIOS bug, as the system was in fact remembering the correct current time but the BIOS was failing to restore the clock to the correct value on boot, what it seemed to be doing was restoring a corrupt value to the clock which would prevent it from 'ticking' - this was evidenced by often seeing 'impossible' times appearing in the BIOS clock (see attachment).  I then discovered that all I needed to do was 'tab' into the clock setting option in the BIOS and _without entering any values_ the clock would immediately restore to the correct current time and tick and boot would proceed normally.   Upon reboot it would fail again unless the same proceedure was applied.

Trying various things to track down this issue it turned out to be some sort of interoperability issue between the Supermicro BIOS and the BIOS option ROM on the LSI 9211 HBA.  When the LSI card was in BIOS option ROM mode (the classic 'Press CTRL+C to enter setup' prompt) the clock issue would occur.  When the LSI card was put into EFI option ROM mode OR the option ROM was disabled then the clock operated normally.  This is with Supermicro for investigation.

I guess the matter that is pertinent to this discussion is whether the boot loader should be re-written to not rely on the RTC to give systems the best chance of booting in all situations.


----------

