Date: Sat, 8 Jun 2013 20:53:48 -0400 From: Glen Barber <gjb@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, jimmy.kelley@charter.net Subject: Re: 10-CURRENT i386 memstick snapshots broken? Message-ID: <20130609005348.GG13292@glenbarber.us> In-Reply-To: <20130609.050100.598816322573845734.hrs@allbsd.org> References: <20130607205129.GA1103@jmobile.jimmy.net> <20130607212256.GG38117@glenbarber.us> <20130608173411.GD13292@glenbarber.us> <20130609.050100.598816322573845734.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130609005348.GG13292>