PDA

View Full Version : iv: cannot reformat Winchester disk.



firebirdta84
December 16th, 2014, 11:36 PM
On a typical AT&T UNIX PC hardware setup, I'm trying to execute iv (initialize volume) from a floppy disk, and reformat my ST506 Winchester disk.

I've copied iv to my "disk 3" of install process, and it will perform most functions, such as "iv -d /dev/rfp000", which prints out the correct description file for the existing hard disk format.

I went on to place the desired description file and loader source file on the floppy, as iv needs these resources when executing iv -i

So, running UNIX 3.51 from floppy disk, I try to execute

iv -iv /dev/rfp000 desc.file

I get this error every time:

-------------------------------

/dev/rfp000
Device Type: HD Name: ms6805
Cylinders: 1024 Heads: 8 Sectors: 17

** Phase 1 - Initializing Internal VHB.
iv: cannot reformat Winchester disk.
** Phase 2 - Formatting Hard Disk.

:S: D::The previous operation on this
floppy disk was incomplete.

Please run Floppy Disk Repair or
remove all files and reformat
the floppy disk.
panic: Format hard drive other than 1

Please record panic message.
Press hardware reset to reboot.

-------------------------------

So, desc.file is the description file with the following contents:


#sccs "@(#)iv/lib:miniscribe6085 1.1"
# Miniscribe 6085
type HD
name ms6085
cylinders 1024
heads 8
sectors 17
steprate 0
$
badblocktable 1
loader /usr/lib/iv/s4load.silent
$
$
0
8
508
$
$


(note: s4load.silent I put on that path /usr/lib/iv/ directly on the floppy)



Also, this error does not appear to be disk model/brand specific, as I've demonstrated this error on about 4 different models/brands of ST506 hard drive, (Maxtor, Seagate, MiniScribe and MicroScience)

Does anyone have any ideas?

For reference, here's my goal:

Using my UNIX PC, I want to reformat any ST506 Winchester hard drive to make slice 1 and slice 2 (close to) equal sizes. The reason for this is my MightyFrame restoration project. They MightyFrame wants to boot the CTIX OS from slice 1 only, and so I need to format the disk with a large enough slice 1 to handle this.

The diagnostic disk does not give me any options to adjust the slice/partition sizes when "initializing hard disk". Is it really there, hiding from me?

For that, I'm using the following description file, which doesn't matter yet, because I can't even use the "standard" description file running iv from floppy the way that I am.

Notice how I've specified 4092 as the "start" of slice 2. This use of description file parameters is described in detail in the UNIX System V User's Manual here
http://bit.ly/1syVep9


type HD
name winche
cylinders 1024
heads 8
sectors 17
steprate 0
$
badblocktable 1
loader /usr/lib/iv/s4load.silent
$
$
0
8
4092
$
$


Thanks, everyone, for your ideas.
-AJ
http://MightyFrame.com

Stone
December 17th, 2014, 04:00 AM
Do any of the drives you mentioned work on any systems? Can you access any of them on any level? If not you might have a collection of doorstops. 25+ year old MFM drives are rapidly becoming an endangered species with regard to functionality and are joining the ranks of exquisite doorstops more and more often.

firebirdta84
December 17th, 2014, 11:51 AM
"Do any of the drives you mentioned work on any systems?"
Yes, actually they all do. Previously, I formatted all of them "standard" to operate on the UNIX PC, and they all boot and run just fine. And I mean I did this all within the last 3 months, not 30 years ago.

Now, This is my attempt at re-partitioning known working drives.

"Can you access any of them on any level?"
Yes, all levels.

"If not you might have a collection of doorstops. 25+ year old MFM drives are rapidly becoming an endangered species with regard to functionality and are joining the ranks of exquisite doorstops more and more often."
Well, I do have some of those too, but I've been very careful to keep them out of this project.

Thanks for the question...very good feedback here!

-AJ

kb2syd
December 18th, 2014, 06:39 AM
When booted from floppy, can you mount the /dev/fp000?
What about putting the drive in as the second hard drive and trying to format it.

firebirdta84
February 12th, 2015, 09:50 PM
kb2syd,

Thanks for this info. Sorry for the delayed response.

"When booted from floppy, can you mount the /dev/fp000?"

Yes, that works well to access the drive, but more accurately, it would be /dev/rfp000 for the raw disk access (I think...), because /dev/fp000 doesn't exist, at least not on the UNIX PC. Again, still learning here.

"What about putting the drive in as the second hard drive and trying to format it."

Unfortunately, my UNIX PC doesn't have the home-brew modifications that enable it to use more than 1 MFM hard drive.

Now, my MightyFrame DOES, and since I started this conversation, I've had some success there. I'll get to that in another post.

Basically, just to wrap up this thread, I did figure out a way around this, but it was pure trickery. I stole a VHB from another dirve formatted thew way I need it to be, with identical physical architecture.

I was guessing that after iv does the low-level format, but before any filesystems are made, or any data is written, the only thing that exists on the drive is the VHB in block 1, and the bad block table in block 2 (or 2 & 3). It doesn't even have a bootloader after that yet.

So, I theorized that, since it's the VHB that determines exactly where the slices (as the UNIX PC and MightyFrame docs call what we commonly call "partitions"), then all I need to do to change the slice sizes and numbers is edit the VHB appropriately.

Well, iv is the program that writes the cryptic code that is the VHB, and since that was refusing to "reformat" the drive after the low-level format is done, then I figured I'd trick it, get a VHB from another drive that has the right size and number of slices.

to steal the VHB, on the system with the right formatted drive:

dd if=/dev/rfp000 of=stolen.vhb count=1

Then to implement the stolen VHB (Note, I stress here that NOTHING was on the drive at all, this came immediately after the low-level format):

I booted the UNIX PC from floppy, that already had stolen.vhb on it, then I did this:

dd if=stolen.vhb of=/dev/rfp000

This worked, and it worked well!

Then I proceeded to load the bootloader and OS on the drive, using the factory-out-of-the-box install process for the UNIX PC, and it immediately recognized the new slices and slice sizes that were in the stolen VHB.

My hope is that, someday this can help someone else doing some crazy project like what I'm doing here...

tingo
February 14th, 2015, 12:48 PM
Nice work, very good of you to document it here.