It does not allow to analyze in detail, because the system is rebooted immediately.No.
What do you mean by "prompt"? What else does the console say?
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.
acheron said:Yup, do you load any kernel module installed from the ports tree? vbox maybe?
I'm very sorry, but I have a real hard time even parsing what you are writing here.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.
You say "the system detected a vulnerability". How did it do that? How did it tell you about the vulnerability?
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?
FreeBSD I usually use for graphical desktop environment, and I said the last thing I did days before the kernel bug.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?
The FreeBSD system is mounted on a virtualized machine of virtualbox.You write "eliminated completely". How is your system being eliminated?
With boot loaderYou say "prompt at boot time". Which prompt. The boot loader one? Or the first login prompt? Or the first shell prompt after login?
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.About the "continuous restarts": Have you tried booting in single-user mode, to get around the automatic loading of kernel modules?
I mentioned the last thing I did.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 have no idea how that works with virtualization of display drivers.The FreeBSD system is mounted on a virtualized machine of virtualbox.
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.
vi /boot/loader.conf# security.bsd.allow_destructive_dtrace=0
# siba_bwn_load="YES"
# if_bwn_load="YES
# bwn_v4_ucode_load="YES"
vi /etc/rc.conf# kld_list="amdgpu /boot/modules/i915kms.ko coretemp cpuctl"
# microcode_update_enable="YES"
vi /etc/sysctl.conf# kern.randompid=1
This line looks odd. You are loading both Intel DRM driver and amdgpu. Are you using both video devices?# kld_list="amdgpu /boot/modules/i915kms.ko coretemp cpuctl"
The Virtualbox machine only uses the video of "vboxvideo" driver.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.
Yes, the FreeBSD system this in Virtualbox.SirDice said:This is a virtual machine isn't it?
It said this upstairs:Then why are you loading i915kms and amdgpu?
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.
security.bsd.allow_destructive_dtrace=0
kern.randompid=1
microcode_update_enable="YES"
So which of those files in those directories was the failure of kernel bug? Was it one of these?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.
#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?