> 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 :-)
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"