From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EF0DF138206 for ; Mon, 1 Aug 2016 15:31:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E5DF1E0B86; Mon, 1 Aug 2016 15:31:21 +0000 (UTC) Received: from smarthost01c.mail.zen.net.uk (smarthost01c.mail.zen.net.uk [212.23.1.5]) by pigeon.gentoo.org (Postfix) with ESMTP id AC5E4E0B80 for ; Mon, 1 Aug 2016 15:31:20 +0000 (UTC) Received: from [82.69.80.10] (helo=peak.localnet) by smarthost01c.mail.zen.net.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bUFBX-0004IF-6T for gentoo-user@lists.gentoo.org; Mon, 01 Aug 2016 15:31:19 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] cross-compile attempt Date: Mon, 01 Aug 2016 16:31:18 +0100 Message-ID: <7280559.BLtsgQ0YyM@peak> User-Agent: KMail/4.14.10 (Linux/4.7.0-gentoo; KDE/4.14.22; x86_64; ; ) In-Reply-To: <2788057.PL0PvVn3Vb@dell_xps> References: <1544697.klPk7OG4O7@dell_xps> <3503837.t7NQTNLzTh@dell_xps> <2788057.PL0PvVn3Vb@dell_xps> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-smarthost01c-IP: [82.69.80.10] X-Archives-Salt: 90d69ed0-a795-4b05-b6d8-755db386a7a0 X-Archives-Hash: 831f1cde3a7e6528683d5fbf19903e39 On Monday 01 Aug 2016 14:51:02 Mick wrote: > Given Andrew's steer I had another look and found this guide: > > https://wiki.gentoo.org/wiki/Project:AMD64/32-bit_Chroot_Guide > > Is this approach still valid, or have things moved on since this article > was authored (2012) and different configuration/approach is now > recommended? I use that method to maintain a 32-bit Atom box. I export its /usr/portage via NFS to a chroot on this i7 box and build packages in the chroot. Then I install from packages on the Atom. I'm sure it would be just as easy, or more so, to mount the whole Atom file system and work in it as though I had an i7 processor on the Atom file system. I may try that again. Meanwhile, here's my /etc/init.d/atom script. The mtab I copy in contains enough entries to forestall error messages: $ cat /etc/init.d/atom #!/sbin/openrc-run depend() { need localmount need bootmisc } start() { ebegin "Mounting 32-bit chroot dirs under /mnt/atom" mount -t proc /proc /mnt/atom/proc mount --rbind /dev /mnt/atom/dev mount --rbind /sys /mnt/atom/sys mount --rbind /var/tmp/portage /mnt/atom/var/tmp/portage mount -t nfs 192.168.1.2:/usr/portage/packages /mnt/atom/usr/portage/packages cp /etc/mtab.atom /mnt/atom/etc/mtab eend $? "Error mounting 32-bit chroot directories" } stop() { ebegin "Unmounting 32-bit /mnt/atom chroot dirs" rm /mnt/atom/etc/mtab umount -f /mnt/atom/var/tmp/portage umount -f /mnt/atom/sys/firmware/efi/efivars umount -f /mnt/atom/sys/fs/pstore umount -f /mnt/atom/sys/fs/cgroup/openrc umount -f /mnt/atom/sys/fs/cgroup/cpuset umount -f /mnt/atom/sys/fs/cgroup/cpu umount -f /mnt/atom/sys/fs/cgroup/cpuacct umount -f /mnt/atom/sys/fs/cgroup/freezer umount -f /mnt/atom/sys/fs/cgroup umount -f /mnt/atom/sys/kernel/config umount -f /mnt/atom/sys/kernel/debug umount -f /mnt/atom/dev/pts umount -f /mnt/atom/dev/shm umount -f /mnt/atom/dev/mqueue umount -f /mnt/atom/proc umount -f /mnt/atom/sys umount -f /mnt/atom/dev umount -f /mnt/atom/usr/portage/packages eend $? "Error unmounting 32-bit chroot directories" } Of course I haven't bothered with idiot-proofing it, as I'm the only one here. HTH. -- Rgds Peter