Hello all. Recently I've been having a bit of fun trying to port CentOS 7 to ARMv7, and I thought I'd share info on what I've been doing with the list.
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]. The announcement and release of the new, faster, quad-core ARMv7-based Raspberry Pi 2 sounded like an ideal reason to have a go at making a CentOS-like RHEL rebuild for ARM, so I ordered a couple of Pi 2s, and started having a think about how I'd go about building EL7.
Having been on the periphery of the CentOS project for quite a while, I knew how CentOS 7 was built: the RHEL 7 sources were rebuilt multiple times; first against the public RHEL 7 beta, then against the results of this build, then against then those results, and so on. Ideally, a similar process could be used to built EL7 for ARM, but of course there has never been a RHEL 7 release for ARM of any sort. 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.
Of course, before I could start rebuilding CentOS sources, I'd need an OS image to rebuild on. Fortunately, the Raspberry Pi's bootloader system is pretty simple: the Pi's firmware looks for specifically named files in the VFAT-formatted first partition of the SD card. The Fedora 19 Minimal image has an ext4 /boot partition which is easily reformatted, and populated with the contents of /boot from the Pi 2 Rasbian image, and the kernel modules to go with the Rasbian-shipped kernel copied to the ext4 / filesystem. A quick (not really) dd of the image to an SD card, and I had a booting Pi 2. The next step was to test out running mock to build Fedora 19 chroots ready to build packages in. Testing showed that it took the Pi roughly 8m30s to create a basic F19 mock chroot on the SD card.
At the same time as starting out working with the Pi 2, a friend pointed me at the ODROID C1 [2], a Pi-like small ARM board. The C1 has a couple of advantages over even the Pi 2: it has a somewhat faster CPU [3], but, more importantly, it has on-SoC gigabit ethernet [4]. The ODROID is designed and manufactured by Hardkernel in South Korea. The ODROID is a bit more expensive (£33 from a UK supplier [5] versus the £25 Pi 2), but still quite affordable. Realising that building RPMs on a Pi on the SD card or over the network would be very slow, I ordered a C1 to try.
I was really rather pleased with the C1 when it arrived. After trying and failing to modify the Fedora 19 ARM Minimal image with an ODROID-specific kernel [6], I ended up grabbing an F21 image made by one of the ODROID forum members [7]. The (one of the) nice thing(s) about building RPMs in mock is that as long as the host OS can run mock, it doesn't really matter what the host OS is, so a Fedora 21 OS for the C1s is fine.
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.
In the meantime, I made a start on building packages using the C1. The sensible starting point was building the C7 versions of the packages that go into the basic mock build chroot. The basic idea here is that the sooner that the set of packages used to build all packages is replaced with the C7 versions, the closer the OS will be to a "true" C7 OS [9]. Once this base set was built, the order of the remaining 1000+ SRPMs is a bit less critical, and more at the mercy of my random whims [10]. I should also note that I'm concentrating on building the CentOS 7 GA package set, not any of the updates. Once I have a C7 GA package set I'm happy with, then I'll look at all the package updates from GA to current.
I was originally planning to knock up a script or two to wrap mock and do createrepo runs. Instead I decided to dust off Plague, the old build system Seth Vidal and co wrote for Fedora Extras. Plague takes care of managing a queue of SRPMs to distribute to multiple builders, running builds, collecting resulting logs and RPMs, and making yum repos. Plague is a tad old, and needed a few code changes to support ARM architectures. It's also a bit... tempremental at times, as the central manager process has issues spotting when builders come and go, but overall it's done quite well.
So what's the current status of the rebuild effort? Of the 2481 SRPMs in CentOS 7.0.1406 (the GA C7 release), 1125 don't need to be rebuilt for ARM, either because they're entirely noarch packages [11], or because they're listed as either "exclusivearch", which means they should only be built on a specific list of architectures [12]. Of the remaining 1356 packages, 943 have been successfully rebuilt, 62 have failed to build, and 351 haven't been attempted yet. Thus far only two RPMs have needed to be modified: centos-release had to be altered to not conflict with the Fedora 19 systemd (both packages contain /usr/lib/systemd/system-preset/90-default.preset), but is now replaced with the stock C7 version, and elfutils has had its test suite disabled [13]. Very much on the positive side, after a 36 hour build, the third build attempt of libreoffice completed successfully [14].
The other thing that's worth saying is that I've not yet looked at any ARM-specific "special" stuff, like an ARM kernel build, or any bootloader support. That's potentially hard stuff, and will take some thinking about [15].
I'm planning to put the various hacky scripts I'm using into a github repo or similar, and I'll be posting status updates in the future with how I get on.
Cheers!
[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.
[2] http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433
[3] Four 1.5GHz cores versus the Pi 2's four 900MHz cores.
[4] Contrasting with the Pi's fast ethernet adapter wired to the onboard USB hub.
[5] http://www.lilliputdirect.com/odroid-c1-quad-core-computer
[6] Not helped by me not having bought a serial cable, so I couldn't watch the bootloader messages.
[7] http://forum.odroid.com/viewtopic.php?f=114&t=8872
[8] SSD backed, using a Samsung EVO 850 SATA SSD.
[9] To the point where it might save an entire OS rebuild cycle, which will be a not inconsiderate amount of effort.
[10] For example, one night I queued up all SRPMs with names starting with "lib"; unfortunately I forgot that that would include libreoffice...
[11] So we can use the C7 builds unmodified.
[12] Packages in this group are generally platform-specific packages like efibootmgr or dmidecode which make no sense on ARMv7 platforms.
[13] Due to a single failing test that wasn't run in the Fedora 19 elfutils build.
[14] The first died when the C1 ran out of RAM, which made me add iSCSI-backed swap to all the builders, while the second ended when I found that the libreoffice build requires more than 16GB of space; on the bright side I found out that the iSCSI LUNs can be resized entirely online.
[15] Apologies for all the footnotes, I like them.
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting point. It has direct installation on a number of cards. You have to dig a bit on the Fedora download site to find them, but they are there.
Or go with F22 beta that is just starting. This has the advantage of a newer uboot and 3.19 kernel; both give better support for a number of boards, including work on the Banana Pi R1 (makes a great router).
F22 can be gotten from http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=...
Now I use the Cubieboards. These have sata, so you can have even better performance and safety than working with an SD card. I have a number running both Redsleeve 6 and Fedora 21. Anything with the Allwinner SoC, you want F22 uboot and kernel to get video support (I am having problems with the usb disconnecting and waiting for a fix on that).
Raspberry Pi 2 work is also being done with F22 (well Rawhide until today when F22 build got approved for beta).
Check out the Fedora-arm list for what has been going on there.
But great to see this post.
On 02/17/2015 01:48 PM, Howard Johnson wrote:
Hello all. Recently I've been having a bit of fun trying to port CentOS 7 to ARMv7, and I thought I'd share info on what I've been doing with the list.
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]. The announcement and release of the new, faster, quad-core ARMv7-based Raspberry Pi 2 sounded like an ideal reason to have a go at making a CentOS-like RHEL rebuild for ARM, so I ordered a couple of Pi 2s, and started having a think about how I'd go about building EL7.
Having been on the periphery of the CentOS project for quite a while, I knew how CentOS 7 was built: the RHEL 7 sources were rebuilt multiple times; first against the public RHEL 7 beta, then against the results of this build, then against then those results, and so on. Ideally, a similar process could be used to built EL7 for ARM, but of course there has never been a RHEL 7 release for ARM of any sort. 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.
Of course, before I could start rebuilding CentOS sources, I'd need an OS image to rebuild on. Fortunately, the Raspberry Pi's bootloader system is pretty simple: the Pi's firmware looks for specifically named files in the VFAT-formatted first partition of the SD card. The Fedora 19 Minimal image has an ext4 /boot partition which is easily reformatted, and populated with the contents of /boot from the Pi 2 Rasbian image, and the kernel modules to go with the Rasbian-shipped kernel copied to the ext4 / filesystem. A quick (not really) dd of the image to an SD card, and I had a booting Pi 2. The next step was to test out running mock to build Fedora 19 chroots ready to build packages in. Testing showed that it took the Pi roughly 8m30s to create a basic F19 mock chroot on the SD card.
At the same time as starting out working with the Pi 2, a friend pointed me at the ODROID C1 [2], a Pi-like small ARM board. The C1 has a couple of advantages over even the Pi 2: it has a somewhat faster CPU [3], but, more importantly, it has on-SoC gigabit ethernet [4]. The ODROID is designed and manufactured by Hardkernel in South Korea. The ODROID is a bit more expensive (£33 from a UK supplier [5] versus the £25 Pi 2), but still quite affordable. Realising that building RPMs on a Pi on the SD card or over the network would be very slow, I ordered a C1 to try.
I was really rather pleased with the C1 when it arrived. After trying and failing to modify the Fedora 19 ARM Minimal image with an ODROID-specific kernel [6], I ended up grabbing an F21 image made by one of the ODROID forum members [7]. The (one of the) nice thing(s) about building RPMs in mock is that as long as the host OS can run mock, it doesn't really matter what the host OS is, so a Fedora 21 OS for the C1s is fine.
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.
In the meantime, I made a start on building packages using the C1. The sensible starting point was building the C7 versions of the packages that go into the basic mock build chroot. The basic idea here is that the sooner that the set of packages used to build all packages is replaced with the C7 versions, the closer the OS will be to a "true" C7 OS [9]. Once this base set was built, the order of the remaining 1000+ SRPMs is a bit less critical, and more at the mercy of my random whims [10]. I should also note that I'm concentrating on building the CentOS 7 GA package set, not any of the updates. Once I have a C7 GA package set I'm happy with, then I'll look at all the package updates from GA to current.
I was originally planning to knock up a script or two to wrap mock and do createrepo runs. Instead I decided to dust off Plague, the old build system Seth Vidal and co wrote for Fedora Extras. Plague takes care of managing a queue of SRPMs to distribute to multiple builders, running builds, collecting resulting logs and RPMs, and making yum repos. Plague is a tad old, and needed a few code changes to support ARM architectures. It's also a bit... tempremental at times, as the central manager process has issues spotting when builders come and go, but overall it's done quite well.
So what's the current status of the rebuild effort? Of the 2481 SRPMs in CentOS 7.0.1406 (the GA C7 release), 1125 don't need to be rebuilt for ARM, either because they're entirely noarch packages [11], or because they're listed as either "exclusivearch", which means they should only be built on a specific list of architectures [12]. Of the remaining 1356 packages, 943 have been successfully rebuilt, 62 have failed to build, and 351 haven't been attempted yet. Thus far only two RPMs have needed to be modified: centos-release had to be altered to not conflict with the Fedora 19 systemd (both packages contain /usr/lib/systemd/system-preset/90-default.preset), but is now replaced with the stock C7 version, and elfutils has had its test suite disabled [13]. Very much on the positive side, after a 36 hour build, the third build attempt of libreoffice completed successfully [14].
The other thing that's worth saying is that I've not yet looked at any ARM-specific "special" stuff, like an ARM kernel build, or any bootloader support. That's potentially hard stuff, and will take some thinking about [15].
I'm planning to put the various hacky scripts I'm using into a github repo or similar, and I'll be posting status updates in the future with how I get on.
Cheers!
[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.
[2] http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433
[3] Four 1.5GHz cores versus the Pi 2's four 900MHz cores.
[4] Contrasting with the Pi's fast ethernet adapter wired to the onboard USB hub.
[5] http://www.lilliputdirect.com/odroid-c1-quad-core-computer
[6] Not helped by me not having bought a serial cable, so I couldn't watch the bootloader messages.
[7] http://forum.odroid.com/viewtopic.php?f=114&t=8872
[8] SSD backed, using a Samsung EVO 850 SATA SSD.
[9] To the point where it might save an entire OS rebuild cycle, which will be a not inconsiderate amount of effort.
[10] For example, one night I queued up all SRPMs with names starting with "lib"; unfortunately I forgot that that would include libreoffice...
[11] So we can use the C7 builds unmodified.
[12] Packages in this group are generally platform-specific packages like efibootmgr or dmidecode which make no sense on ARMv7 platforms.
[13] Due to a single failing test that wasn't run in the Fedora 19 elfutils build.
[14] The first died when the C1 ran out of RAM, which made me add iSCSI-backed swap to all the builders, while the second ended when I found that the libreoffice build requires more than 16GB of space; on the bright side I found out that the iSCSI LUNs can be resized entirely online.
[15] Apologies for all the footnotes, I like them.
On 17/02/15 19:17, Robert Moskowitz wrote:
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting point. It has direct installation on a number of cards. You have to dig a bit on the Fedora download site to find them, but they are there.
the dep tree's on f21 make it harder to map the el7 codebase, we can certainly learn and lean on the work done in the fedora ecosystem around the board support though - and I know lots of folks in that area are keen to help make the CentOS ARM story complete as possible.
On 02/18/2015 09:58 AM, Karanbir Singh wrote:
On 17/02/15 19:17, Robert Moskowitz wrote:
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting point. It has direct installation on a number of cards. You have to dig a bit on the Fedora download site to find them, but they are there.
the dep tree's on f21 make it harder to map the el7 codebase, we can certainly learn and lean on the work done in the fedora ecosystem around the board support though - and I know lots of folks in that area are keen to help make the CentOS ARM story complete as possible.
And it will be harder to support many boards with earlier code bases. It is the uboot and kernel (3.19) that you want, as you know. Until then, you will be doing remixes for each board which will be harder in its own way.
Having some problems with the USB and Cubieboard with the latest Rawhide. Was told it is on the list of many things to figure out and fix. It is that sort of thing that we will need in the end to have broad board support.
On 02/18/2015 03:37 PM, Robert Moskowitz wrote:
On 02/18/2015 09:58 AM, Karanbir Singh wrote:
On 17/02/15 19:17, Robert Moskowitz wrote:
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting point. It has direct installation on a number of cards. You have to dig a bit on the Fedora download site to find them, but they are there.
the dep tree's on f21 make it harder to map the el7 codebase, we can certainly learn and lean on the work done in the fedora ecosystem around the board support though - and I know lots of folks in that area are keen to help make the CentOS ARM story complete as possible.
And it will be harder to support many boards with earlier code bases. It is the uboot and kernel (3.19) that you want, as you know. Until then, you will be doing remixes for each board which will be harder in its own way.
Having some problems with the USB and Cubieboard with the latest Rawhide. Was told it is on the list of many things to figure out and fix. It is that sort of thing that we will need in the end to have broad board support.
step1, get something working
step2, make it work on more than 1 board :)
At the moment, Howard is targetting a 3.18 kernel, I suspect that will change to 3.19 at some point ( or maybe even beyond );
On 02/18/2015 10:41 AM, Karanbir Singh wrote:
On 02/18/2015 03:37 PM, Robert Moskowitz wrote:
On 02/18/2015 09:58 AM, Karanbir Singh wrote:
On 17/02/15 19:17, Robert Moskowitz wrote:
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting point. It has direct installation on a number of cards. You have to dig a bit on the Fedora download site to find them, but they are there.
the dep tree's on f21 make it harder to map the el7 codebase, we can certainly learn and lean on the work done in the fedora ecosystem around the board support though - and I know lots of folks in that area are keen to help make the CentOS ARM story complete as possible.
And it will be harder to support many boards with earlier code bases. It is the uboot and kernel (3.19) that you want, as you know. Until then, you will be doing remixes for each board which will be harder in its own way.
Having some problems with the USB and Cubieboard with the latest Rawhide. Was told it is on the list of many things to figure out and fix. It is that sort of thing that we will need in the end to have broad board support.
step1, get something working
step2, make it work on more than 1 board :)
At the moment, Howard is targetting a 3.18 kernel, I suspect that will change to 3.19 at some point ( or maybe even beyond );
Yah, yah. crawl before walking, and forget about running anytime soon...
Though the 3.18 kernel will match F21 and at least minimal on the Cubies (that is no video support, i.e. headless).
On 18/02/2015 15:41, Karanbir Singh wrote:
At the moment, Howard is targetting a 3.18 kernel, I suspect that will change to 3.19 at some point ( or maybe even beyond );
To be fair I've not looked too closely at the kernel, my (one and only) booting device running my C7 arm packages is using the bootloader / kernel / modules from a recent Rasbian build. I'm still doing the easy-but-time-consuming bit of running mock over SRPMs ;)
On 2015-02-18 15:37, Robert Moskowitz wrote:
On 02/18/2015 09:58 AM, Karanbir Singh wrote:
On 17/02/15 19:17, Robert Moskowitz wrote:
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting point. It has direct installation on a number of cards. You have to dig a bit on the Fedora download site to find them, but they are there.
the dep tree's on f21 make it harder to map the el7 codebase, we can certainly learn and lean on the work done in the fedora ecosystem around the board support though - and I know lots of folks in that area are keen to help make the CentOS ARM story complete as possible.
And it will be harder to support many boards with earlier code bases. It is the uboot and kernel (3.19) that you want, as you know. Until then, you will be doing remixes for each board which will be harder in its own way.
I think it is important to not get hung up on things like kernel versions and boot loaders. The nature of the ARM platform is such that you are inevitably to need more than support for one kernel and boot loader. But IMO that is a relatively minor obstacle to adoption at the moment.
Having some problems with the USB and Cubieboard with the latest Rawhide. Was told it is on the list of many things to figure out and fix. It is that sort of thing that we will need in the end to have broad board support.
If the device ships with a kernel that works, there is nothing at all stopping you from using that kernel to get the EL6 or EL7 userspace up and running on it. There may be ideological reasons why that is bad, but it is not a practical limitation on the ability to use the hardware.
Gordan
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
On 02/17/2015 02:51 PM, Gordan Bobic wrote:
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.
I think this misses the point of doing the build as a CentOS community initiative. I'm actually quite happy to see Howard's post here, as I'm doing a bit of prep to begin a similar build for aarch64 based hardware.
Since Howard's documented a fairly thorough, reproducible, and open procedure in his mail, I would like to support this approach as the 'community standard' way to build, or contribute to the build for armv7h1 within the CentOS community structure.
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.
Ideally, this should stay a CentOS focused community build. This doesn't prevent or preclude RedSleeve or anyone else from doing what they're doing. Collaboration is certainly welcome.
On 2015-02-17 21:44, Jim Perrin wrote:
On 02/17/2015 02:51 PM, Gordan Bobic wrote:
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.
I think this misses the point of doing the build as a CentOS community initiative. I'm actually quite happy to see Howard's post here, as I'm doing a bit of prep to begin a similar build for aarch64 based hardware.
The important point is that until now there seems to have been no public CentOS community initiative on the ARM port.
If it helps things move along, do free to grab a copy of the RSEL7 alpha packages for bootstrapping purposes.
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.
Ideally, this should stay a CentOS focused community build. This doesn't prevent or preclude RedSleeve or anyone else from doing what they're doing. Collaboration is certainly welcome.
Except that thus far there has been talk of different people doing this yet nobody has provided any packages that others can use to help resolve the actual difficult problems (such as packages that require special intervention and patches to build).
In the interest of moving from intangibles to tangibles and avoiding any further duplication of any more effort, here is a link to the preliminary CentOS 7 rebuild for armv5tel:
http://ftp.redsleeve.org/pub/el7/
Credit for this EL7 armv5tel build goes to jacco@redsleeve.org
If you are planing to use it, if you could please grab it from a mirror rather than the primary site that would be appreciated.
Unless you are working on an armv5tel build, I suspect the thing most of interest is likely to be the patches which are included. On the whole, EL7 required much fewer patches to packages than EL6 did.
Gordan
On 17/02/2015 20:51, Gordan Bobic wrote:
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.
I have! I found it a couple of years back when I was looking at OSes for the Pi 1.
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.
Completely agreed.
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.
I've been running the ODROIDs with 4GB of swap each on an iSCSI device since the first (failed) libreoffice build OOMed (as did xulrunner). I've heard mutterings in the past of the risk of deadlocking the kernel for the reason you mentioned, but it seems to be working pretty well so far.
On 17/02/15 20:51, Gordan Bobic wrote:
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.
As I've said to you repeatedly over many years, you are welcome to come join the CentOS effort, on various ARM platforms.
On 2015-02-18 14:57, Karanbir Singh wrote:
On 17/02/15 20:51, Gordan Bobic wrote:
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.
As I've said to you repeatedly over many years, you are welcome to come join the CentOS effort, on various ARM platforms.
I'm here, aren't I? All the heavy lifting for EL6 armv5tel and most of it for EL7 has been done and all the patches have always been published.
Gordan
On 02/18/2015 03:08 PM, Gordan Bobic wrote:
On 2015-02-18 14:57, Karanbir Singh wrote:
On 17/02/15 20:51, Gordan Bobic wrote:
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.
As I've said to you repeatedly over many years, you are welcome to come join the CentOS effort, on various ARM platforms.
I'm here, aren't I? All the heavy lifting for EL6 armv5tel and most of it for EL7 has been done and all the patches have always been published.
Welcome to CentOS Linux on ARM :)
At the moment, the v5 work you guys are doing likely complements the v7 focus were going to try and deliver on from the project side itself.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 18/02/15 16:08, Gordan Bobic wrote:
On 2015-02-18 14:57, Karanbir Singh wrote:
On 17/02/15 20:51, Gordan Bobic wrote:
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.
As I've said to you repeatedly over many years, you are welcome to come join the CentOS effort, on various ARM platforms.
I'm here, aren't I? All the heavy lifting for EL6 armv5tel and most of it for EL7 has been done and all the patches have always been published.
Gordan
<personal interest> that would be cool to see centos 7 working on raspi / arvm5tel : I have two of those and having those running c7 would be interesting :-) </personal interest>
Gordan : have you used f19 or something else to bootstrap the armv5tel build ? I see packages on your ftp site for el5, but no image that can be used on my side as a start.
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 02/18/2015 11:22 AM, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 18/02/15 16:08, Gordan Bobic wrote:
On 2015-02-18 14:57, Karanbir Singh wrote:
On 17/02/15 20:51, Gordan Bobic wrote:
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.
As I've said to you repeatedly over many years, you are welcome to come join the CentOS effort, on various ARM platforms.
I'm here, aren't I? All the heavy lifting for EL6 armv5tel and most of it for EL7 has been done and all the patches have always been published.
Gordan
<personal interest> that would be cool to see centos 7 working on raspi / arvm5tel : I have two of those and having those running c7 would be interesting :-) </personal interest>
Gordan : have you used f19 or something else to bootstrap the armv5tel build ? I see packages on your ftp site for el5, but no image that can be used on my side as a start.
I did this for the Cubieboards and Redsleeve 6. You can see my work at:
http://cdn.opensxce.org/redsleeve/el6/cubieboard2/
I have a number of production systems running with this.
I suspect you can take any F19 remix and use it in a similar method.
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlTkvDgACgkQnVkHo1a+xU6PRQCgjkJakzmBnEOTLFckibRUF8KC GKEAnRx63ux8k67lW8bjiGhWWyjZL9Id =4HLw -----END PGP SIGNATURE----- _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
On 02/18/2015 04:31 PM, Robert Moskowitz wrote:
I did this for the Cubieboards and Redsleeve 6. You can see my work at:
The cubie's should be ARMv7
On 02/18/2015 12:37 PM, Karanbir Singh wrote:
On 02/18/2015 04:31 PM, Robert Moskowitz wrote:
I did this for the Cubieboards and Redsleeve 6. You can see my work at:
The cubie's should be ARMv7
that they are. Allwinner A20s.
I suspect that any F19 remix can be taken and made as a base for RSEL6. Which is valuable and interesting. It will hold me until I have Centos7-arm (I trust).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 18/02/15 19:15, Robert Moskowitz wrote:
On 02/18/2015 12:37 PM, Karanbir Singh wrote:
On 02/18/2015 04:31 PM, Robert Moskowitz wrote:
I did this for the Cubieboards and Redsleeve 6. You can see my work at:
The cubie's should be ARMv7
that they are. Allwinner A20s.
I suspect that any F19 remix can be taken and made as a base for RSEL6. Which is valuable and interesting. It will hold me until I have Centos7-arm (I trust).
Yes, which is why it's now confusing me, as I was talking about Raspi 1, which isn't ARMv7, but (as Redsleeve 6 is, and currently running on one of my raspi1, a mix of armv5tel and armv6l packages)
Don't think that there are F19 images that can be used for Raspi 1
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 02/18/2015 08:25 PM, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 18/02/15 19:15, Robert Moskowitz wrote:
On 02/18/2015 12:37 PM, Karanbir Singh wrote:
On 02/18/2015 04:31 PM, Robert Moskowitz wrote:
I did this for the Cubieboards and Redsleeve 6. You can see my work at:
The cubie's should be ARMv7
that they are. Allwinner A20s.
I suspect that any F19 remix can be taken and made as a base for RSEL6. Which is valuable and interesting. It will hold me until I have Centos7-arm (I trust).
Yes, which is why it's now confusing me, as I was talking about Raspi 1, which isn't ARMv7, but (as Redsleeve 6 is, and currently running on one of my raspi1, a mix of armv5tel and armv6l packages)
Don't think that there are F19 images that can be used for Raspi 1
I do not remember of such a beast either, but this should work for bootstrap purposes:
[root@bug ~]# rpm -qa *release* pidora-release-20-8.rpfr20.noarch raspberrypi-release-notes-0.2-6.rpfr20.noarch
[root@bug ~]# cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) Features : swp half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7
Hardware : BCM2708 Revision : 0010 Serial : 000000008fce93f3
PS: I advise against using the above Pidora version for real "server" tasks. It lacks updates and I will most probably ditch it.
On 2015-02-18 16:22, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 18/02/15 16:08, Gordan Bobic wrote:
On 2015-02-18 14:57, Karanbir Singh wrote:
On 17/02/15 20:51, Gordan Bobic wrote:
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.
As I've said to you repeatedly over many years, you are welcome to come join the CentOS effort, on various ARM platforms.
I'm here, aren't I? All the heavy lifting for EL6 armv5tel and most of it for EL7 has been done and all the patches have always been published.
Gordan
<personal interest> that would be cool to see centos 7 working on raspi / arvm5tel : I have two of those and having those running c7 would be interesting :-) </personal interest>
Gordan : have you used f19 or something else to bootstrap the armv5tel build ? I see packages on your ftp site for el5, but no image that can be used on my side as a start.
I believe Jacco used F18 to bootstrap the build. Not as easy as it would have been with F19, but it worked out.
You can create the image yourself. Take a basic EL7 x86 system (minimal install), grab the list of packages from that using: rpm -qa | sed -e 's/-[0-9].*//' | sort -u > packages.list
You can then feed that to yum: yum --installroot=/path/to/media `cat package.list`
Add a suitable boot loader configuration, kernel, initrd and /lib/modules/ and you should be good to go.
It's not particularly newbie friendly, but it's not very difficult, either.
Gordan
-
Fabian Arrotin -
Gordan Bobic -
Howard Johnson -
Jim Perrin -
Karanbir Singh -
Manuel Wolfshant -
Robert Moskowitz