"Larry O'Neill (H.S.A.)" <[EMAIL PROTECTED]> wrote: > > 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???
See bottom of www.openbsd.org/alpha.html. > 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
