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.
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
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:
It just works :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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:
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
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
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:
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/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: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:
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/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.
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:
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/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:
I am fairly sure that was produced from one of these (mandar can confirm which):
U-Boot Binaries in {cubietruck,bananapi,cubieboard,cubieboard2,beaglebone,pandaboard} have been cross compiled from the u-boot git repo git://git.denx.de/u-boot.git
-
Daniel Veillard -
Fabian Arrotin -
Johnny Hughes -
Mandar Joshi -
Robert Moskowitz