From owner-freebsd-current@FreeBSD.ORG Thu May 18 15:12:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B765716A47E for ; Thu, 18 May 2006 15:12:40 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D88B43D66 for ; Thu, 18 May 2006 15:12:36 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k4IFCXYO044123 for ; Thu, 18 May 2006 19:12:33 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k4IFCXb0044122 for freebsd-current@freebsd.org; Thu, 18 May 2006 19:12:33 +0400 (MSD) (envelope-from yar) Date: Thu, 18 May 2006 19:12:32 +0400 From: Yar Tikhiy To: freebsd-current@freebsd.org Message-ID: <20060518151232.GA37743@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: Root FS corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 15:12:47 -0000 Hi all, 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? -- Yar