Re: 10-CURRENT i386 memstick snapshots broken?

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, 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.

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.
> 
>  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:
 
  Script started on Sun Jun  9 00:41:08 2013
  root_at_snap:/snap/releng # chroot /snap/releng/10-i386-snap
  root_at_snap:/ # cd /usr/obj/usr/src/release
  root_at_snap:/usr/obj/usr/src/release # echo \
    '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > release/etc/fstab
  root_at_snap:/usr/obj/usr/src/release # makefs -B \
    little -o label=FreeBSD_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_at_snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img
  md0
 
All fine up until this point.  Now the gpart(8) partition is created:

  root_at_snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0
  gpart: Inappropriate ioctl for device
  root_at_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_at_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 conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  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)...done.
  Loaded symbols for /lib/libgeom.so.5
  Reading symbols from /lib/libsbuf.so.6...(no debugging symbols found)...done.
  Loaded symbols for /lib/libsbuf.so.6
  Reading symbols from /lib/libbsdxml.so.4...(no debugging symbols found)...done.
  Loaded symbols for /lib/libbsdxml.so.4
  Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done.
  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)...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