Date: Fri, 19 May 2006 12:54:08 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Thomas-Martin Seck <tmseck-lists@netcologne.de> Cc: freebsd-current@freebsd.org Subject: Re: Root FS corruption Message-ID: <20060519085408.GB51604@comp.chem.msu.su> In-Reply-To: <200605181819.k4IIJHL7001150@hardy.tmseck.homedns.org> References: <20060518151232.GA37743@comp.chem.msu.su> <200605181819.k4IIJHL7001150@hardy.tmseck.homedns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 18, 2006 at 08:19:17PM +0200, Thomas-Martin Seck wrote: > * Yar Tikhiy <yar@comp.chem.msu.su>: > > > I saw the following / corruption in a fresh CURRENT when using > > nextboot. Of course, it wasn't the fault of nextboot itself, > > nextboot simply was the only utility to modify / in my case. > > > > I found the contents of nextboot.conf once in my custom /root/supfile, > > the other time in the stock /etc/protocols. /etc/protocols was > > large enough to see how the corruption had happened: the first > > fragment, 2048 bytes, of the file was replaced by the contents of > > nextboot.conf, zero padded. > > > > The / was a usual 2048/16384 UFS2 without soft-updates. The kernel > > was GENERIC. Forced fsck reported no problems at all. The / had > > never been dirty because I used nextboot to boot single-user with > > all FSen read-only and investigate a panic unrelated to FS. > > > > Did any one see a similar problem of fragment mis-allocation? > > I experienced the exact same corruption some months ago with a RELENG_6 > test system I update regularly. Unfortunately, this corruption happened > only once, I was never able to reproduce it since. > > The kernel is a stripped down GENERIC, /root is a 2048/16384 UFS2 fs. Thank you for your reply! Apropos, today /boot/kernel/ng_fec.ko fell a victim to the corruption in exactly the same way: its first fragment was replaced by the nextboot.conf contents. The system was updated last time on the day before yesterday. Of course, more / corruption is likely. The case of nextboot.conf is just detectable easily. Thank Daemon, it's a test machine and not a production server. I'm still trying to find a pattern in the corruption. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060519085408.GB51604>