FreeBSD 13.0 crashes while trying to run 'startx'!

Help, my FreeBSD system was working fine.....until today 😭
Output of freebsd-version ; uname -a gives:
Code:
13.0-RELEASE
FreeBSD frisbie 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri April  9 04:24:09 UTC 2021         root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC/        amd64
I'm running FreeBSD on Oracle VM VirtualBox Manager Version 5.2.44 r139111(Qt 5.6.2). Host machine is Windows 10. My Desktop Environment is KDE5/Plasma.
The command cat /etc/rc.conf gives the following output:
Code:
hostname="frisbie"
ifconfig_em0="DHCP"
sshd_enable="YES"
moused_enable="YES"
dumpdev="AUTO"
allscreens_flags="-h 1000"
dbus_enable="YES"
hald_enable="YES"
kdm4_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
tor_enable="YES"
privoxy_enable="YES"
cat .xinitrc gives the following output:
Code:
exec /usr/local/bin/startplasma-x11
Now, I don't think the problem is in /etc/rc.conf or in .xinitrc as I ran FreeBSD several times with no problems but you guys know the best of course.
I did not install kernel debugging while installing my FreeBSD, and cat /var/crash/core.txt.0 said unable to find kernel debugger and to install it from devel/gdb or gdb package, so I installed it from port and while installing, it gave a warning to add the line DEFAULT_VERSION+=ssl=openssl-devel to some 'make.conf' but I don't know where to find that file. I think I installed openssl-devel earlier for some other thing while installing node.js and yarn but it shows it's own error but of course it deserves it's own thread.
Also while booting, there is a line which I think is relevant:
Code:
mountroot: waiting for device /dev/ada0a...
WARNING: / was not properly dismounted
Anyways, the output of cat /var/crash/core.txt.3 gives
Code:
'version' has unknown type; cast it to it's declared type
'version' has unknown type; cast it to it's declared type
Unable to find matching kernel for /var/crash/vmcore.3
Output of cat /var/log/Xorg.0.log contains the following lines:
Code:
[   148.047] (WW) Falling back to old probe method for mode setting
[   148.047] (EE) open /dev/dri/card0: No such file or directory
[   148.047] (WW) Falling back to old probe method for scfb
[   148.047] scfb trace: probe start
[   148.047] scfb trace: probe done
[   148.047] (WW) VGA arbitrer: cannot open kernel arbitrer, no multi-card support
cat /etc/fstab :
Code:
#Device          Mountpoint     FStype      Options     Dump     Pass#
/dev/ada0a       /              ufs         rw           1           1
/dev/ada0b       none           swap        sw           0          0
 
Last edited by a moderator:
…
… 13.0-RELEASE … 2021 …
…

Welcome to FreeBSD Forums.

13.0-RELEASE is outdated, please begin with an update to the operating system.

Also:

hald_enable="YES"

– HAL died more than a year ago; and

kdm4_enable="YES"

– that's even more outdated. <https://www.freshports.org/x11/kde4/#history>; <https://github.com/freebsd/freebsd-ports/commit/93d2c4e4f7c7f836b76f793c0f3871201feffe5c>.

Please, which instructions did you follow? (If you can't share the address of the page, as a new member, please state the exact title of the page.)

Thanks
 
Don't know the context of your statement concerning "outdated" but, 13.0-RELEASE is supported until the expected release announce date of 13.1-RELEASE + 3 months (=ca. 26 April 2022 + 3 months); then 13.0-RELEASE will have reached EoL. Still some 4.5 months away ...
What he's trying to say is that reason can be even more up to date by running freebsd-update. In other words, one can presently attain 13.0-RELEASE-p7 or higher, and eventually, 13.1-RELEASE, which is even better than just plain, old, out-of-the-box 13.0-RELEASE. The procedure to follow is given by the FreeBSD manual, as we all can see here: freebsd-update(8)

This might or might not solve his problem, but it's a good first step.

He is also recommending, in his roundabout way, that reason remove the lines hald_enable="YES" and kde4_enable="YES" from the /etc/rc.conf file. These lines are in fact also "outdated."
 
I suspect grahamperrin meant it's a "bare" 13.0-RELEASE and it's missing its security/errata patches.

Yep … in theory, a person might have a trouble-free desktop environment experience with real or virtual hardware with an outdated OS, but from what I've seen things are more likely to succeed where things are up-to-date.



That sparks another thought. reason, please, which one of these guest additions did you install?
 
Yep … in theory, a person might have a trouble-free desktop environment experience with real or virtual hardware with an outdated OS, but from what I've seen things are more likely to succeed where things are up-to-date.



That sparks another thought. reason, please, which one of these guest additions did you install?
the second one, i think i should have picked the first one since everything else is outdated
 
Welcome to FreeBSD Forums.

13.0-RELEASE is outdated, please begin with an update to the operating system.

Also:



– HAL died more than a year ago; and

kdm4_enable="YES"

– that's even more outdated. <https://www.freshports.org/x11/kde4/#history>; <https://github.com/freebsd/freebsd-ports/commit/93d2c4e4f7c7f836b76f793c0f3871201feffe5c>.

Please, which instructions did you follow? (If you can't share the address of the page, as a new member, please state the exact title of the page.)

Thanks
I think it was a video of this title in youtube FreeBSD 11.1 Installation + KDE Desktop + Guest Additions on Oracle VirtualBox [2017]. And yeah it is for FreeBSD version 11.1. I was following the handbook but once I was stuck with a lower screen resolution and it made me visit various sites. Anyways, I'll be updating everything first and see if the problem persists.
Isn't 13.0-RELEASE the latest version?
 
I've updated FreeBSD and VirtualBox but the problem persists.
Sorry guys, I think this thread is a mistake, It is probably because of the corrupt file system that startx crashes the system.
 
Could the problem's cause be that VboxSVGA currently is not/no longer supported for FreeBSD guests?

the second one, i think i should have picked the first one since everything else is outdated
...-ose-legacy is for i386 machines.
 
Today's fifth screenshot at <https://forums.freebsd.org/posts/559783> demonstrates VBoxSVGA used for seamless mode with a FreeBSD 13.1-BETA1 guest.
That screenshot shows FreeBSD 14 running a 13.1 guest...
... but how is it with the supported official releases?
I get yellow warning on Virtual box and the guest machine does not recognize the graphics card; this only works with VMSVGA, but with that seamless integration (e.g. resizable guest window) does not work.
 
… how is it with the supported official releases?

Fine, for me. I have a variety of guests:

1647097843929.png

I mean, I don't have any RELEASE host, but (for example) there's no problem resizing the window of a 13.0-RELEASE guest.

… VMSVGA, but with that seamless integration (e.g. resizable guest window) does not work.

Use VBoxSVGA.

If you have trouble with FreeBSD as a guest in, or host to, VirtualBox, aim for:


Thanks
 
It is a while ago I did a quick test with FreeBSD 13-RELEASE-p7 as host+guest, and when I did, there was a yellow warning for FreeBSD guests regarding usage of VboxSVGA. Then the guests' xorg failed to start using xf86-driver-vmware, which should be used with virtualbox also, if I read correctly.
Does your guest's xorg use another driver, say, xf86-video-vesa or -scfb? So, maybe it is just a driver mismatch?
Sadly I am busy these days with other things, so it will take some time until I can look into it again.
 
What does /var/crash/info.3 say?
It appears as if the kernel that crashed is not the same that is in the /boot/kernel/kernel ; did you do any update without reboot maybe? If that is a case it may be worth trying kgdb /boot/kernel.old/kernel /var/crash/vmcore.3 to see if that is the kernel that crashed.
If not you could try to find more info from the vmcore. Try strings /var/crash/vmcore.3 |grep panic, somewhere in the beggining you'll find message buffer, it will show you the panic string. That's the start.
 
Running kgbd /boot/kernel.old/kernel /var/crash/vmcore.3 gives
Code:
Reading symbols from /boot/kernel.old/kernel
(No debugging symbols found in /boot/kernel.old/kernel)
/usr/ports/devel/gdb/work-py38/gdb-11.2/gdb/thread.c:1345 internal-error: void switch_to_thread(thread_info *):(Assertion `thr!=NULL` failed.
A problem internal to GDB is detected, further debugging may be unreliable.
I don't think that is helpful at all.
As for the command strings /var/crash/vmcore.3| grep panic did not give any output.

Sorry for the late reply.
 
I don't think that is helpful at all.
It means that old kernel and dump don't match; rules out and answers my question above.

Can you attach few lines of strings on that vmcore.3 file ? strings /var/crash/vmcore.3|head -100.
Warning about FS not being properly dismounted after panic/sudden reboot is expected. Should there be deeper issue with the FS system would stop.
 
Code:
# tunefs -p /
tunefs: POSIX.1e ACLs: (-a)                                    disabled
tunefs: NFSv4 ACLs:  (-N)                                      disabled
tunefs: MAC multilabel:  (-l)                                  disabled
tunefs: soft updates: (-n)                                     enabled
tunefs: soft update journaling: (-j)                           enabled
tunefs: gjournal: (-J)                                         disabled
tunefs: trim: (-t)                                             disabled
tunefs: maximum blocks per file in a cylinder file group: (-e) 4096
tunefs: average file size: (-f)                                16384
tunefs: average number of files in a directory: (-s)           64
tunefs: minimum percentage of freespace:(-m)                   8%
tunefs: space to hold for metadata for blocks:(-k)             6400
tunefs: optimization preference: (-o)                          time
tunefs: volume label: (-L)
 
Back
Top