Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Jul 2008 21:34:59 +0200 (CEST)
From:      "Didrik Madheden" <didrik@kth.se>
To:        "Miles Nordin" <carton@Ivy.NET>
Cc:        freebsd-sparc64@freebsd.org
Subject:   Re: Sparc64 partitions compatible with PC?
Message-ID:  <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se>
In-Reply-To: <oqbq0w8ipv.fsf@castrovalva.Ivy.NET>
References:  <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> <oqbq0w8ipv.fsf@castrovalva.Ivy.NET>

next in thread | previous in thread | raw e-mail | index | archive | help
A note to Tim: Endianness (Without the dash) is a word. ;)

>>>>>> "dm" == Didrik Madheden <didrik@kth.se> writes:
>
>     dm> I have a Sparc box that I use mainly as an FTP
>     dm> server. (SunBlad 100 if it makes a ny difference) What I want
>     dm> to do now is to move that disk to an x86 box.
>
> backup the disk label to a text file on the sparc box, and move it to
> the PeeCee OOB.
>
> then load the label onto the disk on the peecee.  this writes to the
> disk, and may make it unreadable on both machines because it might go
> wrong, or general compatibility prudery and kludges on the peecee may
> eat up a larger fixed portion at the beginning of the disk making it
> impossible to line up the start of your first filesystem properly.
...
> maybe you should back up the first 1MB of the raw unpartitioned disk
> before you start.  and for the love of god dont make any ``extended''
> MBR partitions on the peecee because this scatters tiny labels all
> over the outer reaches of your disk, so the 1MB backup won't protect
> you.
Could it be that there's some sort of sector offset when reading the disk
on the PC compared to when reading on the Sparc? Doesn't sound logical,
but you never know?
Reason I'm asking is because if possible I'd prefer making the backup on a
PC, since I only have one Sparc installation, and it was a hell to get the
install CD to boot correctly correctly. (As you might remember from about
a year ago)
If I'm not totally mistaken, the backup process is as easy cat /dev/ad0 >
backupfile and then ^C when backupfile is big enough.
Off-topic rant: But something I've been thinking about is that some people
seems to prefer something like dd if=/dev/ad0 of=bakfile even for simple
stream copying, when it could evidently be done just as easily with cat.
Or am I missing something?


>
> It is possible to put plain BSD labels onto FreeBSD/i386 disks:
>
> pizarro:~$ uname -a
> FreeBSD pizarro 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Nov  8 20:23:54
> UTC 2005     carton@cortez:/usr/src/sys/i386/compile/CORTEZ  i386
> pizarro:~$ df -k
> Filesystem 1K-blocks    Used   Avail Capacity  Mounted on
> /dev/ad4a      63214   34552   23606    59%    /
> devfs              1       1       0   100%    /dev
> /dev/ad4e    7615086 2864168 4141712    41%    /usr
> devfs              1       1       0   100%    /usr/var/chroot/named/dev
>
> see how my devices are ad4a instead of ad4s1a?  The missing s1 means
> no MBR label.
>
> this is what you need to do, to make the SMD 'a' slice start in sector
> 0.  (unless you were smart enough not to put your big FTP filesystem
> into the 'a' slice).  The installer won't do this type of raw label,
> even if you set it to Dangerous Mode, so I expect FreeBSD to try to
> resist.  I don't remember how I did it.  definitely ``by hand'' and I
> remember some obstinance.
I did disklabel -e ad0 on the Sparc and got this:

#    size       offset
#    ---------- ----------
  a:   20972448          0
  b:    2097648      41612
  c:   54757584          0
  d:   20972448      20806
  e:  737378208      43693

Size in sector,

Hmm... Do the values

>
>
> or, use Linux.  it ``just works''.  each labeling scheme is a ``kernel
> module''.  You can build all the weird modules on Linux/i386, load
> them all, and read your Sun disklabel using the Sun disklabel
> Interpretation Kernel Module.  It will print a vanity string in dmesg
> when it loads:
>
> Ability to Read Sun Disklabels translation module loaded.  [(c) 1998 by
> darklightw4rriorz@pheerdoom.net]
>
> Then you can download some weird version of fdisk like sunfdisk2-ng or
> something, that's able to write Sun disklabels---this will let you
> edit the label on the disk, then call an ioctl to load the new label
> into the kernel.
>
> BSD has the foundations of a better architecture.  there are ioctls in
> bsd to load the in-core disklabel without touching the on-disk label.
> There are userland programs to read bsd labels, bsd slices, smd
> labels, and mbr labels in BSD, which could be built on non-native
> architectures, to read the label and load it into the kernel without
> touching the disk.  There is a whole geom framework for doing things
> more complicated than simple disklabels.  but in my own experience,
> the right command line flags to do what you want just don't exist.
>





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64373.91.95.8.243.1216323299.squirrel>