At boot time the system is automatically rebooted!

Hello!

When booting the system restarts automatically from the prompt, the system is 12.0 RELEASE for 64 bits. Any idea?
 
No.

What do you mean by "prompt"? What else does the console say?
It does not allow to analyze in detail, because the system is rebooted immediately.

screenbug.png


screenbug1.png
 
OK, that's some information. Unfortunately, not much. The bottom picture tells me that the hardware devices (disk etc.) seem healthy. Then it says that the system had crashed previous, and is doing a log or journal recovery, which is exactly expected. End of bottom picture.

The top pictures tells me that something has triggered a kernel bug, in this case a page fault. Unfortunately, the stack trace at the bottom is cut off, so we don't know what the kernel was really doing. We know a little bit: the process was running kldload, so it was loading modules into the kernel. This gives me a slight suspicion: Your install might be screwed up, with a mix of incompatible kernel modules. Think about how this install was created, maybe there were some updates that didn't work right, or something failed and was manually repaired? But this is just a guess, not necessarily correct.
 
Yup, do you load any kernel module installed from the ports tree? vbox maybe?
 
The top pictures tells me that something has triggered a kernel bug, in this case a page fault. Unfortunately, the stack trace at the bottom is cut off, so we don't know what the kernel was really doing. We know a little bit: the process was running kldload, so it was loading modules into the kernel. This gives me a slight suspicion: Your install might be screwed up, with a mix of incompatible kernel modules. Think about how this install was created, maybe there were some updates that didn't work right, or something failed and was manually repaired? But this is just a guess, not necessarily correct.

I remember that the system detected a vulnerability in webkit2-gtk3 and wanted to update with the updated ports and gave error. It makes me very sad that the system also built is going to be eliminated completely by that kernel failure and its continuous restarts from the prompt at boot time.

I remember the last thing I did was to give permission to the user folder on the wheel to transfer the files from the devices to the user folder.

acheron said:
Yup, do you load any kernel module installed from the ports tree? vbox maybe?

vbox was built from the ports for 3D acceleration.
 
I remember that the system detected a vulnerability in webkit2-gtk3 and wanted to update with the updated ports and gave error. It makes me very sad that the system also built is going to be eliminated completely by that kernel failure and its continuous restarts from the prompt at boot time.

I remember the last thing I did was to give permission to the user folder on the wheel to transfer the files from the devices to the user folder.
I'm very sorry, but I have a real hard time even parsing what you are writing here.

You say "the system detected a vulnerability". How did it do that? How did it tell you about the vulnerability?

You say "webkit2-gtk3". I don't know what that is (I don't run a GUI on FreeBSD), but it seems to be related to GUI, X-windows, web browsers, and rendering. What does it have to do with kernel modules?

Then you say that it "gave error". You need to be way more specific that that. I can't debug "gave error".

You write "eliminated completely". How is your system being eliminated?

About the "continuous restarts": Have you tried booting in single-user mode, to get around the automatic loading of kernel modules?

You say "prompt at boot time". Which prompt. The boot loader one? Or the first login prompt? Or the first shell prompt after login?

And then you say "give permission to the user folder on the wheel...". Sorry, but that sentence makes very little sense. What is a user folder? Which user? Do you mean directory (folders exists on Windows, this is a Unix system)? What do you mean by wheel? There is a group of users called wheel, is that what you mean? What devices did you want to transfer the files from? Which files?
 
You say "the system detected a vulnerability". How did it do that? How did it tell you about the vulnerability?

teo has a whole series of shitposts (shitthreads?) based on a fundamental misunderstanding of the pkg audit feature. I wouldn't read too much into it.
 
I'm very sorry, but I have a real hard time even parsing what you are writing here.

You say "the system detected a vulnerability". How did it do that? How did it tell you about the vulnerability?

You say "webkit2-gtk3". I don't know what that is (I don't run a GUI on FreeBSD), but it seems to be related to GUI, X-windows, web browsers, and rendering. What does it have to do with kernel modules?

Then you say that it "gave error". You need to be way more specific that that. I can't debug "gave error".

You write "eliminated completely". How is your system being eliminated?

About the "continuous restarts": Have you tried booting in single-user mode, to get around the automatic loading of kernel modules?

You say "prompt at boot time". Which prompt. The boot loader one? Or the first login prompt? Or the first shell prompt after login?

And then you say "give permission to the user folder on the wheel...". Sorry, but that sentence makes very little sense. What is a user folder? Which user? Do you mean directory (folders exists on Windows, this is a Unix system)? What do you mean by wheel? There is a group of users called wheel, is that what you mean? What devices did you want to transfer the files from? Which files?


You say "webkit2-gtk3". I don't know what that is (I don't run a GUI on FreeBSD), but it seems to be related to GUI, X-windows, web browsers, and rendering. What does it have to do with kernel modules?
FreeBSD I usually use for graphical desktop environment, and I said the last thing I did days before the kernel bug.

You write "eliminated completely". How is your system being eliminated?
The FreeBSD system is mounted on a virtualized machine of virtualbox.

You say "prompt at boot time". Which prompt. The boot loader one? Or the first login prompt? Or the first shell prompt after login?
With boot loader

About the "continuous restarts": Have you tried booting in single-user mode, to get around the automatic loading of kernel modules?
Entering through Boot Single user, this is what allows to see the virtualbox screen, I don't know what command is used to to see everything in the modules directory.

screenf.png



shkhln said:
teo has a whole series of shitposts (shitthreads?) based on a fundamental misunderstanding of the pkg audit feature. I wouldn't read too much into it.
I mentioned the last thing I did.
 
The FreeBSD system is mounted on a virtualized machine of virtualbox.
I have no idea how that works with virtualization of display drivers.

[quoteEntering through Boot Single user, this is what allows to see the virtualbox screen, I don't know what command is used to to see everything in the modules directory.[/quote]
The command to see all modules is just "ls /boot/kernel/*.ko". I presume the screen shot you posted above is the output of that command, although on my system (which does not use a GUI) most of the files shown in your screen shot don't exist.

I have no idea which one is causing problems, nor do I know where your kernel modules have come from, lacking knowledge of the install history of the system.

Here would the my suggestion: First make sure that these display drivers are actually going to work when virtualized, with a web search. Then back up everything in /boot/kernel, and replace it with the files from a clean install. Update boot loader config accordingly, and make sure the system is basically working. Once you get there, start adding specialized modules slowly, until you find what breaks it.
 
Here would the my suggestion: First make sure that these display drivers are actually going to work when virtualized, with a web search. Then back up everything in /boot/kernel, and replace it with the files from a clean install. Update boot loader config accordingly, and make sure the system is basically working. Once you get there, start adding specialized modules slowly, until you find what breaks it.

Thank you very much for trying to solve the problem of the kernel bug, I already solved it. Would it be these files that were causing the problem at different directories ? Sometimes one makes a mistake by following the guide of others who publish on the internet.

Entering through Boot Single user, I made them deactivate files from directories that have been present and the system at its boot started started running normally.

# vi /boot/loader.conf
Code:
# security.bsd.allow_destructive_dtrace=0
# siba_bwn_load="YES"
# if_bwn_load="YES
# bwn_v4_ucode_load="YES"

# vi /etc/rc.conf
Code:
# kld_list="amdgpu /boot/modules/i915kms.ko coretemp cpuctl"
# microcode_update_enable="YES"

# vi /etc/sysctl.conf
Code:
# kern.randompid=1
 
# kld_list="amdgpu /boot/modules/i915kms.ko coretemp cpuctl"
This line looks odd. You are loading both Intel DRM driver and amdgpu. Are you using both video devices?
I bet one of these is the culprit.
Probably /boot/modules/i915kms.ko is the problem.
 
This line looks odd. You are loading both Intel DRM driver and amdgpu. Are you using both video devices?
I bet one of these is the culprit.
Probably /boot/modules/i915kms.ko is the problem.
The Virtualbox machine only uses the video of "vboxvideo" driver.

SirDice said:
This is a virtual machine isn't it?
Yes, the FreeBSD system this in Virtualbox.
 
Then why are you loading i915kms and amdgpu?
It said this upstairs:

Sometimes one makes a mistake by following the guide of others who publish on the internet.

Entering through Boot Single user, I made them deactivate files from directories that have been present and the system at its boot started started running normally.
 
Entering through Boot Single user, I made them deactivate files from directories that have been present and the system at its boot started started running normally.

Of the variables you list, these two are System Hardening Options available during the build process of the FreeBSD base system that I use on all my machines:

/boot/loader.conf
Code:
security.bsd.allow_destructive_dtrace=0

/etc/sysctl.conf
Code:
kern.randompid=1


This works with sysutils/devcpu-data to download the latest firmware patches for your CPU, which is the second thing I install and run on a new build:

/etc/rc.conf
Code:
microcode_update_enable="YES"

None of them have an adverse effect on any of my machines.
 
Of the variables you list, these two are System Hardening Options available during the build process of the FreeBSD base system that I use on all my machines:

/boot/loader.conf
Code:
security.bsd.allow_destructive_dtrace=0

/etc/sysctl.conf
Code:
kern.randompid=1


This works with sysutils/devcpu-data to download the latest firmware patches for your CPU, which is the second thing I install and run on a new build:

/etc/rc.conf
Code:
microcode_update_enable="YES"

None of them have an adverse effect on any of my machines.
So which of those files in those directories was the failure of kernel bug? Was it one of these?
# vi /boot/loader.conf

Code:
# siba_bwn_load="YES"
# if_bwn_load="YES
# bwn_v4_ucode_load="YES"

# vi /etc/rc.conf
Code:
# kld_list="amdgpu /boot/modules/i915kms.ko coretemp cpuctl"



 
So which of those files in those directories was the failure of kernel bug? Was it one of these?

You might want to ask the author of the online tutorial you followed to get those other settings. I've never used a VM so can't say.
 
Back
Top