Re: boot0cfg and kern.geom.debugflags (was: problem with boot0cfg on a twe?)

> Date: Thu, 09 Jun 2005 13:06:27 -0500
> From: Jonathan Noack <noackjr_at_alumni.rice.edu>
> Sender: owner-freebsd-current_at_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_at_es.net			Phone: +1 510 486-8634