# FreeBSD 13.0 crashes while trying to run 'startx'!



## reason (Mar 9, 2022)

Help, my FreeBSD system was working fine.....until today 
Output of freebsd-version ; uname -a gives:

```
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:

```
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:

```
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:

```
mountroot: waiting for device /dev/ada0a...
WARNING: / was not properly dismounted
```
Anyways, the output of cat /var/crash/core.txt.3 gives

```
'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:

```
[   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 :

```
#Device          Mountpoint     FStype      Options     Dump     Pass#
/dev/ada0a       /              ufs         rw           1           1
/dev/ada0b       none           swap        sw           0          0
```


----------



## bsduck (Mar 10, 2022)

Hello,



reason said:


> `WARNING: / was not properly dismounted`


That's worth a fsck: `# fsck_ffs /dev/ada0a`

Did you forcefully close the running VM?


----------



## grahamperrin@ (Mar 11, 2022)

reason said:


> …
> `… 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


----------



## grahamperrin@ (Mar 11, 2022)

Side note: 



reason said:


> Oracle VM VirtualBox Manager Version 5.2.44 r139111(Qt 5.6.2). Host machine is Windows 10.



Support ended long ago – <https://www.virtualbox.org/wiki/Changelog-5.2>

Please, any reason for not running an Oracle-supported version?


----------



## Erichans (Mar 11, 2022)

grahamperrin said:


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


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


----------



## SirDice (Mar 11, 2022)

I suspect grahamperrin meant it's a "bare" 13.0-RELEASE and it's missing its security/errata patches.


----------



## Vull (Mar 11, 2022)

Erichans said:


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


----------



## grahamperrin@ (Mar 11, 2022)

SirDice said:


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

emulators/virtualbox-ose-additions-legacy
emulators/virtualbox-ose-additions


----------



## reason (Mar 12, 2022)

bsduck said:


> Hello,
> 
> 
> That's worth a fsck: `# fsck_ffs /dev/ada0a`
> ...


yeah,i guess i did do it once while it seemed unresponsive.


----------



## reason (Mar 12, 2022)

grahamperrin said:


> 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


----------



## reason (Mar 12, 2022)

grahamperrin said:


> Welcome to FreeBSD Forums.
> 
> `13.0-RELEASE` is outdated, please begin with an update to the operating system.
> 
> ...


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?


----------



## reason (Mar 12, 2022)

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.


----------



## grahamperrin@ (Mar 12, 2022)

reason said:


> … Isn't 13.0-RELEASE the latest version?



Not quite the latest RELEASE. Please see, for example <https://bokut.in/freebsd-patch-level-table/#releng/13.0>

After using the FreeBSD-provided installer, an update is required.



reason said:


> … probably because of the corrupt file system …



If you reinstall, choose ZFS.

Thanks for follow-up.


----------



## skunk (Mar 12, 2022)

Could the problem's cause be that VboxSVGA currently is not/no longer supported for FreeBSD guests?



reason said:


> the second one, i think i should have picked the first one since everything else is outdated


...-ose-legacy is for i386 machines.


----------



## grahamperrin@ (Mar 12, 2022)

skunk said:


> Could the problem's cause be that VboxSVGA currently is not/no longer supported for FreeBSD guests?



Doubtful. 

Today's fifth screenshot at <https://forums.freebsd.org/posts/559783> demonstrates VBoxSVGA used for seamless mode with a FreeBSD 13.1-BETA1 guest.



skunk said:


> ...-ose-legacy is for i386 machines.



Not solely. Please see, for example <https://github.com/freebsd/freebsd-ports/commit/42d8425b62bb66d04dd01c96d516c11451fd86dd>.


----------



## skunk (Mar 12, 2022)

grahamperrin said:


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


----------



## grahamperrin@ (Mar 12, 2022)

skunk said:


> … how is it with the supported official releases?



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




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.



skunk said:


> … 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:









						Emulation and virtualization
					

Section for questions regarding all sorts of emulation and virtualization, like bhyve, VirtualBox, qemu and jails. As guest and as host.




					forums.freebsd.org
				




Thanks


----------



## skunk (Mar 12, 2022)

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.


----------



## grahamperrin@ (Mar 12, 2022)

grahamperrin said:


> aim for:



Sorry, I meant, aim for a separate topic ;-) thanks


----------



## _martin (Mar 12, 2022)

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.


----------



## reason (Mar 14, 2022)

Running `kgbd /boot/kernel.old/kernel /var/crash/vmcore.3` gives 

```
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.


----------



## bsduck (Mar 14, 2022)

reason said:


> It is probably because of the corrupt file system that startx crashes the system.


Did you try a fsck? What was the result?


----------



## _martin (Mar 14, 2022)

reason said:


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


----------



## grahamperrin@ (Mar 15, 2022)

bsduck said:


> Did you try a fsck? What was the result?



Also (maybe _before_ attempting repair) boot the virtual machine in single user mode (option 2) then, at the command line:

`tunefs -p /`

What's reported?

tunefs(8)


----------



## reason (Mar 15, 2022)

```
# 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)
```


----------



## reason (Mar 15, 2022)

bsduck said:


> Did you try a fsck? What was the result?


Oh, I'm really sorry, I forgot to reply.
Anyways, I don't know how to use it . I typed that command in multi user mode and it showed several commands all of the as far as I can remember defaulted to  'no'. Since I am in single user mode now, I ran that command, and it takes me through but I don't know how to use it. The man page is not helpful.


----------



## reason (Mar 15, 2022)

So, running that command in multiuser mode with `sudo fsck_ffs /dev/ada0a:`

```
** /dev/ada0a (NO WRITE)
** SU+J Recovering /dev/ada0a

USE JOURNAL? no
** Skipping journal, falling through to full fsck

SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on   /
** Root file system 
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames

UNALLOCATED   I=6414210  OWNER=operator  MODE-100600
SIZE= 4096  MTIME=Mar  15 16:33  2022
FILE=/var/db/entropy/saved-entropy.1

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPER BLK
SALVAGE? no
SUMMARY INFORMATION BAD
SALVAGE? no
BLK(S) MISSING IN BIT MAPS
SALVAGE? no
594331 files, 6852664 used, 10157318 free, (20758 frags, 1267070 blocks, 0.1% fragmentation)
```


----------



## bsduck (Mar 15, 2022)

reason said:


> USE JOURNAL?


Answer yes.


----------



## reason (Mar 15, 2022)

_martin said:


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


Here you go.


----------



## _martin (Mar 15, 2022)

Thanks.
Can you reupload the same command but with `head -1000` ? 100 lines is not enough, 1000 should be enough (limiting output is needed, so it's a little bit of guessing game doing this remotely).

For clarification: are you able to boot this VM after crash/reboot or does it end up in single mode ? There's no need to do any fsck if after reboot machine boots up ok. You should not fsck live FS, especially /.

How much free space do you have in /var/crash (or on / as you have only one partition) ?


----------



## reason (Mar 15, 2022)

bsduck, you are right. The more I shutdown from the virtual machine instead through the FreeBSD OS, the more worse the problem gets. First I used to start kdeplasma5 by running`sudo startx`, after that, I installed sddm and by running `sudo sddm` as a workaround. Now, I shutdown the VM a couple of times through the Virtual Box instead from doing it inside the guest because FreeBSD was not responding(It happens when I try to run mpv or vlc media players). And now I can't open sddm too!
Now when I ran `sudo fsck` it seems to me that it has gotten much worse. This is the output:

```
** /dev/ada0a (NO WRITE)
** SU+J Recovering /dev/ada0a

USE JOURNAL? no
** Skipping journal, falling through to full fsck

SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=6410741 (432 should be 424)
CORRECT? no

INODE 6414181: FILE SIZE 156495872 BEYOND END OF ALLOCATED FILE, SIZE SHOULD BE 229736
ADJUST? no

** Phase 2 - Check Pathnames
DIRECTORY CORRUPTED I=5294874 OWNER=jack MODE=40755
SIZE=1024 MTIME=Mar 15 21:26 2022
DIR=/usr/home/jack/.config/session

UNEXPECTED SOFT UPDATE INCONSISTENCY
SALVAGE? no
UNALLOCATED   I=6414210  OWNER=operator  MODE-100600
SIZE= 4096  MTIME=Mar 15 22:00  2022
FILE=/var/db/entropy/saved-entropy.2

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED   I=6900994  OWNER=_tor  MODE-100600
SIZE=0 MTIME=Mar 15 22:04  2022
FILE=/var/db/tor/state

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT FILE I=6921337 OWNER=_tor MODE=0
SIZE=0 MTIME=Mar 15 22:04  2022 COUNT 0 SHOULD BE -1
ADJUST? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPER BLK
SALVAGE? no
SUMMARY INFORMATION BAD
SALVAGE? no
BLK(S) MISSING IN BIT MAPS
SALVAGE? no
594465 files, 6853308 used, 10126075 free, (19451 frags, 1263328 blocks, 0.1% fragmentation)
```


----------



## reason (Mar 15, 2022)

_martin said:


> Thanks.
> Can you reupload the same command but with `head -1000` ? 100 lines is not enough, 1000 should be enough (limiting output is needed, so it's a little bit of guessing game doing this remotely).
> 
> For clarification: are you able to boot this VM after crash/reboot or does it end up in single mode ? There's no need to do any fsck if after reboot machine boots up ok. You should not fsck live FS, especially /.
> ...


Um, well you see, writing 1000 lines is not exactly a trivial task, so I'm sorry, I won't be able to fulfill your wish. I pasted the 100 lines of output into a file and then copied that file to my host and the copied it again from host to another VM where I am running the FreeBSD forums. Now since I have lost sddm too (see my earlier post), how can I send it?


----------



## _martin (Mar 15, 2022)

Is your VM still bootable, meaning are you able to get shell ? Are you able to remotely ssh to that VM ? If yes you can just do `strings /var/crash/vmcore.3|head -1000 > vmoutput` and copy that file from the VM. 
If you can't properly boot the VM you could insert the bootable CD and retrieve it from there.


----------



## reason (Mar 15, 2022)

bsduck says to run fsck, while _martin says not to.


----------



## reason (Mar 15, 2022)

_martin said:


> Thanks.
> Can you reupload the same command but with `head -1000` ? 100 lines is not enough, 1000 should be enough (limiting output is needed, so it's a little bit of guessing game doing this remotely).
> 
> For clarification: are you able to boot this VM after crash/reboot or does it end up in single mode ? There's no need to do any fsck if after reboot machine boots up ok. You should not fsck live FS, especially /.
> ...


Once or twice, while rebooting, I ended up in single user mode. While booting FreeBSD sometimes it reboots again. It was too fast for me to read(next time, I'm gonna record it) but it probably dumps something and the reboots.


----------



## _martin (Mar 15, 2022)

reason said:


> bsduck says to run fsck, while _martin says not to.


We don't know what state is your VM in, it's hard to say what you should or should not do in your particular case. However, you should not run fsck on live system when / is mounted. Also FreeBSD will detect corrupted FS upon boot and will try to fix it automatically. If it fails to do so it drops the boot and lets you interact with it.
As I mentioned above it's normal for system to report dirty FS after sudden reboot/crash.

I'm heavy ZFS user and don't use UFS at all nowadays. grahamperrin traced and shows some bugs in 13 that were fixed. Some of it was expected behavior with certain settings (use updates or not,etc.), maybe he's able to shed some light on it (I didn't follow that topic deeply).

EDIT: btw how are you showing us the fsck output if you can't copy stuff ?


----------



## reason (Mar 15, 2022)

_martin said:


> Is your VM still bootable, meaning are you able to get shell ? Are you able to remotely ssh to that VM ? If yes you can just do `strings /var/crash/vmcore.3|head -1000 > vmoutput` and copy that file from the VM.
> If you can't properly boot the VM you could insert the bootable CD and retrieve it from there.


So I followed this thread 
	

	







						New FreeBSD User - VirtualBox Shared Folders
					

I just installed FreeBSD on a VirtualBox guest just a couple of days ago.  Are there any instructions out there for getting a shared folder that is on my Windows 10 host to work?  Please advise.  Thanks.




					forums.freebsd.org
				



 and now I have accidentaly overwritten my home directory . But anyways, here is the requested file.


_martin said:


> EDIT: btw how are you showing us the fsck output if you can't copy stuff ?


I painfully type them, word for word.


----------



## reason (Mar 15, 2022)

_martin said:


> I'm heavy ZFS user and don't use UFS at all nowadays.


How is ZFS better than UFS? I thought it took more space. Anyways, if it is better I might use it when I install FreeBSD as main OS(now, it is just a 'side OS').


----------



## _martin (Mar 15, 2022)

reason said:


> I painfully type them, word by word.


Sometimes you don't know if one is joking on internet or not. 


```
panic: ufs_dirbad: /: bad dir ino 400652 at offset 4608: mangled entry
cpuid = 0
time = 1647226871
KDB: stack backtrace:
#0 0xffffffff80c57525 at kdb_backtrace+0x65
#1 0xffffffff80c09f01 at vpanic+0x181
#2 0xffffffff80c09d73 at panic+0x43
#3 0xffffffff80f0c11f at ufs_lookup_ino+0xe7f
#4 0xffffffff80cc9f2d at vfs_cache_lookup+0xad
#5 0xffffffff80ccdeed at cache_fplookup_noentry+0x1ad
#6 0xffffffff80ccb5f2 at cache_fplookup+0x322
#7 0xffffffff80cd666f at namei+0x6f
#8 0xffffffff80cf40df at kern_statat+0xcf
#9 0xffffffff80cf47bf at sys_fstatat+0x2f
#10 0xffffffff8108baac at amd64_syscall+0x10c
#11 0xffffffff8106243e at fast_syscall_common+0xf8
Uptime: 1h5m48s
```
Here's your panic string and backtrace. It's related to corrupted FS.

Not sure how come you were not able to grep the panic string from my previous command I shared.

Now this could have been a result of bad shutdown previously done to this VM. Do you have other core files in /var/crash ? Can you check for the panic string there ?


----------



## _martin (Mar 16, 2022)

reason said:


> How is ZFS better than UFS?


By the features and options it provides. It's a bit heavier on resources but considering benefit/cost it's way more on benefit side. That's my personal opinion. 

I checked the bug tracker and it seems there are two PRs but one is linked to PR 244384 which is important (and has quite few dependents).


----------



## reason (Mar 16, 2022)

_martin said:


> Now this could have been a result of bad shutdown previously done to this VM


Is it possible to fix? Sometimes the VM is unresponsive, even after leaving it alone for couple of minutes. What do I do then?


----------



## _martin (Mar 16, 2022)

The only thing that comes to my mind is to boot it into single mode, do the fsck and hope for the best. I don't know if that would help though.
You can also try to find the dir inode with `find / -type d -inum 400652` as root. If anything you'd have an idea which directory is a problem.


----------



## reason (Mar 16, 2022)

_martin said:


> do the fsck and hope for the best.


fsck-ed it, now i can start sddm. but what about the problem / not being dismounted properly?also just immediately after fsck-ing it, it crashed once!
I think I should delete this thread. and probably find my answers somewhere else in the forum. like this thread for example 








						WARNING: / was not properly dismounted (12.2)
					

My system suddenly froze after initially  trying to reboot routinely & properly. I had just before corrected a spelling error in etc/rc.conf & saved the file. I Therefore had to close the system down improperly and  initially I was getting a seemingly continuous stream of what looked like a...




					forums.freebsd.org


----------



## _martin (Mar 16, 2022)

As mentioned above, please run the find command to see which directory has the problem. Do the strings on the new vmcore and verify what it crashed on (most likely it's a FS issue again). 
This is (most likely) a bug in UFS so it very well might not be fixable by fsck.


----------



## reason (Mar 16, 2022)

wait a min, actually when I rebooted the system(from the vm)because it got stuck again as always when i try to run vlc or mpv (i suspect it is the limitation of hardware resources), i fscked it the warning disappeared. also startx works(though it opens plasma as user root, but i can always log out and login as regular user) and so too sddm.
Erm, do you still want the strings?
If not, I think I should delete this thread.


----------



## grahamperrin@ (Mar 16, 2022)

UFS soft updates without soft update journaling can be problematic with `13.0-RELEASE-⋯`. <https://forums.freebsd.org/posts/523465>



reason said:


> `tunefs: soft updates: (-n)                                     enabled
> tunefs: soft update journaling: (-j)                           enabled`



this combination of preferences is OK.



reason said:


> … If not, I think I should delete this thread.



Please, do not remove. Leave these writings visible to the public, a _realistic_ record of things can be very useful.



_martin said:


> … You should not fsck live FS, especially / …





_martin said:


> … you should not run fsck on live system when / is mounted …



As far as I know – anyone, please correct me if I'm wrong:

although fsck_ffs(8) with option `-n` _can_ be used on a mounted file system, do so can be meaningless†
if a file system is mounted and if `-n` is omitted, the utility will not attempt any repair.



_martin said:


> … I'm heavy ZFS user and don't use UFS at all nowadays…




† Meaningless because _normal_ writes to a file system, during a check, will cause the utility to report _abnormalities_ that do *not* exist.


----------



## grahamperrin@ (Mar 16, 2022)

_martin said:


> PR 244384



_244384 – UFS fuzz metabug_

This meta bug was opened by Conrad Meyer following a series of methodical reports from Neeraj Pal (presumably bsdboy | <https://dev.to/bsdboy>, Senior Product Security Engineer at Qualcomm).

In the list of dependent bugs, I don't know why the first five of eight are (currently) GEOM-specific, they do involve UFS.

geom(8)



_martin said:


> … grahamperrin traced and shows some bugs in 13 that were fixed. …



I might describe my period of focused testing as thoughtful but *far* less methodical 

The fix for 256746 is not yet released.

Other FreeBSD bugs for UFS include:

256712 – UFS: kernel panic: ffs_blkfree_cg: freeing free frag – in response to pkg-delete(8) soon after login – _Closed_, _Unable to Reproduce_ ("… Thanks, and if you were awaiting information from me: sorry, I wasn't aware. …"); _Affects Some People_ – reminds me that one other person did produce the bug (I don't plan to trace the details)
259090 – UFS: bad file descriptor: soft update journaling can not be enabled on FreeBSD-provided disk images for 13.0-RELEASE and 13.0-STABLE – failed to write updated cg – *not* fixed.



grahamperrin said:


> Open bug reports for `13.1-RELEASE`:
> 
> <https://bugs.freebsd.org/bugzilla/b...04&query_format=advanced&version=13.1-RELEASE>



If 259090 is reproducible with `13.1-BETA⋯`, it should be reclassified to `13.1-RELEASE`.


----------



## _martin (Mar 17, 2022)

reason said:


> Erm, do you still want the strings?
> If not, I think I should delete this thread.


Don't delete the thread, it may help others googling around. No need to share more strings. I'd suggest to look into why you can't read the dump (insufficient space in /var maybe?) and check what directory is affected. 
X startup is related to the corrupted files, it is most likely what is triggering the bug during the access too.


----------



## _martin (Mar 17, 2022)

grahamperrin I'm not 100% sure with the UFS, it's a rule of thumb for many years on other systems. I don't know how force behaves on mounted FS either. 
When FS is in a state where you do need to run fsck it makes sense not to use it till the check is done and (possible) issue fixed though.


----------

