The original question is at the end.
Thanks go out to:
John James
William J. Bochik
Collin Walters
Dr. Tom Blinn
Ernest Gronblom
SUMMERY
Dr. Tom Blinn
> If you can boot from the CDROM media, you may be able to extract your
> disk label from the disk (using disklabel -r /dev/rrz0a > /tmp/label)
> and then zero the label on the disk and re-write it with UFS boot
> blocks (disklabel -z /dev/rrz0a, then
> disklabel -r -R /dev/rrz0a /tmp/label rzxx)
> but this is always somewhat risky. And this is assuming that what's
> making the disk not boot is bad boot blocks. If you managed to hose
> your root partition, that could lead to a failure, too.
>
> Just not really clear what exactly is making it fail, but it looks
> like the primary boot strap program (which gets read in from the
> boot blocks and needs to be able to find the root partition to read
> in the secondary boot strap program "osf_boot") is just halting, and
> that usually means it's not finding on disk what it expects.
Ernest Gronblom
> The boot block on the disk is different for UFS and ADVFS. You need to
> relabel your disk (make sure you retain your partition sizes!) with -t advfs:
>
> disklabel -r {diskname} > /mydisklabel
> cat /mydisklabel # Ensure that a valid label was read
> disklabel -Rr -t advfs {diskname} /mydisklabel {disktype (found in header of
/mydisklabel)}
>
> This should resolve the problem (at worst it is non-destructive).
Both Dr. Tom Blinn and Ernest Gronblom pointed out that it looked like the boot
block was not correct for the boot partition. I put a new boot block on the
disk using disk label and the following steps.
Steps:
//boot from CD
>>> boot DKA500
// use MAKEDEV to create the device special files for the disk.
# ./MAKEDEV rz0
// Copy the current disk label to a file
# disklabel -r /dev/rrz0a > /tmp/rz0.label
// Re-label the disk with boot block for ufs and use the label in the file
rz0.label
# disklabel -Rr -t ufs rz0 /tmp/rz0.label RZ2ED-LS
// Shutdown and reboot the system.
# shutdown -h now
//boot from disk
>>> boot DKA0
The system booted perfectly with all partitions mounting and no loss of data.
During the system setup I must have inadvertently damaged the boot block. I
will update this summery if the we discover how the boot block was damaged.
ORIGINAL POST
> Managers,
>
> We have an Alpha 800 server that I just installed tru64 4.0g on. The
system
> went through the installs and setup fine. I then Installed Legato, DIA, and a
> few other software packages. After setup advfs and mounting the other disks
in
> the system I rebooted it and got the following message:
>
> jumping to bootstrap code
>
> halted CPU 0
>
> halt code = 5
> HALT instruction executed
> PC = 20000000
> >>>
>
> The system had been running fine with tru64 4.0d so I thought this was a BIOS
> problem. I upgraded the BIOS to 5.7 and the machine will still not boot. I
can
> boot CD and mount all of the partitions on the hard disks I ran fsck on
> partition a and it came back clean. I am fairly new to tru64 and do not know
> how to proceed. I found four five problem just like this in the archives but
> there were no summaries I will summarize.
>
> Any help is greatly appreciated.
>
Received on Tue Sep 26 2000 - 22:08:06 NZST