Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!kralizec.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.bugs Subject: Re: bad144 problem? Date: 24 Aug 1993 11:26:28 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 61 Message-ID: <25bqo4INNg1m@kralizec.zeta.org.au> References: <9322908.27770@mulga.cs.mu.OZ.AU> <1993Aug16.180751.16931@crash> <24qnlt$s4p@hrd769.brooks.af.mil> <256js2INN1jk@kralizec.zeta.org.au> NNTP-Posting-Host: kralizec.zeta.org.au In <256js2INN1jk@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: >I previously gave an (untested) example of how to split a disk so that >the 'c' partition ended at cylinder 1023. It would probably be better >to end it just above partition 'a', e.g.: >386BSD partition: cylinders 400-1746: > 'a' partition 400-598 (root) > 'b' partition 600-799 (swap) > 'c' partition 400-599 (label is on 400, bad144 stuff on 599) > 'd' partition 0-1746 (whole disk) > 'e' partition 600-1746 (usr) >This is also untested. This turns out not to work, due to a suite of bugs and one check. This is what happens: bad144: The bad144 utility puts the bad sector table at the end of the 'c' partition (like I claimed) if the disk does not have a "DOS" partition table. The test for having a DOS partition table is the incorrect "offset of partition 'a' != 0". bad144 does check that the forwarded sectors are before the end of the 'c' partition, so my idea doesn't quite work. bad144 doesn't check that the forwarded sectors are after the start of the 'c' partition; it checks that they are >= 0 (bug 1). disklabel: If the disk has a bad sector table, then the disklabel utility attempts to store backup copies of the label interleaved with the 5 copies of the bad sector table. It thinks that the bad sector table is always at the end of the disk (bug 2). It allows the end of the disk as given by d_secperunit in the label to be different from the end of the disk as given by d_nsectors * d_ntracks * d_ncylinders. (This might be useful but the numbers are sometimes assumed to be the same, so: bug 3.) It forgets that the label is on the second sector of the bootstrap for 386BSD so it stores useless copies of the first sector of the bootstrap (bug 4). old boot blocks: The old wd boot block thinks that the bad sector table is always at the end of the disk (bug 5). new boot blocks: The new BIOS boot blocks think that the bad sector table is always at the end of the disk (bug 6). wd driver: readdisklabel() thinks that the bad sector table is always at the end of the disk (bug 7). The wd driver thinks that the bad sector table is always at the end of the disk (bug 8). The inconsistency between bad144 and everything else can be avoided by making partition 'c' go to the end of the disk. This is dangerous if the 386BSD partition doesn't go to the end of the disk, and it might force the last cylinder above 1023 unecessarily. I've fixed bugs 1, 2, 3, 4, 5, 7 and 8. I'm not sure what to do about the weak but sensible range checking in bad144. -- Bruce Evans bde@kralizec.zeta.org.au