fix corrupted system files, 13.5?

T

Todd M

So I had a crash after updating to the latest (-p6) yesterday, again related to drm_kmod, but I don't know why....

Anyway, I have things running again, but I've corrupted some system files from the crash.

`freebsd-update fetch` says I don't need any updates. I thought it might find problems.

So how should I determin/fix what is wrong in userland? I have programs like 'mail' acting funny.
 
So in terms of funny, I've noticed two problems: I read my system mail with 'mail' and now it loads the mailbox and displays the header screen, but it won't display a message (with 't' or 'T'). So that's some sort of significant issue.

And then previously, `screen` started giving me /bin/sh instead of my own shell (which I fixed by adding a 'shell' directive to .screenrc, but it was never needed to use the default...).

So those are the only issues I found -- after fixing pkgs (with `pkg upgrade -f`) -- but they are new. And it's also true that I never booted into -p5, because there wasn't a new kernel, so possibly these issues are old, but I am thinking they are actually recent file corruptions. I also have a 14.3 system, didn't have a crash, and don't have these issues with either program.
 
And to use IDS, I need to mount a system myself? There isn't an online comparison? And then there are the patch levels....
 
You can try simply untarring a release tarball over the running system. I forgot whether I ever did that.

Remember to exclude /etc when untarring.
 
  • Like
Reactions: cy@
Untarring a release tarball sounds rather "exciting" ....

I've discovered that this mail problem does generate errors in /var/log/messages:

kernel: pid 14496 (mail), jid 0, uid 1001: exited on signal 11

(The `mail` program doesn't crash. It simply returns to the '&' prompt after displaying nothing, instead of a message.)
 
yes, that sounds like file corruption in the code. freebsd-update IDS ought to tell you which files are at fault. with that information, we'd build a VM and do freebsd-update to the same release as yours, and then copy the corrupted files over manually. (but then, we wouldn't have found ourselves in your situation because we use zfs, and freebsd-update takes a snapshot)
 
Well, my basic procedural problem is rushing to do it, basically because updating stresses me, and then doing something foolish like trying to get into X again before the first fsck finished....

However, the update itself to -p6 should have completed correctly. I then rebooted and updated ports, and then tried to go into graphics mode and crashed. So e.g. the updated firefox was gone, but easily restored. So the corruption happened after a reboot after the system update....
 
Todd M said:
However, the update itself to -p6 should have completed correctly. [...] So the corruption happened after a reboot after the system update....
Click to expand...
right, and with ZFS one could use zfs diff to discover the corrupted files, or zfs rollback to undo the upgrade and try again — we've done that one before.
 
easy-mode would be to build a VM on another machine and bring it to the right patch level.

also we just remembered about freebsd-update rollback, so, assuming those files aren't also corrupted, you could freebsd-update rollback and try the update again. that's a slightly more risky option.

the release-tarball thing, i'm pretty sure, will make you out-of-sync with freebsd-update and cause future problems, and if we were in your shoes we'd rather backup and reinstall instead of trying to pick specific files out of the distribution sets.
 
From post #1 , system was rebooted after the crash is good indication for the base system. The drm-kmod may be the cause for the crash. In that case you need to fix that and have done with -f. You did not mention which file/files are corrupted and related effect on your daily use. In extreme case it will be easy to reinstall the base after having the necessary backups.
 
I don't know which files are corrupted, but the only problems I have found so far are with `mail` & `screen` (the latter having been reinstalled from pkgs already). So some library somewhere, probably.

It's also possible that this is a problem with the update itself, and no corruption on my end. I don't know.
 
No, I haven't tried doing that yet. Any reboot of the main home/office system is a major disruption for me, and I have a lot to do. I am collecting suggestions. So far, the system still seems to work other than issues noted, so I'm hopeful I can be more patient in developing a resolution.

I am really hoping that someone has a simpler idea, frankly. (Or maybe that this is not even a problem I created.)
 
the reason you should not be using freebsd-update IDS on a potentially corrupted system is, to us, obvious — you cannot trust a corrupted system to evaluate itself. properly identifying the corruption requires that the system be quiesced. you can try the command from a running system but we would expect false-positive results. there is not a simple solution to this problem.
 
My educated guess: The problem isn't in "software" (meaning an executable or runtime library), but in a config file. It could be as simple as a config file that has become unreadable. I would start an exhaustive search in /etc and /usr/local/etc. Also run the offending programs with a system call trace on, and see what config files they (try to ...) open and read.
 
You must log in or register to reply here.
Back
Top