boot0cfg and kern.geom.debugflags
Jonathan Noack
noackjr at alumni.rice.edu
Thu Jun 9 19:06:06 GMT 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20050609/e58147bf/signature.bin
More information about the freebsd-current
mailing list