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

[Heinz W Genhart]

Hi Paul

after changing the Cluster Group and Password, it's required to have the whole cluster down.
You will not be able to boot the second node, as long the first node is not also down at same time. (all nodes must be down at same time)

Regards

Heinz

[Paul Beaudoin]

Heinz,

OK - I should have read your original note a bit better - yeou did tell me that but I didn't hear it :-)

I'll (holding my breath) try that tonight. Comes back to the original question - As near as I can tell this sys disk is OK but would love to prove that before reboot. The real problem here is that I can't boot off CD anymore (hardware prob) and if I run into problems it gets a bit complicated.

Many thanks - I'll let you know.

Paul

[Paul Beaudoin]

Heinz,

Partial success. As part of other things, I installed the PCSI and upodate003 patches and rebooted. Bugchecked on the first try very early in the sequence but came up fine on the second try. All seems well. The sattelite still shows the same result though - it gets its first file(s?) and then starts requesting cluster membership endlessly. I was a bit rushed so didn't get the boot screen up and see what it was saying so I'll have to try that over the weekend to get the complete picture.

Thanks for your help (and patience)

Paul

[Paul Beaudoin]

Gents,

I'm really stuck now. Back to the original problem: Sattelite finds initial files then requests cluster membership. Boot node appears to accept (received Request followed by cluster tansition completed) and then sattelite requests again repeating this cycle. I have now: changed the cluster pass and rebooted, checked VAXCLUSTER param (2) and licensing - all OK. I have also booted the sattelite standalone (it has a sys disk) and that is OK. I searched but could not find a basic guide (check list) to cluster building. This has to be something simple and so obvious that I can't see it. Straw grabbing: was there any licence requirement changes in 8.2? Any suggestions?

Thanks

Paul

[Paul Beaudoin]

Gents,
Just to close this out properly - I have found the problem. The new root created by cluster_config.com included setting the sysgen param expected_votes to 2 in the new root. Once changed to its proper value of 1 , it booted. This is a vms/procedure error. The vote param was set (correctly) to 0 and from the local box the correct value of 1 could and should have been calculated. This was a brand new root creation and I did not even check, never mind change any params as until now, it was a safe assumption that all were correct.
Many thanks to all, especially Heinz who helped me through this.

Paul

[Paul Beaudoin]

See previous post.