Date: Fri, 01 Oct 2010 17:10:51 +0200 From: Daniel Braniss <danny@cs.huji.ac.il> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org Subject: Re: boot0cfg problems Message-ID: <E1P1hG7-000EG1-ET@kabab.cs.huji.ac.il> In-Reply-To: <20101001113434.GA43360@icarus.home.lan> References: <E1P1a0v-0009QQ-Rt@kabab.cs.huji.ac.il> <20101001090143.GA40450@icarus.home.lan> <E1P1dfO-000BRI-MZ@kabab.cs.huji.ac.il> <20101001113434.GA43360@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1P1hG7-000EG1-ET>