SunOS 4.x boot disk layout
Jules Richardson
julesrichardsonuk at yahoo.co.uk
Sun Mar 27 15:04:31 CST 2005
On Sun, 2005-03-27 at 14:58 -0500, Scott Stevens wrote:
> On Sun, 27 Mar 2005 14:11:14 -0500 (EST)
> der Mouse <mouse at rodents.montreal.qc.ca> wrote:
>
> > > Maybe support under Linux is a little broken (I know already that
> > > ufs/sun makes assumptions about the endian-ness of the filesystem in
> > > some places)
> >
> > Yes, if the filesystem really is a SunOS 4.* filesystem, it will be
> > big-endian. Your Linux FFS support has to be prepared for big-endian
> > data structures on disk, which if you're on a little-endian
> > architecture like i386 it may not be.
> >
>
> I have a question about this that might be answerable by somebody here.
>
> Awhile back I had a drive from an RS/6000 system and was attempting to
> figure it out and get into it.
>
> I decided that I would need to use another big-endian system to copy the
> drive onto an image file to poke around in it. So I mounted the (SCSI)
> drive on a Sparc box here (everybody should have a lunchbox sparc around
> for such purposes) running NetBSD and used the dd command to make an
> image.
>
> Would it have made a difference if I'd used a little-endian system to
> image the drive?
Generally, no. 'dd' just copies raw bytes as it sees them; it knows
nothing of any structure on top of the raw data (such as a filesystem
layout). It's only the code that you may then use to analyse the image
which needs to worry about byte order where necessary.
However, there do seem to be caveats. When I pulled raw data off my NCR
Tower's drive I had to swap bytes before anything made sense, but I
think that's an exception to the rule rather than the norm.
FWIW, 'dd' supports the 'swab' argument to swap adjacent pairs of bytes.
Why it's called swab rather than swap, I don't know - must have been
done that way for a reason...
cheers
Jules
More information about the cctalk
mailing list