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:
#
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
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 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
On Fri, 1 Oct 2010 04:34:34 -0700
Jeremy Chadwick free...@jdc.parodius.com 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
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
