Sorry about that I hit the send button before I had extracted the fdisk info
here it is...
The number of cylinders for this disk is set to 38661.
This is larger than 1024, and may cause problems with:
1) software that runs at boot time (e.g., LILO)
2) booting and partitioning software form other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Disk /dev/sda: 64 heads, 32 sectors, 38661 cylinders
Units = cylinders of 2048 * 512 bytes
Device Boot Begin Start End Blocks Id System
/dev/sda1 * 1 1 11 11248 83 Linux native
/dev/sda2 12 12 1036 1049600 83 Linux native
/dev/sda3 1024 1037 5133 4195328 83 Linux native
/dev/sda4 5120 5134 38661 34332672 83 Linux native
Still I tried you "dd if=/dev/zero of=/dev/sda bs=1k count=1" on my disk
and rebooted. (Of course now it won't boot at all) but I went through
the redhat install again until I could get to fdisk and checked its
parameters and they were still the same.
(I then reconfigured fdisk exactly the way it was before. mounted the
drives under the redhat install shell and reran lilo. fdisk/mbr and
I am back up and running.
But the disk still reports the wrong sizes. (df and fdisk actually.)
What are DPT users with extremely large RAID-5 arrays suppose to in order
to get the kernel, fdisk and df to report the correct sizes.
Thanks,
- Jeff
Miquel van Smoorenburg wrote:
>
> In article <cistron.363C7C62.9E0F451C@la.usweb.com>,
> Jeff Wiegley <jeff@la.usweb.com> wrote:
> >We just upgraded the size and number of drives on a DPT controller.
> >Now the controller has 7 18gig drives on it for a total of 104Gig
> >(in RAID-5 configuration). (note: that is 18 (eighteen) not 8 (eight)
> >as somebody incorrectly read and answer a recent news article on
> >a very similar problem.
> >
> >The problem is that when the EATA-DMA driver starts up it correctly
> >reports /dev/sda as having 213395712 sectors. which works out to
> >104gig (or so).
> >
> >but fdisk reports this:
>
> [nothing..] that's not much :)
>
> >2) what the values for heads, cylinders and sectors should really be?
> > The DPT configuration utility doesn't seem to present any sane values.
> > only the DPT bios reports 65535/64/32 which is meaningless and no where
> > near 104Gig as well.
>
> I have no idea, but perhaps the Linux kernel will work something
> out for you. Fdisk (and the kernel) take CHS from the partition table,
> if a valid partition table is present. I assume your drives have been
> used before, so there might be old information on it.
>
> Wipe out the partition table on the disks with something like
>
> dd if=/dev/zero of=/dev/sda bs=1k count=1
>
> Then reboot, and try again ..
>
> HTH
>
> Mike.
> --
> ... one of the main causes of the fall of the Roman Empire was that, lacking
> zero, they had no way to indicate successful termination of their C programs.
> -- Robert Firth
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-- J E F F W I E G L E Y, Ph.D. Systems Analyst ___________________________________________________ USWeb Corporation http://www.usweb.com/ 8522 National Blvd, Suite 101 Culver City, CA 90232 ph 310 815 1177 x 216 fax 310 815 1133 mailto:jeff@usweb.comUSWeb - A Strategic Partner for the Information Age
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/