From owner-freebsd-stable@FreeBSD.ORG Fri Oct 1 15:10:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C5F31065670 for ; Fri, 1 Oct 2010 15:10:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B6CE28FC0C for ; Fri, 1 Oct 2010 15:10:52 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1P1hG7-000EG1-ET; Fri, 01 Oct 2010 17:10:51 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20101001113434.GA43360@icarus.home.lan> References: <20101001090143.GA40450@icarus.home.lan> <20101001113434.GA43360@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Fri, 01 Oct 2010 04:34:34 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 01 Oct 2010 17:10:51 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: boot0cfg problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 15:10:53 -0000 > On Fri, Oct 01, 2010 at 01:20:42PM +0200, Daniel Braniss wrote: > > > On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote: > > > > In a not so distant past, boot0cfg -sn ... used to work, then it = only > > > > partialy worked, it would modify the data in boot but not the mbr= , for > > > > which 'gpart -s set active -in ...' modified the mbr. Now > > > > =23 boot0cfg -s1 -v /dev/mfid0 > > > > boot0cfg: write_mbr: /dev/mfid0: Operation not permitted > > > > but: > > > > =23 boot0cfg -v /dev/mfid0 > > > > =23 flag start chs type end chs offset = size > > > > 1 0x80 0: 1: 1 0xa5 1023:212:63 63 4194= 3006 > > > > 2 0x00 1023:255:63 0xa5 1023:169:63 41943069 4194= 3006 > > > > 3 0x00 1023:255:63 0xa5 1023:126:63 83886075 4194= 3006 > > > > 4 0x00 1023:255:63 0xa5 1023:201:63 125829081 104647= 8825 > > > >=20 > > > > version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D=23 = (0x23) > > > > options=3Dpacket,update,nosetdrv > > > > volume serial ID 9090-9090 > > > > default_selection=3DF2 (Slice 2) > > >=20 > > > Can you try doing =22sysctl kern.geom.debugflags=3D16=22 first? > > > > > this is not realy foot-shooting :-), but > > - the error msg is gone, > > - the slice info is updated, > > - but the active bit in the mbr is not=21 - some bioses rely on it. > > looking at changes done to boot0cfg.c there is now an err(...) call w= hich > > does an exit, before the boot is updated. I changed it to a warn(...)= and the=20 > > old > > behaviour is back. > > BTW,=20 > > a- gpart command should have been: gpart set -a active -i n ... > > b- this works with kern.geom.debugflags=3D0. >=20 > Bit 4 (hence 0x10, or 16 decimal) in kern.geom.debugflags is described > as: >=20 > 0x10 (allow foot shooting) > Allow writing to Rank 1 providers. This would, for exampl= e, > allow the super-user to overwrite the MBR on the root disk= or > write random sectors elsewhere to a mounted disk. The imp= lica=E2=80=90 > tions are obvious. >=20 > I read this as: =22you can't modify the MBR of a root disk unless bit 4= of > this sysctl is set=22. Sector 0 holds the MBR, and boot0cfg modifies t= he > MBR. So can you explain what you mean by =22this really isn't > foot-shooting?=22 I mean, even the NOTE section of the boot0cfg(8) man= > page documents what I'm trying to say. >=20 > Anyway, if the MBR did get updated without kern.geom.debugflags having > bit 4 set, then wouldn't this indicate there's a bug in GEOM's =22secto= r > 0=22 protection? but mbr did NOT get updated by boot0cfg, gpart does however succeed, but = gpart=20 knows nothing about the other bits boot0cfg knows, like which slice to bo= ot=20 from (not to be confused with the current active slice), what bell to ring, et= c, these are (or used to be) updated before the last change. anyways, as you correctly pointed out, the problem is in GEOM, being some= what over protective :-)