On 10/15/2015 04:39 AM, Johnny Hughes wrote: > On 10/15/2015 04:21 AM, Johnny Hughes wrote: >> On 10/15/2015 03:40 AM, Fabian Arrotin wrote: >>> On 15/10/15 10:29, Johnny Hughes wrote: >>>> On 10/15/2015 02:53 AM, Daniel Veillard wrote: >>>>> On Mon, Aug 31, 2015 at 10:27:56AM -0400, Robert Moskowitz >>>>> wrote: >>>>>> I had to rebuild me image from scratch, so this time, instead >>>>>> of permissive, I decided to set enforcing for selinux. >>>>>> >>>>>> I powered off and powered back on. What ever happened (and I >>>>>> can send the serial console to anyone wanting to review this), >>>>>> the system rebooted and came back around finally to login. >>>>>> Once I logged in, I saw that the ethernet was not available. >>>>>> >>>>>> So I am going to redo this and just leave selinux to disabled >>>>>> until we get further along (and someone else tests it out!). >>>>>> >>>>>> I am running all my systems behind two firewalls and will just >>>>>> have to rely on that for now. >>>>> >>>>> resurecting an old thread, >>>>> >>>>> Hi, >>>>> >>>>> I', curious, What image did you use for the cubie2, you said you >>>>> rebuild those from scratch, that sounds a bit complex but any >>>>> guidelines ? My recollection from fedora is that Cubieboard2 >>>>> differes from Cubietruck only by a few uboot parameters (size, >>>>> location), so do one really need to regenerate the image >>>>> completely ? >>>>> >>>>> thanks, >>>>> >>>>> Daniel >>>>> >>> >>>> DV, >>> >>>> The easy way to do this is to use RBF: >>> >>>> https://github.com/mndar/rbf >>> >>>> It just works :) >>> >>> >>> Afaik, it uses kernel built outside of our env, reason why I asked >>> earlier on the list how we'd be able to proceed to build "official" >>> images ... >>> I don't think we want to use rbf (which I just tested one, and it >>> failed on me) to build official images with artifacts/rpms coming from >>> our builders, but at the same time from unknown sources (aka importing >>> binary packages/kernels) and still call it CentOS image >> >> Well, that totally depends upon the board. >> >> Some boards require special kernels others don't. >> >> The cubuetruck uses our kernel .. and while I have not built one for >> cubieboard2, looking at the xml file, I think it also uses our kernel. >> >> Almost all of the arm32 boards require uboot .. and there is a >> files/cubieboard2/u-boot-sunxi-with-spl.bin. >> >> I am fairly sure that was produced from one of these (mandar can confirm >> which): >> >> http://linux-sunxi.org/U-Boot >> >> http://linux-sunxi.org/Mainline_U-Boot >> >> We spent a lot of time and effort in GSOC 2015 to create RBF to make >> CentOS usable on ARM32. Of course, you can completely redesign it if >> you like. > > Looking at the raspberry pi 2 ... which requires special kernel drivers > (therefore a special kernel), this looks like a Linux-4.1.10 LTS kernel > and the proper rpi2. > > We could compile that kernel ourselves (maybe, obviously we would have > to try it) then use that image, if you prefer for rpi2. > > Using RBF as the tool set to make those happen (via the scripts and xml > files) would be the way to build those images still, after one creates > their own uboot and their own kernels. Sorry .. here is the link: https://github.com/raspberrypi/linux/commits/rpi-4.1.y -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20151015/48157935/attachment-0006.sig>