Status: Closed (View Workflow)
Resolution: Won't Fix
Affects Version/s: 0.8.0
Fix Version/s: None
Component/s: Meta appliance
Environment:Amazon EC2 32-bit environments, Fedora
Similar Issues:Show 10 results
BGBUILD-95 Use RPM to install boxgrinder-build and plugins on boxgrinder-meta appliance BGBUILD-310 BoxGrinder doesn't build appliances when Fedora 16 is the host BGBUILD-382 Can't boxgrind the boxgrinder-meta appliance from git since yesterday, 18th April 2013 BGBUILD-289 Boxgrinder making broken ec2 amis BGBUILD-53 Install Latest Boxgrinder Gems on Meta Appliance Boot BGBUILD-258 Script for creating meta-appliance releases BGBUILD-201 Creating a meta-appliance for all the EC2 regions BGBUILD-17 when retrying a failed appliance creation boxgrinder bundles an incomplete AMI BGBUILD-231 Cannot register Fedora 15 EC2 AMI with S3 delivery plugin in eu-west-1 availability zone BGBUILD-232 boxgrinder doesn't validate config early enough
There's a severe bug in the chroot environment set up by boxgrinder that affects 32-bit systems running on Amazon EC2, and also under other Xen environments.
Xen requires a special glibc runtime, named nosegneg in order for applications to access thread-local storage efficiently. This is configured in a file named /etc/ld.so.conf.d/libc6-xen.conf with the following contents:
These ld.so config files must also be present in the chroot environment, or the nosegneg version of glibc will not be used. And if those are not used, some applications will be very slow, while others will either crash or go into an infinite loop.
Here is a bug I reported against GHC that turned out to not be a GHC bug - it was really due to GHC not being run with the nosegneg libraries inside boxgrinder's chroot environment: http://hackage.haskell.org/trac/ghc/ticket/4993
That problem was causing my attempt to build a VM image with boxgrinder on 32-bit EC2 to hang forever, and it took me ages to figure out why.
I think there are two parts to fixing this:
- Copy /etc/ld.so.conf and the files in /etc/ld.so.conf.d into the chroot environment. (Actually, the real fix would be to figure out what creates /etc/ld.so.conf.d/libc6-xen.conf and do the exact same thing, but I've not been able to figure out what does that.)
- Run ldconfig in the chroot environment.
Thanks for looking into this. It's a big deal, as it's very hard to understand why an installer gets stuck, and very difficult to work around.