> 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
> > >
On Fri, 1 Oct 2010 04:34:34 -0700
Jeremy Chadwick wrote:
> 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?
Or that it knows that updating the active byte is harmless.
--
Bruce Cran
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 'g
> 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
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
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:
# boot0cf
