[Arm-dev] Cubieboard2 - selinux enforcing fails

[Johnny Hughes]

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.sig>