Date: Tue, 4 Apr 1995 05:56:23 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@FreeBSD.org, swallace@ece.uci.edu Subject: Re: slice code Message-ID: <199504031956.FAA00223@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>My Quantum 1080S has 1028 cylinders in it. Before the slice code, >I allocated the first 1024 cylinders in the partition. However, >in the disklabel, I did not want those 4 MB to go to waste so I extended >the BSD partitions beyond that to the real drive size. Since you only >need first BSD partition inside the 1024 cylinders this does not cause >any probs. >Now with the slice code, this no longer works. I had to change the size >of my BSD partition to the real drive size. Unfortunately, that no >longer fits in 1024 cylinders and it wrapps to end at cylinder #4 >(I have also tried specifying the end cylinder at 1023). >Now when I boot, I get 'No Operating System' error message. I now >have to use a BSD floppy to boot the disk. Apparently the BIOS is even fussier than the slice code. What exactly did you put in the partition table? >Instead of having to change the size of the partition, the slice >code should not reject disklabel entries that are not inside any other >partitions. So only if a disklabel entry used an area of a disk >that was covered by another slice it should be rejected. It also This isn't workable in general. Consider slices for different OS's, each with a magic internal label covering sectors outside the slice. >would be nice to use the real disk size in determining if an entry >went beyond the physical drive limit not the unreliable BIOS/DOS partition >info. Now the size is max(real disk size according to drive, disk size according to unreliable partition info) It would be better to use the reliable partition info here :-). (C/H/S values are unreliable and linear sector numbers are reliable). There is a bug setting the number of cylinders reported in the dummy label on /dev/rsdN to match the unreliable partition info: it isn't changed from the value reported by the drive, so it is usually wrong if the H/S values are changed to match the unreliable partition info (1980/13/80 becomes 1980/64/32 for one of my drives; it should become 1015+/64/32). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504031956.FAA00223>