Harddisk boot failure after creating disc image

[InterLockingZ]

Hello all,

we have two old Alpha based Workstation DEC DMCC 5/500 in use. The System was setup by a industrial company in 1998 and we do not have root privileges to the system.
To prevent hard disk errors in the future, we wanted to create disk images of the old SCSI hard drives (Seagate ST32151N / RZ28M).

Several times in the past I had success wich such tasks for x86-architecture and I thought I have a little experience in this.
But after creating the image on a linux machine, the Alpha does not boot ("can't open osf_boot").

What I was doing:
- Installing the disk in the Linux machine (Adaptec SCSI Card)
- booting arch linux (Dist is up to date)
- ls /dev/sd* (Found /dev/sdb without any partitions)
- fdisk /dev/sdb (Because i wasn't sure, if it is the right drive)
- show partition table and disk size, exit with 'q' (no write to disk)
- dd if=/dev/sdb conv=sync,noerror bs=64K | gzip -c > ~/240705_alpha1.image.gz
- shutdown and remove drive

I think, it was a mistake to run fdisk this way. Fdisk informed to create a new DOS-partition table. I am not sure, if the table was already created, since I left fdisk using 'q' and nothing else touched. But I can't figure out, what else can cause the error.
I wrote the image back to another (empty) disk, but running it within the Alpha occours the same error.

We have annother identical Alpha machine with nearly the same setup. Maybe it is possible to copy the area of the "Master Boot Record" from the intact disk to the other, but I have to know, which sectors fdisk could have changed. In future, I can also set a Jumper to write-protect the drive. But before doing anything, I have politely ask for your help for not ending in an even bigger disaster.

 

[osprey]

Running fdisk does not in normal circumstances alter the drives until a configuration is written pressing the w key to write the changes. Usually fdisk lets the user know that that's the case with a message printed on screen.

Copying the MBR from one disk to the other with the hope that it would repair the other, is not likely to work. The disks will almost certainly have different partition tables stored in their respective MBR sectors with different byte allocations for the divisions of partitions. It only takes one byte's difference to fail.

Basically, if the MBR is dysfunctional, then it may be repairable by mounting and chrooting the filesystem from an external bootable medium and reinstalling the bootloader, e.g. LILO or grub. No guarantees if the disks are corrupted though.

Extra thought: if it's a linux or unix system, then root access can usually be gained by altering the root password from either booting into single mode or booting from an external live disk or repair disk.

 

[InterLockingZ]

Many thanks for your answer.
Good to know, that fdisk does not alter the drive without exiting with 'w'.
At the moment, I think the problem may be an hardware issue, since I removed the drive and installed it back. I will check everything again.

The operating system probably is Tru64 UNIX (formerly named DEC OSF/1 AXP and Digital UNIX). I wondered, that the partitions can't be detected / mounted within today's x86-Linux.

Maybe it's effort the worth, building an gentoo "Minimal installation CD" for alpha. Maybe by mounting the live disk I would be able do something more with the system. But before, it would be nice to know, if drive and backup are okay and working. Doing things within the alpha os and also touching the partition table, I don't feel experienced and have to ask before again.

 

[InterLockingZ]

I once again checked the system and the boot process.
I did a mistake by setting the boot-device in the so called SRM-Console (wrong SCSI-drive, since there are two drives installed).
Now the drive is working and booting. The backup drive also works.

I tried to start the system from the gentoo minimal installation CD. But the system returns "Block 0 of dka500 is not a valid boot block". Dka500 is the boot device for the CD drive.

I also figured out, that the partitions are as followed:
/ (root): UFS (Unix File System)
(all others): AdvFS (Advanced File System)

Since the partition links (sdb...) under /dev of the x86-Arch Linux System does not exist, I tried 'modprobe ufs'. But nothing happend. No links within /dev, no output in dmesg and no error message
Any ideas, how I can mount the UFS Partition within Linux?
Nice would be, to mount the partitions straight from the disk image.

 

[Brickwizard]

Is this for a museum? if not, as they would probably have been 32 bit machines then you would need a 32 bit [i386] distribution, BUT 32 bit Linux is rapidly approaching extinction [expected in the next year or so] unless Vitaly important, you may consider replacing them with something a bit more modern that can run 64 bit systems

 

[osprey]

Is this for a museum? if not, as they would probably have been 32 bit machines then you would need a 32 bit [i386] distribution, BUT 32 bit Linux is rapidly approaching extinction [expected in the next year or so] unless Vitaly important, you may consider replacing them with something a bit more modern that can run 64 bit systems

It's a DEC Alpha @Brickwizard ... 64 bit running Tru64 Unix Check posts #1 and #3.

@InterLockingZ wrote:

also figured out, that the partitions are as followed:
/ (root): UFS (Unix File System)

Linux is normally able to mount a UFS filesystem. Check the mount manpage. It may have to specified though thus: mount -t ufs <device> <mountpoint>

 

[Brickwizard]

It's a DEC Alpha @Brickwizard ... 64 bit running Tru64 Unix Check posts #1 and #3.

Apologies, I forgot Intel were playing with 64 bit CPU's back then, spoke to friend who used to work for Compaq, it wasn't his division but did give me a link to the manual if it's of any help [alpha were subject to a number of takeovers ending with HP who closed the project]

Table 4-1 System Troubleshooting (Continued) - Digital Equipment AlphaStation 500 Series User Information [Page 77]

Digital Equipment AlphaStation 500 Series Manual Online: Table 4-1 System Troubleshooting (Continued). Problem System does not boot Possible Cause Operating system software is not installed on the hard disk drive. System cannot find the boot device. Environment variables incorrectly...

www.manualslib.com

 

[bob466]

Devine intervention maybe required here with something 37 years old.

 

[InterLockingZ]

The system is now up and running. The post is therefore solved. Many thanks to all, especially osprey!

We were now able to install a fresh Tru64 UNIX 4.0F from installation disc.
Unfortunately we were not able, to store the SRM-Variables (boot-parameters) to non-volatile memory, using '/sbin/consvar -a'
I have to check, if there is another 'BIOS'-Battery, which could be empty.

I also didn't really tried to mount the original drive partitions within the installed system yet. There is no fdisk command, so I can't see partition table using 'fdisk -l'.
It would be nice to change the root-password on a copy of the original drive in case of further maintenance tasks. But this is not really necessary yet.

Maybe there is someone out there, who have experience with the museal system.
We use the system in our university to teach our students. It's part of an railway interlocking system.
From the point of mechanical interlockings, which we also use, it's a very new system.