Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Oct 2013 13:13:47 -0700
From:      Sean Bruno <sean_bruno@yahoo.com>
To:        sbruno@freebsd.org
Cc:        freebsd-fs@freebsd.org
Subject:   [SOLVED?] Re: Endian issues, LE write to BE partitions
Message-ID:  <1380744827.6516.16.camel@localhost>
In-Reply-To: <1380730546.1619.47.camel@localhost>
References:  <1380730546.1619.47.camel@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-1n515Inn0ufD0tsRQbzX
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Wed, 2013-10-02 at 09:15 -0700, Sean Bruno wrote:
> Using makefs from an amd64 host to build a f/s in a VTOC8 partition will
> destroy the entire partition table.  I simplified the test to simple dd
> to an existing partition and got the same result, exonerating mkfs
>=20
> I suspect a lack of endian knowledge in geom itself, not
> geom_part_vtoc8. =20
>=20
> test case:
> 	using amd64 host (10.0 current) create monolothic image
> 		truncate -s+5G /var/tmp/myfile.img
> 		mdconfig -f /var/tmp/myfile.img
>         build and load geom_part_vtoc8 kernel module
> 	use gpart to create VTOC8 part table
> 	add partition to part table to yeild the following:
>=20
> =3D>       0  10442250  md0  VTOC8  (5.0G)
>          0  10442250    1  freebsd-ufs  (5G) =20
>=20
> 	dd to md0a from dev zero for just a bit
> 		dd if=3D/dev/zero of=3D/dev/md0a bs=3D64k count=3D100
>=20
> 	destroy md0 via mdconfig -d -u 0
> 	recreate it with mdconfig -f /var/tmp/myfile.img
>=20
> 	gpart displays no partions for the image any more:
> 		gpart: No such geom: md0.
>=20
> bcc freebsd-geom


Nathan brought me some knowledge.  newfs(8) knows that the first 16
sectors for the first partition are special and not to touch it.
makefs(8) does not.

So, as a proof of concept, I modified makefs to read() the first 16
sectors from the "image" (in my case, /dev/md0a) and throw it away.
(lseek() failed on the partition, so read() was used)

This got me to a bootable SPARC64 image in qemu-system-sparc64, and will
probably allow further booting in other BE architectures.

Is this patch going to break non "device" makefs calls?  e.g. if I want
to create an image file and not use a loopback device?


Index: ffs.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- ffs.c       (revision 255871)
+++ ffs.c       (working copy)
@@ -470,6 +470,7 @@
        char    *buf;
        int     i, bufsize;
        off_t   bufrem;
+       char temp_buf[16*512];
=20
        assert (image !=3D NULL);
        assert (fsopts !=3D NULL);
@@ -480,6 +481,7 @@
                warn("Can't open `%s' for writing", image);
                return (-1);
        }
+       read(fsopts->fd, temp_buf, 16*512);
=20
                /* zero image */
 #if HAVE_STRUCT_STATVFS_F_IOSIZE && HAVE_FSTATVFS


bcc - nwhitehorn, freebsd-geom

--=-1n515Inn0ufD0tsRQbzX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)

iQEcBAABAgAGBQJSTH57AAoJEBkJRdwI6BaHgJsH/jwJnObv/zaBDTXRnwuusSV4
Cj1MSaJOVgEyrguD75FMOCD3IcvXMThzehapdrc8OoWvdFXdufeXskUfS+FTWU8w
BTMir0SVaX1FGN518pXy+PHQpwEi8tfm8VTnspzUqrQwxK6qB/snwdPfO0wd88eS
vy1hXcnKwSugoIrFK5RYMjyXNMIuuFKxDRbxVDOEmpN6JgNeBxwl/RYnrsxQJPme
0y+ZFDZ3Qx7gEs3NjWM80uS2iu8TXst0yoM5mgQqkHkxdQsCximIUq4zQaBtEI5/
Tx7ZoxM3SrP0o9hQBNFEn2EYbfg94NY9uTR/Z9IkEcbd2/ZMcquwFxpKq+23Vcc=
=z2iu
-----END PGP SIGNATURE-----

--=-1n515Inn0ufD0tsRQbzX--




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