Hi,
Thanks for your replies. I have started a dd from the disk to a
volume mounted over nfs from an i386 box. My hope is that from there I
will eventually be able to sort out getting the data from it. Right now I
need to return the disk itself and the Alpha it came in back to where it
came from.
Another approach I had been considering was booting the alpha from
an openbsd install disk for Alpha (if such a thing exists - I didnt
install the Alpha), mounting the hard drive from there, and getting the
data from it that way... assuming the machine can actually boot from the
cdrom. The OpenBSD CDs I have have i386, amd, sparc, etc... but not
alpha... Is there a place I can get a CD that has complete install
components for Alpha???
Larry
On Tue, 21 Mar 2006, Martin Reindl wrote:
> Joachim Schipper <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Mar 20, 2006 at 09:31:33PM +0000, Larry O'Neill (H.S.A.) wrote:
> > > Hi.
> > > I have a disk from an Alpha server that I need to get data from... The
> > > Alpha server no longer boots, and I dont have the time right now to
> > > diagnose the problem. So I took the disk and lashed it into a Sun Ultra60,
> > > which is also running OpenBSD. My problem is that I cant remember all of
> > > the details of the partitioning that the disk had... So in terms of
> > > getting access to the data, how do I find out what to put into disklabel
> > > for it? Unfortunately due to other complications, I currently dont have
> > > fdisk on the machine.
> > >
> > > (only 2 slots for Ultra2 SCSI Wide, one was root disk, other was /usr.
> > > Copied as much stuff onto the root disk that space would alow, so that I
> > > could remove the origional /usr disk and put in the one I need the data
> > > from. This caused some stuff not to work because not all of it could be
> > > copied over)
> >
> > As Theo pointed out, this is rather difficult (though I had no idea it
> > was *that* difficult, honestly).
> >
> > A low-level disk recovery is possible, but extremely painful. I have no
> > idea if such recovery-kits as The Corononer's Toolkit and the Sleuthkit
> > (newer than TCT) work on Alpha disks (they do claim to work on OpenBSD),
> > but if they do, they might be a good bet, changing low-level recovery
> > from 'extremely painful' to something more like 'very painful'.
> >
> > Be aware that they are both meant to gather information from a system
> > after it's been broken into, more than recover a complete filesystem
> > from scratch, which is one of the reasons for the 'very painful'.
> > Notably, they seem to deal mainly in deleted inodes, rather than
> > allocated ones, and I am not at all certain they can even be made to
> > work with allocated nodes.
> >
> > If you can get the Alpha to come up even a bit, you could write a bunch
> > of NULLs and a large tar file directly to disk, which would be much
> > easier to recover (the NULLs are optional, but make it easier to see
> > where the data starts; directly means bypassing the filesystem, which
> > might scatter stuff all over the place). However, I gather that's not an
> > option, and if you can get the Alpha up that far you could probably just
> > nc the whole thing.
> >
> > If the data is not too private, you might want to check if there is a
> > fellow Alpha owner near - that would, by far, be the easiest solution.
> >
> > Of course, you can always try hacking the kernel to read Alpha disks,
> > but that is likely to be far from trivial.
> >
>
> The big task is really endianess, look at NetBSD's 'option FFS_EI'. The
> easiest solution should be just slapping the drive into a stray i386 box.
>
> martin
