On 2015-02-17 18:48, Howard Johnson wrote: > As a long-time Red Hat family distribution user, I've been interested > in a CentOS build for ARM since the release of the originally > Raspberry Pi. However, it's only with the release of RHEL 7 that a > source code base that largely works on ARM has been available to > CentOS [1]. [...] > [1] RHEL6's Fedora 12/13-derived codebase largely predates the Fedora > ARM effort, whereas the Fedora 19 base of RHEL 7 had an actively > maintained ARM secondary architecture; fixes to Fedora packages for > ARM were incorporated into Fedora proper, and RHEL 7 inherited these > fixes. Have you heard of RedSleeve? We've had an EL6 build for armv5tel for years now. All the patches that were required are on the wiki. We have an elpha build of EL7 for armv5tel, bootstrapped via F18, if you would like to take it for a spin, but we haven't touched the branding yet so the release packages aren't available but you should be able to presuade rpm to build a chroot without it using --nodeps. > Fortunately, Fedora 19, which RHEL 7 was forked from, does have a > public (and functional) ARM release. So an EL7 ARM port can be > bootstrapped from the Fedora binary RPMs. It turns out this wasn't quite as critical as it originally seemed. Jacco successfully bootstrapped the first stage armv5tel build of EL7 off F18. > Testing showed that it took the Pi roughly 8m30s to > create a basic F19 mock chroot on the SD card. Trust me, you don't want to do that kind of I/O on an SD card. It will take forever and kill the card in the process. > Of course, even the ODROID wouldn't be able to make mock chroots very > quickly on their SD card, but the built-in gigabit ethernet makes > another option quite sensible: iSCSI. By mounting a block device [8] > from a server over iSCSI, the C1 can create an F19 chroot in about > 2m40s. Having decided the C1 was better for the builder job than the > Pi 2, I borrowed another C1 from my friend, and put an order in for > two more. AFAIK iSCSI and NFS won't work if you need swap (and you probably will need swap for at least some package builds). The kernel has had a long standing issue where it will sometimes try to swap out it's network stack, which will then cause it to be unable to unswap it back because it's been swapped out to a network device. I don't know if that has been fixed recently, but I haven't heard anything about it. Gordan