Re: boot0cfg and kern.geom.debugflags

On 06/09/05 13:51, Kevin Oberman wrote:
>>Date: Thu, 09 Jun 2005 13:06:27 -0500
>>From: Jonathan Noack <noackjr_at_alumni.rice.edu>
>>Sender: owner-freebsd-current_at_freebsd.org
>>
>>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).

*blush*  I never considered they would be listed with different bases, 
although that makes perfect sense.  Thanks!

-- 
Jonathan Noack | noackjr_at_alumni.rice.edu | OpenPGP: 0x991D8195