From owner-freebsd-current@FreeBSD.ORG Thu Jun 9 18:51:14 2005 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 C839216A41C for ; Thu, 9 Jun 2005 18:51:14 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3F0B43D1D for ; Thu, 9 Jun 2005 18:51:14 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Thu, 09 Jun 2005 11:51:12 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2BB295D07; Thu, 9 Jun 2005 11:51:13 -0700 (PDT) To: noackjr@alumni.rice.edu In-reply-to: Your message of "Thu, 09 Jun 2005 13:06:27 CDT." <42A88523.1050707@alumni.rice.edu> Date: Thu, 09 Jun 2005 11:51:13 -0700 From: "Kevin Oberman" Message-Id: <20050609185113.2BB295D07@ptavv.es.net> Cc: Randy Bush , FreeBSD Current , Rainer Duffner Subject: Re: boot0cfg and kern.geom.debugflags (was: problem with boot0cfg on a twe?) 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, 09 Jun 2005 18:51:15 -0000 > Date: Thu, 09 Jun 2005 13:06:27 -0500 > From: Jonathan Noack > Sender: owner-freebsd-current@freebsd.org > > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enigAB786D0A662873CF03C9D567 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 06/09/05 09:02, Randy Bush wrote: > >>I looked in my archives (well, it's actually at gmane): > >> > >>I got this from Doug White: > >> > >>>This is a erroneous message. The actual problem is: > >>> > >>>> 484 boot0cfg NAMI "/dev/twed0" > >>>> 484 boot0cfg RET open -1 errno 1 Operation not permitted > >>>> > >>>>This is a known problem with certain MBR layouts. To work around this > >>>>problem, set: > >>>> > >>>>sysctl kern.geom.debugflags=16 > >>>>then try your boot0cfg. There's a protection mechanism that sometimes gets > >>>>confused by certain partition table layouts. Flag 16 disables that > >>>>protection. I don't recommend running this unless you are explicitly > >>>>trying to updating something in a partition table-like area; its very easy > >>>>to destroy your system with the flag set! > >> > >>Can you try this? > > > > bingo!!! > > > > # sysctl kern.geom.debugflags=16 > > kern.geom.debugflags: 0 -> 16 > > # boot0cfg -B -d 1 -s 1 -v twed0 > > # flag start chs type end chs offset size > > 1 0x80 0: 1: 1 0xa5 1023:254:63 63 72292437 > > > > version=1.0 drive=0x1 mask=0xf ticks=182 > > options=packet,update,nosetdrv > > default_selection=F1 (Slice 1) > > From what I gather from Poul-Henning Kamp's posts on the matter, this > is a design feature and not a bug. If a disk is mounted in any way > (including read-only), you may not update the MBR to prevent foot > shooting. The real problem is that the error that is returned gives > little information. There has not been a consensus on how to make > things easier for the user. Various ways to print friendly error > messages have been proposed and shot down. > > This issue is documented in boot0cfg(8) as the first entry in the BUGS > section: > "Protection mechanisms in the geom(4) subsystem might prevent boot0cfg > from being able to update the MBR on a mounted disk. Instructions for > temporarily disabling these protection mechanisms can be found in the > geom(4) manpage." > > Under the DIAGNOSTICS section of geom(4) describing the use of the > kern.geom.debugflags sysctl: > "0x10 (allow foot shooting) > Allow writing to Rank 1 providers. This would, for example, allow the > super-user to overwrite the MBR on the root disk or write random sectors > elsewhere to a mounted disk. The implications are obvious." > > I'm not sure what "tracing" is so I don't understand why 0x02 and 0x04 > are necessary (to give us 0x16). I think you forgot which bases the numbers are in. 16base10 is the same thing as 0x10. No other flags are involved. Or 16(10) = 10(16). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634