From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 7 Jan 2012 21:13:44 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120107201344.GA5210@polynum.com> References: <20120107182908.GA3674@polynum.com> <1c3ba45416e47236eedd6ca05863d751@chula.quanstro.net> <20120107192213.GA4971@polynum.com> <00ef086e68547f47c3dce5d366aa94bb@chula.quanstro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ef086e68547f47c3dce5d366aa94bb@chula.quanstro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] BUG: disk/fdisk.c: corrupts MBR Topicbox-Message-UUID: 56514de4-ead7-11e9-9d60-3106f5b1d025 On Sat, Jan 07, 2012 at 02:30:52PM -0500, erik quanstrom wrote: > > the code assumes c/h/s. and if it (libdisk) can't find the geometry, it makes stuff > up. that seems like a dubious assumption. not very clean at all. > > i was thinking that setting cyc2cyl=1 should cleanly remove this feature. > it could then be reenabled with a command-line flag if necessary for > some really ancient h/w. We should be careful, because bootloaders whether take the c/h/s, or the as is lba values (and the incorrect assumption is that c/h/s == lba since this will defeat the purpose of lba). But in the code, there are p->ctlstart and p->ctlend, that have the correct values... and are not used. Perhaps simply using these values when writing will suffice. But whether I or another have/has to look carefully: doing blunders in Plan9 zone is unfortunate but... Messing others' areas must be forbidden. disk/fdisk(8) is the program that impacts others. The MBR is the BIOS entry point so it shall not be botched. Furthermore, with a booloader that has not the capability to select the primary to boot, if the MBR is partially wrong, and the active partition not the correct one, you have to have... a plan B (but perhaps not the well known one ;). -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C