Re: [slackware-sparcdevel] New updates

From: Phil Howard (phil@ipal.net)
Date: Sat Dec 16 2000 - 16:50:03 PST


David Cantrell wrote:

> On Sat, Dec 16, 2000 at 03:19:13PM -0600, Phil Howard wrote:
[...snip...]
> > Before running fdisk I did:
> > dd if=/dev/zero of=/dev/sdb bs=4096
> > Then when I did run fdisk, it prompted me for the type of disk. I entered
> > the value "0" for custom, then pressed empty returns to all questions for
> > device parameters to accept the defaults, which appeared to all be correct.
> > So the disk label involved was what fdisk put there.
> >
> > Even the Intel version of fdisk has had calculation and overlap bugs since
> > I recall ever using it. In some cases those bugs won't put partitions right
> > next to each other. In other cases I have seen overlaps. One of the things
> > I am seeing in the sparc fdisk is that it lets me allocate cylinder numbers
> > 0 through 1008 for a 1008 cylinder disk, whereas the Intel version numbers
> > the first cylinder as 1. I think there are a combination of "one off" bugs
> > and calculations not respecting sector mode in there.
>
> I must say that that's a very odd way of going about partitioning. What I
> do is just drop the disk in the machine (no dd step involved), then fire
> up fdisk on that device and type "s" to create a new empty Sun disklabel.
> Then I create partitions from there.

I've encountered several instances where garbage remaining on a disk can
cause fdisk to croak. Valid circumstances (in the sense of not being there
to intentionally croak fdisk) can do this (such as accidentally writing a
file to the device). I've even found that the RAID label from a Compaq RAID
system can cause fdisk (at least the version for Sun as distributed with
Redhat 6.2 for Sparc, and Debian potato for Sparc) to croak. Also, I
recently copied the contents of one disk to another disk with the intent of
replicating the first couple of partitions (I was planning to delete the
remaining partitions). The target drive was big enough for the partitions I
wanted to keep. But fdisk croaked and would not start when it ran it on
that disk. The reason? The extended partition ran off the end of the
device, and some of the logical partitions began off the end of the device.
So fdisk tried to read their extended partition tables and got an error and
gave up. It can handle cases where the partitions are outside the range of
the device, but not if a logical partition table is.

In summary, the intent and purpose of my practice is to ensure things are
reduced to known and reproduceable conditions. I had to dd the MBR in that
scenario of copying disks, and put the entries for the 2 copied partitions
back in manually. 21 years of professional sysadmin experience teaches many
diligent practices. I routinely zero off an entire drive before installing
anything on it, especially if it's MS Windows.

> OK, that could be it. I am using gcc 2.95.2 to compile the kernels. I'm
> going to upgrade to 2.2.18 and use gcc 2.95.2. I'd like you to give that
> new kernel a try and see if it does the same thing. If it does, I'll
> recompile using another compiler and we'll see if it goes away then.

Sounds like a plan.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------



This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT