How can I verify a system disk?

[Paul Beaudoin]

I may of may not have a problems here. Briefly: I created an LD device and backed up the system disk (/image) successfully to it (no verify) intending to get this to dvd for saftey. Meanwhile, cleaning up the disk by removing unused facilities, I discovered that removing Pathworks kindly destroys Excursions also (thanks guys). Having a recent backup I used it to restore from the LD device and booted OK. I tried to boot the other box into the cluster. I stripped out its old root and created a new one via cluster_config. The sattelit then boots, finds its first image but then fails to locate sysboot.exe. It is there and in the same relative location as the booted node. This seems to suggest something not quite right with the system disk. The check I have found is DFU /verify (which passes). Is there any method to ensure that on a reboot, the current system disk is bootable?. Just to keep things simple - I can no longer boot from CD. I intend to create a 'mini-vms' before attempting this but would like to have some hint as to what, if any, the problem is here before (possibly) throwing the whole thing off a cliff.

Many thanks for any hints

Regards

PAul

[Heinz W Genhart]

Hi Paul

It seems like the bootblock has not been saved properly.

To recover from this, you need to use the WRITEBOOT utility. With this utility you will be able to update the information that APB requires to locate SYSBOOT.EXE

SYSBOOT.EXE must be contiguous.
Then RUN SYS$SYSTEM:WRITEBOOT and follow the instructions.


Hpe that helps

Heinz

[Paul Beaudoin]

Heinz,

Thnaks for the quick reply and I'll try that tonight. Can I assume it is safe to just do this regardless of whether it is correct now or not (within reason?). Also - as this is the booted disk, does that not mean that the bootblock is (or at least was, at boot time) OK?.
I'll use dfu to defrag (if necessary) sysboot.exe and then re-create the root.

Many thanks

Paul

[Heinz W Genhart]

Hi Paul

If you follow the instructions of writeboot you will not encounter problems. If the bootblock was already ok before you used writeboot, it will also be ok after using writeboot.

Another Question: Did you use @sys$system:setfilenomove. This is very important if you are usin a defragmenter.

The following you can find with HELP SET FILE/MOVE

When you create a file, movefile operations are enabled on that file. You should disable movefile operations on specialized files that are accessed other than through the XQP (such as files accessed through logical I/O to a disk).

Regards

Heinz

[Paul Beaudoin]

Heinz,

Thanks again. I don't use a defragger - I am in the fortunate position of have plenty of disk space. IF the original backup/restore operations completed correctly, I'd assume the SET FILE attributes originaly in place are still there. What the issue is: If the bootblock or sysboot.exe (or any other basic file) is in some way wrong, is there a way to determine if this disk is still (fully) bootable. Or alternately, is there a process by which I can ensure that it is?
I have some appreciation how complex the answer to this can be.
Thanks

Paul

[Heinz W Genhart]

Hi Paul

I dont know a way to verivy, if a systemdisk is bootable, without to try it.

Some ideas:

- ANALYZE/DISK sys$sysdevice:
Check the output. Something suspect ?
ANALYZE/DISK/REPAIR sys$sysdevice

- doing autogen
Is there something suspect ?
AGEN$PARAMS.REPORT ?


I think you should execute writeboot and then try to boot the second machine. If this stil does not work I have at least some other ideas what the problem could be, like a corruption within the systemdisk structure. I think there is a note everywhere, describing this problem. Let me try to find it ....

Regards

Heinz

[Heinz W Genhart · Accepted solution]

Hi Paul

I found a document within ITRC which describes this problem very good. Try the following Link:

http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=816240


Hope that helps

Regards

Heinz

[Paul Beaudoin]

Heinz,

That worked a treat - 10 out of 10. I have now progressed in the boot to the next problem (sorry about this) ...

I stripped out the old root and re-wrote it using cluster_config just in case the writeboot change needed that. Accepted most of the defaults and entered correct numbers where needed. The sattelite now boots to a stage where it sends a 'join the cluster request' With the boot machine up and a reply/ena set, it reports, in sequence 'Received cluster request', 'propose adding new node' and finaly 'cluster transition complete'. Then the sequence repeats endlessly with the sattelite requesting and apparently the boot node accepting with no further progress. I left this for some time (maybe 20 or so cycles). On occasion, maybe every 7-8 cycles, the sattelite reports 'have connection to ccci20' (boot node). I rewrote the cluster password just in case of corruption but other than that, with everything seeming to be OK, am stuck. Can you (or anyone) suggest a way forward?

Many thanks

Paul

[Heinz W Genhart]

Hi Paul

did You change the cluster Password and Group ?
If so, did You reboot the whole cluster?
Note: the whole cluster must be down. As long as one node is stil up, you will never be able to boot another Node, because the remaining node in the cluster is stil using the old password and group.

The only way is, to shut down the whole Cluster and then to reboot one node after another.

Regards

Heinz

[Paul Beaudoin]

Heinz,

I changed the password (to the original in case it was corrupted or otherwise unreadable) in the only boot node. This is a 2 node cluster and it is the 2nd one I am trying to boot. Are you saying I also need to reboot the node I changed this on?

Thanks

Paul