Reboots or Boots stops at AUTOBOOT in 10 seconds

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?
Code:
kern.eventtimer.periodic = 1
 
I will try this when back near the device as I am remote right now. WIll do and report back.

Cheers,
 
What is the contents of your /boot/loader.conf ? Any chance you have some sort of serial device connected to this book?
 
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.
I have checked for stuck keys and fairly sure none are stuck. I get no such errors or post errors. It would be great if I could just disable to keyboard as I don't use it or the screen - lol. Laptop manufacturers should make those BIOS options


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 ...
 
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"
 
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).
 
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
 
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.
 
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.

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.
 
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!
 
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.
 
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
 
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?
 
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?
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 

Attachments

  • Screenshot 2022-04-08 102512.jpg
    Screenshot 2022-04-08 102512.jpg
    746.5 KB · Views: 43
Back
Top