boot0cfg problems

[Jeremy Chadwick]

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
> > > # boot0cfg -s1 -v /dev/mfid0
> > > boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
> > > but:
> > > # boot0cfg -v /dev/mfid0
> > > #   flag     start chs   type       end chs       offset         size
> > > 1   0x80      0:  1: 1   0xa5   1023:212:63           63     41943006
> > > 2   0x00   1023:255:63   0xa5   1023:169:63     41943069     41943006
> > > 3   0x00   1023:255:63   0xa5   1023:126:63     83886075     41943006
> > > 4   0x00   1023:255:63   0xa5   1023:201:63    125829081   1046478825
> > > 
> > > version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
> > > options=packet,update,nosetdrv
> > > volume serial ID 9090-9090
> > > default_selection=F2 (Slice 2)
> > 
> > Can you try doing "sysctl kern.geom.debugflags=16" 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! - some bioses rely on it.
> looking at changes done to boot0cfg.c there is now an err(...) call which
> does an exit, before the boot is updated. I changed it to a warn(...) and the 
> old
> behaviour is back.
> BTW, 
> a- gpart command should have been: gpart set -a active -i n ...
> b- this works with kern.geom.debugflags=0.

Bit 4 (hence 0x10, or 16 decimal) in kern.geom.debugflags is described
as:

     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 implica‐
             tions are obvious.

I read this as: "you can't modify the MBR of a root disk unless bit 4 of
this sysctl is set".  Sector 0 holds the MBR, and boot0cfg modifies the
MBR.  So can you explain what you mean by "this really isn't
foot-shooting?"  I mean, even the NOTE section of the boot0cfg(8) man
page documents what I'm trying to say.

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 "sector
0" protection?

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |