UFS mount failure - disk slice created on and64, unable to mount on sparc64

John-Mark Gurney jmg at funkthat.com
Sat Oct 17 19:46:41 UTC 2015

Vasile Buruiana wrote this message on Sat, Oct 17, 2015 at 22:38 +0300:
> Yesm I played with a harddisk connected via IDE to the sun and later
> to the laptop via USB-to-IDE adapter. Currently I'm trying to
> buildworkd+buildkernel on the sun using some contents of the /usr/obj
> cross-compiled on the amd-64 laptop to speed up the process (that's
> how I found the problem), so I'm writing these from my memory:
> This happened on the SUN:
> gpart create -s mbr ada0
> gpart add -t freebsd ada0
> gpart create -s bsd ada0s1
> gpart add -s 1G -t freebsd-zfs ada0s1
> newfs -U /dev/ada0s1
> copy stuff, umount, invalid argument while attempting to mount on the laptop.

Expected as the UFS file system is big endian, and tried to mount on
a little endian machine..

> gpart create -s vtoc8 ada0
> gpart add -t freebsd ada0
> gpart create -s bsd da0s1
> gpart add -s 1G -t freebsd-zfs ada0s1
> newfs -U /dev/ada0s1
> copy suff, unmount, again invalid argument while attempting to mount
> on the laptop.


> Same when creating on the laptop and mounting on the sun.
> When moving the harddisk from one unit to the other, at boot (or at
> usb insert) the kernel reports:
> g_dev_taste: make_dev_p() failed (gp->name=da0a, error=17)     or ada0a

Not sure about this.. asking on -current or -stable and -geom might
get you more info on this..

> and many slices appear in /dev:
> da0a
> da0aa
> da0ab
> da0b
> da0c
> da0ca
> da0cb
> (or ada0s1a, ada0s1aa, ada0s1ab, ada0s1b, ada0s1bb, ada0s1c, ada0s1ca
> on the sparc64....)
> and so on, same for mbr/vtoc8, same for bsd/zfs.
> These are some geom-relaed errors as I read on some other mailing
> lists, so I tried to identify the problem by simplifying things until
> I reduced everything to image file attached to md.
> The Sparc also ran a FreeBSD 6.1-release perfectly, the ufs mbr
> partition could be mounted on a x86 for fsck or other maintenance with
> absolutely no problems. Seems that the advances in technology are
> still causing headaches in keeping the things simple.

Hmm...  Are you sure about this?  iirc, there was a utility that you
could run to switch the endianness of a UFS FS, could you have been
using this utility?

> I will try to makefs -B big on the amd64 but I doubt i will also be
> able to mount it on the same machine.

Correct, you will not be able to mount an FS created w/ -B big on the
laptop as it will be the wrong endianness, but it will mount fine on
the sparc64 system...

> On 10/17/15, John-Mark Gurney <jmg at funkthat.com> wrote:
> > Vasile Buruiana wrote this message on Sat, Oct 17, 2015 at 21:32 +0300:
> >> Found a bug in FreeBSD 10.2.
> >> An UFS disk slice created under sparc64 cannot be mounted under amd64.
> >> And reverse:  UFS disk slice created under amd64 cannot be mounted
> >> under sparc64. This also happens with hard disks on both MBR and VTOC8
> >> partition schemes, on both UFS and ZFS filesystems.
> >
> > Sadly, this is due to the fact that sparc64 is big endian, and our UFS
> > implementation isn't bi-endian...  If you need to make a UFS file system
> > on amd64 for use on sparc64, use the makefs utility w/ the option -B big
> > to create it...
> >
> > Just ran into the same issue on an EdgeRouter Lite, which is a big
> > endian MIPS64 machine...
> >
> > Though I'm a bit surprized that it happens w/ ZFS as ZFS is suppose
> > to support either endianness automaticly..  Did you try this on raw
> > disks?

  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

More information about the freebsd-sparc64 mailing list