Reboots or Boots stops at AUTOBOOT in 10 seconds

Snurg

Daemon

Reaction score: 577
Messages: 1,349

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
 
OP
nero

nero

Member

Reaction score: 6
Messages: 22

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

Cheers,
 

_martin

Aspiring Daemon

Reaction score: 226
Messages: 984

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

nero

Member

Reaction score: 6
Messages: 22

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 ...
 
OP
nero

nero

Member

Reaction score: 6
Messages: 22

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

Aspiring Daemon

Reaction score: 226
Messages: 984

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).
 
OP
nero

nero

Member

Reaction score: 6
Messages: 22

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
 

Snurg

Daemon

Reaction score: 577
Messages: 1,349

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

Daemon

Reaction score: 1,155
Messages: 2,083

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.
 

Snurg

Daemon

Reaction score: 577
Messages: 1,349

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

Daemon

Reaction score: 1,155
Messages: 2,083

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.
 
OP
nero

nero

Member

Reaction score: 6
Messages: 22

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
 
Top