> 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?
but mbr did NOT get updated by boot0cfg, gpart does however succeed, but gpart knows nothing about the other bits boot0cfg knows, like which slice to boot from (not to be confused with the current active slice), what bell to ring, etc, these are (or used to be) updated before the last change. anyways, as you correctly pointed out, the problem is in GEOM, being somewhat over protective :-) _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
