Date: Sun, 2 Apr 1995 04:42:06 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, mark@grondar.za Cc: Kai.Vorma@hut.fi, current@FreeBSD.org Subject: Re: panic: update: rofs mod Message-ID: <199504011842.EAA17673@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I had similar problems to Kai, but I remembered the changes, so no panic. >what I cannot get round is this: (please bear with me) >I am running current (ctm 471) with a 2-3 day old kernel. >> Mar 31 12:42:49 grunt /kernel: sd0s4: start 1, end = 412359, size 412359: OK >> Mar 31 12:42:49 grunt /kernel: sd0: rejecting partition in BSD label: it isn't entirely within the slice (**) >> Mar 31 12:42:50 grunt /kernel: sd0: start 1, end 412359, size 412359 >> Mar 31 12:42:50 grunt /kernel: sd0d: start 0, end 415599, size 415600 >(x3) >(**) This I can fix by getting rid of the "d" partition, right? Yes. >EXCEPT I get this when I exit disklabel: >> ... >> 4 partitions: (was eight) >> # Hsize offset fstype [fsize bsize bps/cpg] >> a: 40960 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 167*) >> b: 65536 40960 swap # (Cyl. 167*- 436*) >> c: 412359 0 unused # (Cyl. 0 - 1689*) >> e: 305152 106496 4.2BSD 1024 8192 16 # (Cyl. 436*- 1687*) >[exit] >> Warning, unused partition e: size 305152 offset 106496 >> disklabel: ioctl DIOCSDINFO: Open partition would move or shrink >> re-edit the label? [y]: n >1) What does the DIOCSDINFO mean? It's the name of the ioctl that failed. This is perhaps more useful to know about than "Open partition would move or shrink". There is no errno to describe the failure in this much detail, so disklabel(1) guesses an error message which in this case is worse than useless. >2) e is most certainly not unused! You need 5 partitions to reach the 'e' partition (a-e, with d empty). I always use 8. This doesn't waste any space. >The logfile continues: >> Mar 31 12:42:50 grunt /kernel: sd1s4: start 1, end = 2045651, size 2045651 >> Mar 31 12:42:50 grunt /kernel: sd1s4: C/H/S end 933/6/34 (222291) != end 2045651: invalid (+++) >> ... >(+++) is wierd. Ths is a 1GB SCSI disk, and the variable (or whatever) used >to hold the number of tracks seems a little messed up. >Here is an fdisk session >> bash# fdisk -u /dev/rsd1c >> ... >> cylinders=2981 heads=7 sectors/track=98 (686 blks/cyl) ** These are OK >> ... >> The data for partition 3 is: >> sysid 165,(FreeBSD/NetBSD/386BSD) >> start 1, size 2045651 (998 Meg), flag 80 >> beg: cyl 0/ sector 2/ head 0; >> end: cyl 933/ sector 34/ head 6 >> ... >> Supply a decimal value for "size" [2045651] >> Explicitly specifiy beg/end address ? [n] y >> Supply a decimal value for "beginning cylinder" [0] >> Supply a decimal value for "beginning head" [0] >> Supply a decimal value for "beginning sector" [2] >> Supply a decimal value for "ending cylinder" [933] 2981 ** Look here! >> Supply a decimal value for "ending head" [6] >> Supply a decimal value for "ending sector" [34] >> sysid 165,(FreeBSD/NetBSD/386BSD) >> start 1, size 2045651 (998 Meg), flag 80 >> beg: cyl 0/ sector 2/ head 0; >> end: cyl 933/ sector 34/ head 6 ** WTF?? >> Are we happy with this entry? [n] ** Of course not! >> Supply a decimal value for "sysid" [165] ^C ** Outta here! First, the ending cylinder can't be 2981 because there are only 10 bits for it in the partition table so it must be < 1024. fdisk silently truncates it mod 1024 when it calculates it from `start+size' and silently truncates it mod 1024 when you try to fix it. There is a compatibility kludge that allows large cylinders if they are only correct mod 1024. See old commit mail. For this to work, at least one of the partitions should have ending head and cylinder numbers that agree with the BIOS geometry. fdisk should enforce this (it doesn't). You only have one partition, and its ending H/S is 6/34 which is unrelated to the geometry (H=7, S=98) so the compatibility kludge fails. The bootstrap apparently manages to succeed because the 6/34 is good enough to translate the label sector number (because the label is on a very early sector). If the BSD slice isn't first, then it is essential for some ending H/S to be maximal, but this usually occurs because the OS's that created the other slices did a better job of setting the ending H/S suitably for FreeBSD than FreeBSD does for itself :-(. 2981/7/98 is an unusual geometry for 1GB scsi drives/controllers. Most controllers translate to nnnn/64/32 where nnnn < 1024 so there are less problems, especially if you don't try to use all the sectors on the disk and round to an (apparent) cylinder boundary. Rounding to a cylinder boundary should have worked for your disk too, but you can't use it if you have something on the disk above the rounding point. There is another compatibility kludge that allows large cylinders if they are replaced by 1023 and the ending H/S are replaced by the maximum H/S values. See old commit mail. This kludge probably applies in your case: set the ending C/H/S to 1023/6/98 and leave the size alone. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504011842.EAA17673>