Re: SCSI disk from an Alpha box, in a Sparc
On Mon, Mar 20, 2006 at 09:31:33PM +, 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. Joachim
Re: SCSI disk from an Alpha box, in a Sparc
On Tue, 21 Mar 2006 10:44:50 +0100 Joachim Schipper [EMAIL PROTECTED] wrote: On Mon, Mar 20, 2006 at 09:31:33PM +, 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). Just because the label is built just for a particular arch imho you still can use dd and the raw device . ~~ http://www.chatou-informatic.com Maintenance, infogerance, interventions sur site, telemaintenance
Re: SCSI disk from an Alpha box, in a Sparc
Joachim Schipper [EMAIL PROTECTED] wrote: On Mon, Mar 20, 2006 at 09:31:33PM +, 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
Re: SCSI disk from an Alpha box, in a Sparc
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 +, 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
Re: SCSI disk from an Alpha box, in a Sparc
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 +, 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
SCSI disk from an Alpha box, in a Sparc
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) Larry machine$ disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: RZ2DD-LS (C) DEC flags: bytes/sector: 512 sectors/track: 168 tracks/cylinder: 20 sectors/cylinder: 3360 cylinders: 5273 total sectors: 17773524 rpm: 10045 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 3 partitions: # sizeoffset fstype [fsize bsize cpg] c: 17773524 0 unused 0 0 # Cyl 0 - 5289* disklabel: warning, partition c: size % cylinder-size != 0 machine$ machine$ disklabel -r sd1 disklabel: no disklabel found. scanning. disklabel: no disk label machine$ machine$ dmesg console is /[EMAIL PROTECTED],4000/[EMAIL PROTECTED]/[EMAIL PROTECTED],40:a Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2005 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 3.7-current (GENERIC) #453: Thu Apr 14 23:32:06 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC total memory = 268435456 avail memory = 235053056 using 1638 buffers containing 13418496 bytes of memory bootpath: /[EMAIL PROTECTED],4000/[EMAIL PROTECTED],0/[EMAIL PROTECTED],0 mainbus0 (root): Sun Ultra 60 UPA/PCI (2 X UltraSPARC-II 296MHz) cpu0 at mainbus0: SUNW,UltraSPARC-II @ 295.998 MHz, version 0 FPU cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 2048K external (64 b/l) psycho0 at mainbus0 addr 0xfffb4000 SUNW,psycho: impl 0, version 4: ign 7c0 bus range 0 to 0; PCI bus 0 STC0 on /mainbus enabled DVMA map: fe00 to e000 IOTDB: a136 to a1368000 pci0 at psycho0 ebus0 at pci0 dev 1 function 0 Sun PCIO Ebus2 rev 0x01 auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003 power at ebus0 addr 724000-724003 not configured SUNW,pll at ebus0 addr 504000-504002 not configured uperf0 at ebus0 addr 50-57: model SUNW,sc-qp (0/1) ports 9 sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2 sabtty0 at sab0 port 0: console i/o sabtty1 at sab0 port 1 comkbd0 at ebus0 addr 3083f8-3083ff ipl 41: no keyboard com0 at ebus0 addr 3062f8-3062ff ipl 42, mouse: ns16550a, 16 byte fifo lpt0 at ebus0 addr 3043bc-3043cb, 300398-300399, 70-7f ipl 34: polled fdthree at ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ipl 39 not configured clock1 at ebus0 addr 0-1fff: mk48t59: hostid 80b3c979 flashprom at ebus0 addr 0-f not configured audioce0 at ebus0 addr 20-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ipl 35 ipl 36: nvaddrs 0 audio0 at audioce0 hme0 at pci0 dev 1 function 1 Sun HME rev 0x01: address 08:00:20:b3:c9:79 qsphy0 at hme0 phy 1: QS6612 10/100 PHY, rev. 1 hme0: using ivec 3021 for interrupt siop0 at pci0 dev 3 function 0 Symbios Logic 53c875 rev 0x14: ivec 20, using 4K of on-board RAM scsibus0 at siop0: 16 targets sd0 at scsibus0 targ 0 lun 0: IBM, DDRS34560SUN4.2G, S98E SCSI2 0/direct fixed sd0: 4094MB, 3882 cyl, 16 head, 135 sec, 512 bytes/sec, 8385121 sec total sd1 at scsibus0 targ 1 lun 0: DEC, RZ2DD-LS (C) DEC, 0306 SCSI2 0/direct fixed sd1: 8678MB, 5273 cyl, 20 head, 168 sec, 512 bytes/sec, 17773524 sec total st0 at scsibus0 targ 3 lun 0: HP, C1537A, L907 SCSI2 1/sequential removable st0: density code 0x25, variable blocks, write-enabled siop1 at pci0 dev 3 function 1 Symbios Logic 53c875 rev 0x14: ivec 26, using 4K of on-board RAM scsibus1 at siop1: 16 targets psycho1 at mainbus0 addr 0xfffc6000 SUNW,psycho: impl 0, version 4: ign 7c0 bus range 128 to 128; PCI bus 128 STC0 on /mainbus enabled STC1 on /mainbus enabled pci1 at psycho1 timer0 at mainbus0 addr 0xfff9fc00 irq vectors 7ec and 7ed creator0 at mainbus0 addr 0xfebc: Elite3D, model SUNW,XXX-, dac 0 wsdisplay0 at creator0 wsdisplay0: screen 0 added (std, sun emulation) pcons at mainbus0 not configured root on sd0a siop0: target 0 now using tagged 16 bit 20.0 MHz 15 REQ/ACK offset xfers rootdev=0x700 rrootdev=0x1100 rawdev=0x1102 siop0: target 1 now using tagged 16 bit 20.0 MHz 15 REQ/ACK offset xfers machine$
Re: SCSI disk from an Alpha box, in a Sparc
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? It is way more complicated than that. The disklabel is at a different place, the filesystems are a different byte order, and there are other issues. You are trying to do something very hard.
