From owner-freebsd-current@FreeBSD.ORG Sun Jun 9 00:53:52 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 74149ED9; Sun, 9 Jun 2013 00:53:52 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4980C1200; Sun, 9 Jun 2013 00:53:52 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 9270323F848; Sat, 8 Jun 2013 20:53:50 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us 9270323F848 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 8 Jun 2013 20:53:48 -0400 From: Glen Barber To: Hiroki Sato Subject: Re: 10-CURRENT i386 memstick snapshots broken? Message-ID: <20130609005348.GG13292@glenbarber.us> References: <20130607205129.GA1103@jmobile.jimmy.net> <20130607212256.GG38117@glenbarber.us> <20130608173411.GD13292@glenbarber.us> <20130609.050100.598816322573845734.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qoTlaiD+Y2fIM3Ll" Content-Disposition: inline In-Reply-To: <20130609.050100.598816322573845734.hrs@allbsd.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, jimmy.kelley@charter.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 00:53:52 -0000 --qoTlaiD+Y2fIM3Ll Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 09, 2013 at 05:01:00AM +0900, Hiroki Sato wrote: > gj> Because the userland is 32-bit and the kernel is 64-bit, "something" > gj> goes wrong, but interestingly not wrong enough that the script fails > gj> entirely. So, the paritions appear to be created, but in reality, th= ey > gj> are not. > gj> > gj> So, for the snapshots case, the solution is to write the memstick ima= ge > gj> from outside of the chroot environment, which is easy to do because > gj> I already do this for creating the VM disk images (interestingly for = the > gj> same reason as the memstick creation failure). >=20 > I do not think there is a problem with cross building in chroot. cross-building, no, there is no problem. > allbsd.org is also generating i386 snapshots on an amd64 box in > almost the same way as generate-release.sh, but the memstick images > already generated were not broken as far as I can check. Although I > do not use generate-release.sh on it because I added another build > world stage in chroot before cross compiling, the difference is > small. >=20 > What was exactly gone wrong in 32-bit binary on 64-bit kernel? The problem is creating the gpart(8) partition scheme on the md(4) device. Below follows script(1) output of what the make-memstick.sh script does: =20 Script started on Sun Jun 9 00:41:08 2013 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap root@snap:/ # cd /usr/obj/usr/src/release root@snap:/usr/obj/usr/src/release # echo \ '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > release/etc/fstab root@snap:/usr/obj/usr/src/release # makefs -B \ little -o label=3DFreeBSD_Install test.img release Calculated size of `test.img': 649420800 bytes, 12922 inodes Extent size set to 8192 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024 using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111440, 222848, 334256, 445664, 557072, 668480, 779888, 891296, 1002704, 1114112, 1225520, Populating `test.img' Image `test.img' complete root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img md0 =20 All fine up until this point. Now the gpart(8) partition is created: root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0 gpart: Inappropriate ioctl for device root@snap:/usr/obj/usr/src/release # gpart list md0 Segmentation fault (core dumped) I also ran into this when initially creating the 8.4-RELEASE memory stick images, which uses fdisk(8) instead of gpart(8). I basically attributed this to "probably shouldn't be expected to work", such as doing netstat(1) on within 32-bit chroot/jail on a 64-bit kernel. root@snap:/usr/obj/usr/src/release # gdb -c ./gpart.core gpart GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain conditi= ons. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols = found)... Core was generated by `gpart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libgeom.so.5...(no debugging symbols found)...d= one. Loaded symbols for /lib/libgeom.so.5 Reading symbols from /lib/libsbuf.so.6...(no debugging symbols found)...d= one. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /lib/libbsdxml.so.4...(no debugging symbols found)..= =2Edone. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...d= one. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/geom/geom_part.so...(no debugging symbols found= )...done. Loaded symbols for /lib/geom/geom_part.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found).= =2E.done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x28070205 in geom_deletetree () from /lib/libgeom.so.5 (gdb) bt #0 0x28070205 in geom_deletetree () from /lib/libgeom.so.5 #1 0x08049b43 in ?? () #2 0xffffcbf0 in ?? () #3 0x28813050 in ?? () #4 0x0804cb1a in ?? () #5 0x28813030 in ?? () #6 0x0804e63d in __stderrp () #7 0x00000000 in ?? () I can rebuild gpart(8) with debugging symbols enabled tomorrow. The machine is churning through builds at the moment. Glen --qoTlaiD+Y2fIM3Ll Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJRs9IcAAoJEFJPDDeguUajBX0H/A/dc3R7mcnT/mtG2icF+hX+ pLY29H6v9Ois5o8gRl7MkerTse/TStJshp64f7u8FCrCPwB+xkP2MyUMJ/2V7JLg WkFmYiM6M8FdHrak/FQfrHIBe/3RSoIdgYDnZB2LzFjgWDEv5QK+qxZRe5Kv2Tvr 27uAtma3JBlSXiIJ9sfOyEmiXWZMgXNh9TLpO5caBiHT7BJWbQkw8L+eylATWIZV uxZ84R0I6AtulrbYOh32yTpR+Ic5iCz2xP2rRUZIeMVP0n1O+dNuGJo2PGsKtYSV +2wmk2W21gNP1avYTST/FwDcB37dOYlPg+ZyaaiHHt1OoWlxMOhj6e1lOrEnu3A= =1GMu -----END PGP SIGNATURE----- --qoTlaiD+Y2fIM3Ll--