[Arm-dev] Cubieboard2 - selinux enforcing fails

[Johnny Hughes]

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.




-------------- 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/0c786e14/attachment-0001.sig>