Format unit requires destructive mode???

I am trying to format a Seagate 2 Gb SCSI drive using the HP-UX 9.0 support disc and I receive a message that says: DESTRUCTIVE MODE REQUIRED TO EXECUTIVE THIS COMMAND (SCD2WARN 106). I have entered this command several times on other SCSI drives and never got this message. Anyone ever see this and how do you resolve it?

Thats old...
Are you talking of a series 800 (server) or 700?

It is a series 700. I believe it is a 742.

OK... because 800 in 9.XX was introduced to LVM and in HFS format allowed up to I think 16 partitions.. and commands differed.. Only I know (more) 800 using 9.04 (I started with 8.XX) (sic) but did work with a 715,710,725(9.05)...
So I can remember, what commands are you actually passing, what were the ones that worked ( and what for...) that arent anymore? From what I remember its not just adding a new disk of XGB and it works!
The exact model has to be known by the OS, it should have a description in /etc/disktab
id not you would to have to add an entry...
Then you used mediainit command (but was that for 800 only?)
I cant remember of a "format" command :frowning: You will maybe need to refresh my memory a bit... but remember you had to use mkdev ( and config -a) and mknod

I am using HP-UX 9.05. The support disc is booted into the SCSIDSK2 which brings me to the DUI> prompt. The following command is entered: run scsidsk2 ldev=/dev/diag/dsk/c201d6 pdev=2/0/1.6.0 section=17 At the SCSIDSK2> prompt. I enter format unit. That's when the destructive mode is required. I am already a superuser, so I should have complete control to do whatever I want to the disk, but there appears to be some sort of security code that is required to gain access to the disk. What is this code?? Thanks in advance.

I am not a HP-UX expert (my forte is Solaris/SCO/Linux) but I have seen such things before. My immediate thoughts are:

  1. The disk has been used in another environment (or came from the factory) with a register value set on a mode page on the SCSI drive which is causing this, or,
  2. Some O/S's don't like to overwrite partition tables written by other O/S's.

I suggest that, if possible, you put the drive into a PC and try installing Windows on it. Does it object to that? If not, run the Windows install routine again and, when prompted, remove all partitions but DON'T create any new partitions. Simply turn the PC off when no partitions are present and put the drive back into the HP system.

As far as (1) above is concerned, I don't know how to get a HP-UX system to "set mode pages to default" on a SCSI drive. However, this may be what is required. (If you've got a Solaris box there I can tell you how to do it).

I tried what you suggested on WinXp and it recognized the SCSI Seagate disk. When I reinstalled it in the HP-UX 9000/742 computer I got the same error. I skipped over the support disk format function and went to the HP-UX installation disk phase. Everything installed correctly until the last step where I had to do an update on the X window screen. It stopped updating and I got a memory dump error. I did a reboot and got this error: cannot read block 17363328. It suggested to use fsck interactively. Not sure how to do that. Thanks, one again, in advance.

I'm not a HP-UX expert but fsck is fairly generic so I would expect something like:

fsck /dev/rdsk/c0t0d0s0 (or whatever the device name is).

Apart from that, you normally cannot fsck a filesystem that is mounted so, if this is a root filesystem, you will probably need to boot from cd and fsck the hard disk filesystem device name from there.

Also, most fsck implementations include a switch "-o full" which will do a really long and hard fsck (but may take a long time).

It may be that you've got some bad disk blocks on the drive and there must be a "badblock" management utility from HP that will map these out. Perhaps a HP-UX expert on this forum will tell you how to do that.

When I rebooted the HP Computer this morning it still detected an error in the file system, but then it went into an automatic fsck repair and apparently it fixed the bad block without the interactive fsck mode. I will use your fsck option tomorrow. Thanks again in advance.