0

I have received a HDD. It has single partition with id 42 SFS covering the whole partition. But I am reliably told that it came from Sun Fire XXXX (where XXXX is 15 hundred or thousand or something like that).

Please help me to mount it.

I'm sure that it is not SFS.

Running strings against the device shows loads of files/text etc.

I've tried mounting it as UFS/ZFS/newfs, doesn't work. Tried to run fsck to find the correct magic number, still doesn't work.

I'm thinking that the drive was part of Solaris Volume Manager or Hardware Raid. Any tips on how to verify this and mount the harddrive under solaris?

Dima
  • 305
  • 1
  • 4
  • 17

3 Answers3

4

The Sun-Blade-1500 is a SPARC machine. A Solaris 11 VM (assuming on x86) won't mount a SPARC disk, unless perhaps if it is an EFI disk with ZFS.

Your disk is more likely ufs or vxfs. There is no fdisk partition table on SPARC disks, as they aren't using BIOS. The ID 42 partition is probably just an artifact.

Should you want to try mounting it and assuming you didn't break it with fsck or newfs, you first need to find SPARC hardware, at least if you use Solaris. Linux might be able to read a sun label and mount its big endian ufs although I'm skeptical about it.

jlliagre
  • 8,861
  • 18
  • 36
  • This makes the most sense! doing a whole disk partition 42 is a way to protect disk from erasing data, just because OS cannot read the formatting properly. Thanks. – Dima Jan 20 '12 at 14:19
0

You tried... what? newfs? I would expect it to overwrite your disk, and you don't seem to want that.

42 is more commonly used for "Windows 2000 dynamic extended partition marker" than for Secure Filesystem (SFS). So it can be a dummy partition that really contains Windows "dynamic" disk, with proprietary LDM (or DDM) structure. It may contain Windows volumes, or parts of volumes. I would simply try it on Windows (XP is compatible with these, not sure about Vista/7).

kubanczyk
  • 13,812
  • 5
  • 41
  • 55
  • Why would a Windows dynamic disk have: SUNW, Sun-Blade-1500, /opt/SUN /usr/bin/ksh and etc. And no references to WINDOWS or anything like that. – Dima Jan 17 '12 at 17:50
0

The problem you are facing is that SPARC is Big Endian, while x86 is Little Endian. Back in the days that meant, that Little- and BiG Endian systems save stuff in opposite byte order to disk. With modern filesystems like ZFS that doesn't matter anymore, but what you got is probably UFS (just out of my head). So basically you need another SPARC machine to read that.

juwi
  • 573
  • 1
  • 5
  • 14
  • Put in procurement request for a sparc machine now.... – Dima Jan 18 '12 at 13:31
  • So this is probably solved, then.. – juwi Jan 18 '12 at 22:54
  • The big/little endian mismatch is just a part of the issue and it isn't always a show stopper. For example FAT is little endian and can be mounted on SPARC anyway. The bigger issue is that x86 machines expect disks to have a partition table with up to four primary partitions and a valid checksum there. SPARC machines use a differently written "slice table" with up to 8 (or 16) partitions. – jlliagre Jan 20 '12 at 14:47
  • Sure, but FAT has its endianness clearly defined, whereas UFS in UFA it is not. So basically when mounting FAT on SPARC there is a wrapper in between that needs to take care of byte order, since FAT always is little endian. The vtoc of course, also is a problem. Modern SPARC machines with ZFS use EFI labels, but with UFS volumes EFI isn't well supported. – juwi Jan 21 '12 at 15:39