Date: Tue, 13 Nov 2018 22:49:15 +0100 From: Polytropon <freebsd@edvax.de> To: B J <va6bmj@gmail.com> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Kernel Panics With Firefox 63.x Message-ID: <20181113224915.9429e289.freebsd@edvax.de> In-Reply-To: <CAP7QzkOXYUZfaNxzUvH_XOmn7eE4ueT6E83H3TX%2BER9ETKy_fw@mail.gmail.com> References: <CAP7QzkN_6sGAh66Am2oTfDmazWUD6Gxq2d5ss-kNewjcRoc5RA@mail.gmail.com> <20181113182954.1d7060bd.freebsd@edvax.de> <CAP7QzkN66pSTOmw0HAPsDAzRgxRtLXRgoqFZnAvNoXW1eLq5uQ@mail.gmail.com> <20181113201830.f0eec001.freebsd@edvax.de> <CAP7QzkO8=A-DVa7GxEXv0gpJL4MnDirz6DVfzF%2B6GdAF9h7aag@mail.gmail.com> <20181113205020.afc446d9.freebsd@edvax.de> <CAP7QzkOXYUZfaNxzUvH_XOmn7eE4ueT6E83H3TX%2BER9ETKy_fw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Nov 2018 21:04:43 +0000, B J wrote: > <snip> > > >> Thanks for the info. It looks like I've got some work ahead of me. > >> I'll look into that once I finish building FF from ports which, as I'm > >> writing this, is still in progress after about 2 hours. > > > > I'd suggest you interrupt the build right now. It _could_ > > happen that a file system inconsistency causes a defective > > binary to be generated without you noticing. Perform the > > forced fsck in SUM first, then "make clean", and finally > > restart the build - just to be sure... > > <snip> > > I halted the building process and did as you suggested earlier. There > were indeed a number of inconsistencies and corrupted files when I ran > fsck in single-user mode. Excellent! Always make sure the file system consistency is present _before_ the system boots; relying on background fsck just asks trouble. ;-) Technical sidenote: The background fsck can only handle a subset of errors. Common errors, sure, but sometimes there is something it cannot correct or repair, and you boot into an inconsistent system state, but without any warning. A foreground fsck makes sure that _if_ such a problem is recognized, you will be interactively prompted, so you can decide what to do. In very few cases you do _not_ want fsck to do anything, as it might make data recovery more problematic; for example, you first decide to "mount -o ro /something", retrieve data, then run fsck and maybe end up with zero length files (whose content you have already recovered), and then you "re-fill" those files; or you need to use fsdb to help fsck with a problem it cannot work around. However, for typical use, a foreground fsck will be the right thing to do. You gain safety by paying with downtime. You usually don't pay with data loss. :-) > One thing I didn't mention earlier was that, before I had the kernel > panics earlier today, each time I tried starting FF, I had to reset > everything. Evidently, some of the preference files had been > corrupted but either couldn't be restored or would be damaged each > time I ran it. Firefox today uses a quite complex structure of files to store settings. Combine this with a file system inconsistency, and you can easily end up with files that get rewritten or reset, but are still damaged at the next program start. In case the same inodes were used, the file would always be somehow damaged, and even if a process of unlink() and open() / fopen() to create it would allocate a different inode, it's still possible that the problem was within the parent inode - and only a proper fsck would have been able to fix this problem. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181113224915.9429e289.freebsd>