Use Sparc HD in Linux PC?

Applications UNIX Desktop Questions & Answers
1

My Sparc 10 is not working and I would like to get some data file from it. Can I use Sparc HD as an external HD to a linux PC? If I do, dies linux PC will recognize this HD and not ask to format it?

Thanks a lot.

:confused:

2

As long as you have the right kind of controller (SCSI? IDE?) and cables to plug it in, go ahead and try. No PC that I know of just formats a hard drive because you connected it... you have to tell it to do so.

Linux should recognise the Sun label on the disk and allow you to mount and read them as long as your kernel has the required modules and utilities to support mounting UFS filesystems (I'm guessing that's what you used on your SPARC).

3

You might have "fun" with the data having been stored in big endian and little endian format (Sparc vs. Intel), so if once you have mounted the disk the file names and or file contents look scrambled then that could be why.

See: Endianness - Wikipedia, the free encyclopedia and Dr. Bill's Notes on "Little Endian" vs. "Big Endian".

The problem can be resolved with some C code though.

4

I strongly doubt about it.
Linux expects hard disks to have a MBR and is only able to mount low endian UFS in slices layed out in a Solaris primary partition.
SPARC (as already stated) use big endian UFS and don't use the extra layer of primary partitions.

5

Strange to ressurrect such an old thread that the OP seems to have disappeared from anyway...

Linux does not expect an MBR. In fact, by default, when you initialise disks for use by Veritas Volume Manager, it uses Sun disk labels (which surprised me), e.g.

Disk /dev/sdb8 (Sun disk label): 30 heads, 128 sectors, 55508 cylinders
Units = cylinders of 3840 * 512 bytes

    Device Flag    Start       End    Blocks   Id  System
/dev/sdb8p3  u          0     55508 106575360    5  Whole disk
/dev/sdb8p8  u          0     55508 106575360    f  Unknown

The endianness of the data on the filesystem is only an issue if you are trying to read it programmatically (i.e. reading multiple byte values), and can be fixed programmatically if desired... however ASCII will still be in the correct order.

6

I stand corrected. Thanks for the information.