|August 21st, 2014|
Let's say you want to build some 32-bit binaries for distribution but only have a 64-bit OS. You could try to set your build system up to make 32-bit builds, but if your build system is as complicated as ours is that sounds likely to go wrong. What if we just set up a 32-bit chroot? On Debian/Ubuntu this isn't very hard because this is how they generally build packages, and debootstrap and schroot can do most of the work for you. On CentOS/RHEL this is much more annoying, and I can't find anyone out there who has documented how to do this. So I figured I should at least write up what I did, in case someone (or me) later is trying to do the same thing:
# setarch is a command that lets you make uname lie and say it's 32-bit sudo yum install setarch CHROOT_DIR=/var/chroot/centos_i386 sudo mkdir -p $CHROOT_DIR sudo mkdir -p $CHROOT_DIR/var/lib/rpm # If there's a release since 5.10, you should update this url. CENTOS_RPM_URL="http://mirror.centos.org/centos/5/os/i386/CentOS/" CENTOS_RPM_NAME="centos-release-5-10.el5.centos.i386.rpm" wget "$CENTOS_RPM_URL$CENTOS_RPM_NAME" # When running on a 64-bit system, rpm will install 64-bit packages # even if you set $arch and $basearch like you're supposed to. # To force it to install 32-bit packages inside our chroot we have to # change /etc/rpm/platform. While this is changed, don't run any # other system commands or they will get the architecture wrong. I # don't know why rpm doesn't use uname like everything else; then we # could just use setarch. For more details see this discussion. sudo cp /etc/rpm/platform /etc/rpm/platform.real echo i686-redhat-linux | sudo tee /etc/rpm/platform sudo rpm --rebuilddb --root=$CHROOT_DIR sudo rpm --root=$CHROOT_DIR --nodeps -i $CENTOS_RPM_NAME sudo yum --installroot=$CHROOT_DIR/ update sudo yum --installroot=$CHROOT_DIR/ install -y rpm-build yum sudo mv /etc/rpm/platform.real /etc/rpm/platform # The base system is now installed on our chroot, and we've put the # platform file back. # Copying over resolv.conf makes networking work in the chroot. $ sudo cp /etc/resolv.conf $CHROOT_DIR/etc/resolv.conf # If you're setting up a chroot for security purposes, these next # steps are a bad idea. I'm just using chroot for a build environment # so this is fine. The users and groups within the chroot will be the # same as the ones outside, with the same passwords, and sudo will work. $ pushd $CHROOT_DIR/etc $ sudo rm group passwd $ for x in passwd shadow group gshadow hosts sudoers; do sudo ln /etc/$x; done $ popd # These mounts you'll need to do again on every reboot. There's # probably also a way to do this with /etc/fstab. $ sudo mount -t proc proc $CHROOT_DIR/proc $ sudo mount -t sysfs none $CHROOT_DIR/sys $ sudo mount --bind /dev $CHROOT_DIR/dev $ sudo mount -t tmpfs tmpfs $CHROOT_DIR/dev/shm # Enter the chroot! $ sudo setarch i386 /usr/sbin/chroot $CHROOT_DIR/ /bin/bash -l # A few things to do now that we're in our chroot for the first time. # First, delete any rpm database files. Otherwise you'll get errors # about them being corrput. I think this is fine; as far as I can # tell they just get regenerated when they're needed. $ rm /var/lib/rpm/__db.00* # Install sudo, which isn't in the base install. $ yum install sudo # Switch to yourself. $ su yourusername # Now make yourself a homedir and go there: $ sudo mkdir $HOME $ sudo chown $USER $HOME $ cd ~ # Give yourself a prompt that reminds you you're in the chroot. $ echo 'PS1='"'"'(32bit) \u@\h:\w\$ '"'" >> ~/.bashrc # Things are set up now. $ exit # Whenever you want to get back into the chroot, just run: $ sudo setarch i386 /usr/sbin/chroot $CHROOT_DIR/ /bin/bash -l $ su yourusername
- Local Action and Remote Donation
- Instrument Complexity and Automation
- Keeping Choices Donation Neutral
- Is Pandora Really Exploiting Artists?
- Giving vs Doing