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 :)

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.

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