From owner-freebsd-current@FreeBSD.ORG Sat Jun 8 20:01:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E2042ED; Sat, 8 Jun 2013 20:01:27 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 2035A11B8; Sat, 8 Jun 2013 20:01:26 +0000 (UTC) Received: from alph.d.allbsd.org (p2175-ipbf701funabasi.chiba.ocn.ne.jp [122.25.209.175]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r58K18EF047608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jun 2013 05:01:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r58K16oM061423; Sun, 9 Jun 2013 05:01:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 09 Jun 2013 05:01:00 +0900 (JST) Message-Id: <20130609.050100.598816322573845734.hrs@allbsd.org> To: gjb@FreeBSD.org Subject: Re: 10-CURRENT i386 memstick snapshots broken? From: Hiroki Sato In-Reply-To: <20130608173411.GD13292@glenbarber.us> References: <20130607205129.GA1103@jmobile.jimmy.net> <20130607212256.GG38117@glenbarber.us> <20130608173411.GD13292@glenbarber.us> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jun__9_05_01_00_2013_556)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 09 Jun 2013 05:01:19 +0900 (JST) X-Spam-Status: No, score=-94.5 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,RCVD_IN_PBL,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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: Sat, 08 Jun 2013 20:01:27 -0000 ----Security_Multipart(Sun_Jun__9_05_01_00_2013_556)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Glen Barber wrote in <20130608173411.GD13292@glenbarber.us>: gj> On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber 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, they gj> are not. gj> gj> So, for the snapshots case, the solution is to write the memstick image 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). I do not think there is a problem with cross building in chroot. 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. What was exactly gone wrong in 32-bit binary on 64-bit kernel? -- Hiroki ----Security_Multipart(Sun_Jun__9_05_01_00_2013_556)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlGzjXwACgkQTyzT2CeTzy3I2wCeN+lHtZfOb2rWYYHoPuQHcUgL YyAAn0irwGX433DrQpNhGuVlam8t8WcB =uDD/ -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun__9_05_01_00_2013_556)----