-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
It seems we have now reach the point where enough packages are built to start looking at producing a working minimal setup. (with the c7-buildroot and c7-pass-1 repos) Who does take that in charge, and document it ?
Cheers,
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
On June 1, 2015 11:24:09 AM CDT, Fabian Arrotin arrfab@centos.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
It seems we have now reach the point where enough packages are built to start looking at producing a working minimal setup. (with the c7-buildroot and c7-pass-1 repos) Who does take that in charge, and document it ?
Cheers,
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlVshykACgkQnVkHo1a+xU5YtACfYOFWMIuJgBnrKSAOx2mjKCo/ /z4AnjRshY3xIHGQIhJcruiXsbs+1Dcj =TBOb -----END PGP SIGNATURE----- _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/06/15 03:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
Well, I don't know but it would be good if Mandar (GSoC student) and Ian (his Mentor) could participate and give their opinions/status about the current work. Also, let's keep in mind that we'd have to think about how to start from zero (so not using existing image in which we'd modify something). That can work for initial testing images, but we have to produce final images from scratch.
Cheers, - --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 2015-06-02 09:33, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/06/15 03:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
It is that easy.
A more interesting question is what packages to include. The base image would, presumably, contain what anaconda would install on a minimal install. In reality, however, I think it would be useful to include at least NetworkManager-tui if not Xorg and KDE/Gnome to make it easier to connect to the network and yum install anything else required.
There is also the question of what FS to use. If the kernel sources are available and the appropriate kernel rpm can be built, I would suggest default should be XFS, same as on x86. On RedSleeve I'm currently working on rootfs images with zfs-fuse (over the past few years I've learned to no longer trust anything other than ZFS with any data that takes more than a couple of hours to restore from backups).
Well, I don't know but it would be good if Mandar (GSoC student) and Ian (his Mentor) could participate and give their opinions/status about the current work. Also, let's keep in mind that we'd have to think about how to start from zero (so not using existing image in which we'd modify something).
In general you can use an x86 machine to yum install ARM packages into a chroot. If there are %pre or %post scripts they will fail, but it should still be good enough to build a base image for bootstrapping more images.
That can work for initial testing images, but we have to produce final images from scratch.
I don't see what the problem is. You can yum install into a clean chroot directory, then copy that onto a loopback mounted clean image directory (make sure to preserve the xattrs/caps!).
Gordan
Well, I don't know but it would be good if Mandar (GSoC student) and Ian (his Mentor) could participate and give their opinions/status about the current work.
Sorry guys, I've been a silent observer in this discussion. My exams are going on. They end tomorrow.
Please give me a day or two to discuss with Ian give you an update about the GSoC Project.
If you would like to see the original GSoC proposal with my ideas, its available on Github https://github.com/mndar/gsoc2015. Some of the things described in it might change.
Regards Mandar Joshi
On 2015-06-02 02:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
On the subject of images, it also occurs to me that it would make sense to standardise the image contents between CentOS and RedSleeve to keep them at least similar if not 100% identical.
Gordan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/06/15 11:07, Gordan Bobic wrote:
On 2015-06-02 02:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
On the subject of images, it also occurs to me that it would make sense to standardise the image contents between CentOS and RedSleeve to keep them at least similar if not 100% identical.
Gordan
That's a good idea, so we can discuss that. My idea was to have "minimal" reflecting what we have for x86_64 (and i686 now in beta !) for CentOS 7, so reusing the comps.xml and installing @core. I've quickly done a test yesterday , and built an initial test image through appliance-creator (thanks Howard for the pointer !) but without "cleaning up" the comps.xml so it installed some firwmare (noarch) files that aren't needed at all on the arm platform.
It needed 706Mb on / (normal for @core), but we can reduce that.
I've only tested that image through qemu-system-arm and here are the results :
uname -a ; rpm -q centos-release ; cat /proc/cpuinfo Linux localhost 3.18.7-200.el7.0.1.armv7hl #1 SMP Tue Jun 2 10:18:14 UTC 2015 armv7l armv7l armv7l GNU/Linux centos-release-7-1.1503.el7.centos.2.7.armv7hl processor : 0 model name : ARMv7 Processor rev 0 (v7l) BogoMIPS : 695.09 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc09 CPU revision : 0
Hardware : ARM-Versatile Express Revision : 0000 Serial : 0000000000000000
Now if someone can have a look at the required bits for various boards (my time is very limited actually, so just spending some "free" time on armv7hl at the moment)
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 2015-06-03 07:55, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/06/15 11:07, Gordan Bobic wrote:
On 2015-06-02 02:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
On the subject of images, it also occurs to me that it would make sense to standardise the image contents between CentOS and RedSleeve to keep them at least similar if not 100% identical.
Gordan
That's a good idea, so we can discuss that. My idea was to have "minimal" reflecting what we have for x86_64 (and i686 now in beta !)
Good to hear you guys got there with the i686 build in the end. I'd been using the Scientific Linux i686 port as a base to build my own, but the main reason I've needed it for is WINE builds and the odd Steam and Optimus/Bumblebee dependency, so once I had a complete mock chroot build set for those I didn't bother with completing the package build.
for CentOS 7, so reusing the comps.xml and installing @core. I've quickly done a test yesterday , and built an initial test image through appliance-creator (thanks Howard for the pointer !) but without "cleaning up" the comps.xml so it installed some firwmare (noarch) files that aren't needed at all on the arm platform.
Do you have a link handy to a copy of the CentOS 7 (and CentOS 6 for that matter) comps.xml file?
It needed 706Mb on / (normal for @core), but we can reduce that.
I am not even sure it is worth wasting too much time trying to skim that down a bit. I find that having a few extra things is really quite handy, and helps greatly to get up and running quickly.
I've only tested that image through qemu-system-arm and here are the results :
uname -a ; rpm -q centos-release ; cat /proc/cpuinfo Linux localhost 3.18.7-200.el7.0.1.armv7hl #1 SMP Tue Jun 2 10:18:14 UTC 2015 armv7l armv7l armv7l GNU/Linux centos-release-7-1.1503.el7.centos.2.7.armv7hl processor : 0 model name : ARMv7 Processor rev 0 (v7l) BogoMIPS : 695.09 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc09 CPU revision : 0
Hardware : ARM-Versatile Express Revision : 0000 Serial : 0000000000000000
Now if someone can have a look at the required bits for various boards (my time is very limited actually, so just spending some "free" time on armv7hl at the moment)
I'm not sure what your plans are for CentOS, but given the sheer volume of various hardware, I don't think it is reasonable for the core project to try to cover everything. My experience with RedSleeve is that most people are using R-Pi (1 and 2), Odroid, Cubies and CuBox-es - which interestingly means next to no overlap with my own hardware so I can't support it. I mostly use Kirkwood devices (*Plug, QNAP NAS), Tegra2 (Toshiba AC100) and Chromebook (Exynos) machines, I was donated a CuBox to get an image built for it, and other than that I have a few relatively obscure machines that I have on the shelf that I have not yet had a chance to even look at getting up and running yet, and since I got them the manufacturers of some of them appear to have gone out of business. :(
The point I'm getting to is that some engagement from the community is likely to be necessary for such things, purely because to support the hardware you have to have the hardware, and without a substantial toy and manpower budget it will almost certainly have to fall to the community members to figure out and support anything but the most widely used hardware.
This is also made more difficult by the fact that even when the sources are available, the kernels in use are massively heavily patched, and pretty ancient. Ignoring the issue of bugs and security with such ancient kernels, it is still a case of having to have a separate specific kernel build for many devices, some of which require various additional bodges to make them work. For example, on the Exynos Chromebook, the kernel firmware loader isn't quite up to the task of loading the firmwares itself, which means much of the hardware won't work with the 3.4 kernel built from sources in the usual way. The only workaround that makes it work with systemd is to glue the firmware blobs into the kernel itself. Getting to a fully working system took me most of the last weekend, and from experience much ARM hardware is like that. And that is a LOT of man-days to spend on an unfunded project to support a wide range of hardware.
Gordan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/06/15 11:36, Gordan Bobic wrote:
On 2015-06-03 07:55, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/06/15 11:07, Gordan Bobic wrote:
On 2015-06-02 02:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
On the subject of images, it also occurs to me that it would make sense to standardise the image contents between CentOS and RedSleeve to keep them at least similar if not 100% identical.
Gordan
That's a good idea, so we can discuss that. My idea was to have "minimal" reflecting what we have for x86_64 (and i686 now in beta !)
Good to hear you guys got there with the i686 build in the end. I'd been using the Scientific Linux i686 port as a base to build my own, but the main reason I've needed it for is WINE builds and the odd Steam and Optimus/Bumblebee dependency, so once I had a complete mock chroot build set for those I didn't bother with completing the package build.
I've myself built wine i686 for CentOS 7 (for family members) in July last year, just pointing mock to the public repositories (having i{3,6}86 packages) on http://buildlogs.centos.org :-)
for CentOS 7, so reusing the comps.xml and installing @core. I've quickly done a test yesterday , and built an initial test image through appliance-creator (thanks Howard for the pointer !) but without "cleaning up" the comps.xml so it installed some firwmare (noarch) files that aren't needed at all on the arm platform.
Do you have a link handy to a copy of the CentOS 7 (and CentOS 6 for that matter) comps.xml file?
Well, not sure to understand the question, as the comps is in the distro itself, and so directly in the mirror tree (like http://mirror.centos.org/centos-7/7/os/x86_64/repodata/175ddec2056ec6b5ef267...)
But we also have that in a git repo, including some of the tools used to merge/produce those and sanitize the xml output (https://git.centos.org/summary/?r=sig-core/comps.git)
It needed 706Mb on / (normal for @core), but we can reduce that.
I am not even sure it is worth wasting too much time trying to skim that down a bit. I find that having a few extra things is really quite handy, and helps greatly to get up and running quickly.
<snip>
I'm not sure what your plans are for CentOS, but given the sheer volume of various hardware, I don't think it is reasonable for the core project to try to cover everything. My experience with RedSleeve is that most people are using R-Pi (1 and 2), Odroid, Cubies and CuBox-es - which interestingly means next to no overlap with my own hardware so I can't support it. I mostly use Kirkwood devices (*Plug, QNAP NAS), Tegra2 (Toshiba AC100) and Chromebook (Exynos) machines, I was donated a CuBox to get an image built for it, and other than that I have a few relatively obscure machines that I have on the shelf that I have not yet had a chance to even look at getting up and running yet, and since I got them the manufacturers of some of them appear to have gone out of business. :(
Yeah .. the beauty of "Secondary Arch" is that there is no real plan nor "things written in stone", so we can discuss and implement slowly what we want :-)
The point I'm getting to is that some engagement from the community is likely to be necessary for such things, purely because to support the hardware you have to have the hardware, and without a substantial toy and manpower budget it will almost certainly have to fall to the community members to figure out and support anything but the most widely used hardware.
Yes, so community interested into having it working would need to work on it and we can centralize all the needed steps for automated builds for those images.
This is also made more difficult by the fact that even when the sources are available, the kernels in use are massively heavily patched, and pretty ancient. Ignoring the issue of bugs and security with such ancient kernels, it is still a case of having to have a separate specific kernel build for many devices, some of which require various additional bodges to make them work. For example, on the Exynos Chromebook, the kernel firmware loader isn't quite up to the task of loading the firmwares itself, which means much of the hardware won't work with the 3.4 kernel built from sources in the usual way. The only workaround that makes it work with systemd is to glue the firmware blobs into the kernel itself. Getting to a fully working system took me most of the last weekend, and from experience much ARM hardware is like that. And that is a LOT of man-days to spend on an unfunded project to support a wide range of hardware.
Gordan
Indeed, the kernel part will be the most obscure / more difficult part to do. Probably good to at least centralize the doc around various boards, and start from that experience. As you said, I was expecting more people to be interested in raspi2/odroid/bananapi/cubie
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
Used a 1gb usb card, formatted to xfs and mounted to /mnt/rootfs
$ mkdir -p /mnt/rootfs/var/lib/rpm
$ rpm --root /mnt/rootfs --initdb
$ yumdownloader --destdir=/var/tmp centos-release
$ cd /var/tmp
$ rpm --root /mnt/rootfs -ivh --nodeps centos-release*rpm
$ cp /etc/yum.repos.d/pass1.repo /mnt/rootfs/etc/yum.repos.d/
$ cp /etc/yum.repos.d/buildroot.repo /mnt/rootfs/etc/yum.repos.d/
$ yum --installroot=/mnt/rootfs -y groupinstall @core
Now, this was only a test. As I did not make a boot partition (though the raspi needs special stuff on the /boot partition and has to be fat32).
In order to actually try the image, i need to make a /boot partition on an sdcard, dd this usb stick onto a / partition, mount it, change the /etc/fstab, load the raspi firmware/kernel/config/cmdline, and it should in theory boot.
Thoughts on this method? It appears to have installed everything and built the database fine as I can chroot into it and everything seems to work.
On June 3, 2015 4:36:03 AM CDT, Gordan Bobic gordan@redsleeve.org wrote:
On 2015-06-03 07:55, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/06/15 11:07, Gordan Bobic wrote:
On 2015-06-02 02:23, cc35359@gmail.com wrote:
I just read about the Google summer of code project in regards to repacking/customizing arm 32 images, how does that effect what we are looking to accomplish? I don't mind assisting in the rootfs build (the right way), but I've never tried it in my 20 years of nix :-). I'm wondering if I use my pi image, chroot into a new pqrtition and do the installs in that? That sounds easy, but not sure if it is that easy.
On the subject of images, it also occurs to me that it would make sense to standardise the image contents between CentOS and RedSleeve to keep them at least similar if not 100% identical.
Gordan
That's a good idea, so we can discuss that. My idea was to have "minimal" reflecting what we have for x86_64 (and i686 now in beta !)
Good to hear you guys got there with the i686 build in the end. I'd been using the Scientific Linux i686 port as a base to build my own, but the main reason I've needed it for is WINE builds and the odd Steam and Optimus/Bumblebee dependency, so once I had a complete mock chroot build set for those I didn't bother with completing the package build.
for CentOS 7, so reusing the comps.xml and installing @core. I've quickly done a test yesterday , and built an initial test image through appliance-creator (thanks Howard for the pointer !) but without "cleaning up" the comps.xml so it installed some firwmare (noarch) files that aren't needed at all on the arm platform.
Do you have a link handy to a copy of the CentOS 7 (and CentOS 6 for that matter) comps.xml file?
It needed 706Mb on / (normal for @core), but we can reduce that.
I am not even sure it is worth wasting too much time trying to skim that down a bit. I find that having a few extra things is really quite handy, and helps greatly to get up and running quickly.
I've only tested that image through qemu-system-arm and here are the results :
uname -a ; rpm -q centos-release ; cat /proc/cpuinfo Linux localhost 3.18.7-200.el7.0.1.armv7hl #1 SMP Tue Jun 2 10:18:14 UTC 2015 armv7l armv7l armv7l GNU/Linux centos-release-7-1.1503.el7.centos.2.7.armv7hl processor : 0 model name : ARMv7 Processor rev 0 (v7l) BogoMIPS : 695.09 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc09 CPU revision : 0
Hardware : ARM-Versatile Express Revision : 0000 Serial : 0000000000000000
Now if someone can have a look at the required bits for various
boards
(my time is very limited actually, so just spending some "free" time on armv7hl at the moment)
I'm not sure what your plans are for CentOS, but given the sheer volume of various hardware, I don't think it is reasonable for the core project to try to cover everything. My experience with RedSleeve is that most people are using R-Pi (1 and 2), Odroid, Cubies and CuBox-es - which interestingly means next to no overlap with my own hardware so I can't support it. I mostly use Kirkwood devices (*Plug, QNAP NAS), Tegra2 (Toshiba AC100) and Chromebook (Exynos) machines, I was donated a CuBox to get an image built for it, and other than that I have a few relatively obscure machines that I have on the shelf that I have not yet had a chance to even look at getting up and running yet, and since I got them the manufacturers of some of them appear to have gone out of business. :(
The point I'm getting to is that some engagement from the community is likely to be necessary for such things, purely because to support the hardware you have to have the hardware, and without a substantial toy and manpower budget it will almost certainly have to fall to the community members to figure out and support anything but the most widely used hardware.
This is also made more difficult by the fact that even when the sources are available, the kernels in use are massively heavily patched, and pretty ancient. Ignoring the issue of bugs and security with such ancient kernels, it is still a case of having to have a separate specific kernel build for many devices, some of which require various additional bodges
to make them work. For example, on the Exynos Chromebook, the kernel firmware loader isn't quite up to the task of loading the firmwares itself, which means much of the hardware won't work with the 3.4 kernel built from sources in the usual way. The only workaround that makes it work with systemd is to glue the firmware blobs into the kernel itself. Getting to a fully working system took me most of the last weekend, and from experience much ARM hardware is like that. And that is a LOT of man-days to spend on an unfunded project to support a wide range of hardware.
Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
$ yum --installroot=/mnt/rootfs -y groupinstall @core
I am not able to get this to work. It works with the F21 Repos but not with the CentOS ones. I get a warning "Warning: group core does not exist"
Here is the output http://pastebin.com/WXxMZuVj --------------------------------------------------------------------------------------------------------------------------------------------------- # cat /disks/temp/etc/yum.repos.d/c7buildroot.repo [c7buildroot] name=c7buildroot baseurl=http://armv7.dev.centos.org/repodir/c7-buildroot/ #baseurl=ftp://192.168.1.3/c7buildroot gpgcheck=0 enabled=1
# cat /disks/temp/etc/yum.repos.d/c7pass1.repo [c7pass1] name=c7pass1 baseurl=http://armv7.dev.centos.org/repodir/c7-pass-1/ #baseurl=ftp://192.168.1.3/c7pass1/ gpgcheck=0 enabled=1
# yum --installroot=/disks/temp/ groupinstall @core There is no installed groups file. Maybe run: yum groups mark convert (see man yum) c7buildroot | 2.9 kB 00:00 c7pass1 | 2.9 kB 00:00 (1/2): c7buildroot/primary_db | 2.3 MB 00:05 (2/2): c7pass1/primary_db | 2.8 MB 00:09 Warning: group core does not exist. Maybe run: yum groups mark install (see man yum) Error: No packages in any requested group available to install or update
---------------------------------------------------------------------------------------------------------------------------------------------------
Any ideas? What am I missing?
I shorthanded it to post, as the group didn't exist yet. Otherwise I would have filled the email with a boatload of yums. Yum install yum, yum install systemd, yum install blah blah blah. Maybe even yum install * :) Or you can try yum distro-sync, I didnt try that.
My point was simply to show that that method worked so far. I was just ensuring that it installed and was working. Yum groups will be made eventually i assume. I did it just to test using that method to build an image. Though i used a USB stick, you could also use dd to create a file whatever size you want and that will be your image
On June 5, 2015 6:50:22 PM CDT, Mandar Joshi emailmandar@gmail.com wrote:
$ yum --installroot=/mnt/rootfs -y groupinstall @core
I am not able to get this to work. It works with the F21 Repos but not with the CentOS ones. I get a warning "Warning: group core does not exist"
Here is the output http://pastebin.com/WXxMZuVj
# cat /disks/temp/etc/yum.repos.d/c7buildroot.repo [c7buildroot] name=c7buildroot baseurl=http://armv7.dev.centos.org/repodir/c7-buildroot/ #baseurl=ftp://192.168.1.3/c7buildroot gpgcheck=0 enabled=1
# cat /disks/temp/etc/yum.repos.d/c7pass1.repo [c7pass1] name=c7pass1 baseurl=http://armv7.dev.centos.org/repodir/c7-pass-1/ #baseurl=ftp://192.168.1.3/c7pass1/ gpgcheck=0 enabled=1
# yum --installroot=/disks/temp/ groupinstall @core There is no installed groups file. Maybe run: yum groups mark convert (see man yum) c7buildroot | 2.9 kB 00:00 c7pass1 | 2.9 kB 00:00 (1/2): c7buildroot/primary_db | 2.3 MB 00:05 (2/2): c7pass1/primary_db | 2.8 MB 00:09 Warning: group core does not exist. Maybe run: yum groups mark install (see man yum) Error: No packages in any requested group available to install or update
Any ideas? What am I missing? _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/06/15 01:50, Mandar Joshi wrote:
$ yum --installroot=/mnt/rootfs -y groupinstall @core
I am not able to get this to work. It works with the F21 Repos but not with the CentOS ones. I get a warning "Warning: group core does not exist"
Here is the output http://pastebin.com/WXxMZuVj
# cat /disks/temp/etc/yum.repos.d/c7buildroot.repo
[c7buildroot] name=c7buildroot baseurl=http://armv7.dev.centos.org/repodir/c7-buildroot/ #baseurl=ftp://192.168.1.3/c7buildroot gpgcheck=0 enabled=1
# cat /disks/temp/etc/yum.repos.d/c7pass1.repo [c7pass1] name=c7pass1 baseurl=http://armv7.dev.centos.org/repodir/c7-pass-1/ #baseurl=ftp://192.168.1.3/c7pass1/ gpgcheck=0 enabled=1
# yum --installroot=/disks/temp/ groupinstall @core There is no installed groups file. Maybe run: yum groups mark convert (see man yum) c7buildroot | 2.9 kB 00:00 c7pass1 | 2.9 kB 00:00 (1/2): c7buildroot/primary_db | 2.3 MB 00:05 (2/2): c7pass1/primary_db | 2.8 MB 00:09 Warning: group core does not exist. Maybe run: yum groups mark install (see man yum) Error: No packages in any requested group available to install or update
Any ideas? What am I missing?
The two repositories you are pointing yum at are only "raw" trees with rpms/srpms so I created an empty comps repository containing the comps.xml file and repodata needed around it (for my first test with appliance-creator some days ago) :
http://armv7.dev.centos.org/repodir/comps/
Cheers, - --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
The two repositories you are pointing yum at are only "raw" trees with rpms/srpms so I created an empty comps repository containing the comps.xml file and repodata needed around it (for my first test with appliance-creator some days ago) :
Thanks. That worked. I am facing one problem though I did
yum --installroot=/tmp/temp install kernel
but there is no initramfs in /tmp/temp/boot Any idea what might be going wrong?
You'll have to run dracut yourself to build one, as far as I am aware, I'm used to a raspi which needs to use binary firmware, and the generic kernel doesn't work as well as the one compiled by the raspi foundation
On June 6, 2015 11:50:26 AM CDT, Mandar Joshi emailmandar@gmail.com wrote:
The two repositories you are pointing yum at are only "raw" trees
with
rpms/srpms so I created an empty comps repository containing the comps.xml file and repodata needed around it (for my first test with appliance-creator some days ago) :
Thanks. That worked. I am facing one problem though I did
yum --installroot=/tmp/temp install kernel
but there is no initramfs in /tmp/temp/boot Any idea what might be going wrong? _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
You'll have to run dracut yourself to build one, as far as I am aware, I'm used to a raspi which needs to use binary firmware, and the generic kernel doesn't work as well as the one compiled by the raspi foundation
cc35359, Running dracut manually did the trick. I am able to use CentOS7 stock kernel on my Cubietruck3.
Gordan, I am using the kernel that is available in the CentOS Repo vmlinuz-4.0.0-1.el7.armv7hl
Ok, so the next task I created a disk image using dd and installed @core and kernel. This works on the Cubietruck3. I tried to boot the same image with qemu using this script http://pwhalen.fedorapeople.org/Fedora/20/boot-vexpress . I got the CentOS login prompt using the F22 kernel and initramfs. http://pastebin.com/mHBazwU4
The CentOS kernel and initramfs however is not able to find the root partition . It waits forever, gets stuck here http://pastebin.com/EUeBvcKD
Does anyone have a working CentOS initramfs and kernel for qemu?
The CentOS kernel and initramfs however is not able to find the root partition . It waits forever, gets stuck here http://pastebin.com/EUeBvcKD
Eventually it dropped to the emergency shell with an warning saying "Warning: /dev/mmcblk0p3 does not exist". Here are the boot messages http://pastebin.com/VdRYNxAW
The mmc_block kernel module is present. I am wondering why the kernel and initramfs works on the Cubietruck3 but not in Qemu. Any suggestions?
Thanks Mandar Joshi
Does qemu name the device and partitions differently? Perhaps it gives it a /dev/sdx name? Such as my pi uses /dev/mmcblk0, but the SD card in my x86_64 will show up as /dev/sdb
On June 6, 2015 7:36:57 PM CDT, Mandar Joshi emailmandar@gmail.com wrote:
The CentOS kernel and initramfs however is not able to find the root partition . It waits forever, gets stuck here http://pastebin.com/EUeBvcKD
Eventually it dropped to the emergency shell with an warning saying "Warning: /dev/mmcblk0p3 does not exist". Here are the boot messages http://pastebin.com/VdRYNxAW
The mmc_block kernel module is present. I am wondering why the kernel and initramfs works on the Cubietruck3 but not in Qemu. Any suggestions?
Thanks Mandar Joshi _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
On 06/06/2015 07:25 PM, Mandar Joshi wrote:
You'll have to run dracut yourself to build one, as far as I am aware, I'm used to a raspi which needs to use binary firmware, and the generic kernel doesn't work as well as the one compiled by the raspi foundation
cc35359, Running dracut manually did the trick. I am able to use CentOS7 stock kernel on my Cubietruck3.
Gordan, I am using the kernel that is available in the CentOS Repo vmlinuz-4.0.0-1.el7.armv7hl
Ok, so the next task I created a disk image using dd and installed @core and kernel. This works on the Cubietruck3.
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I have a cubietruck and have installed Fedora20 .. I have no idea how to do anything else with it, but I would like to learn how to take either a chroot'ed area or a mounted SD Card and create a bootable image for that.
If I can get something decent working, we'll be showing it at Red Hat Summit in a couple of weeks at the CentOS room.
I tried to boot the same image with qemu using this script http://pwhalen.fedorapeople.org/Fedora/20/boot-vexpress . I got the CentOS login prompt using the F22 kernel and initramfs. http://pastebin.com/mHBazwU4
The CentOS kernel and initramfs however is not able to find the root partition . It waits forever, gets stuck here http://pastebin.com/EUeBvcKD
Does anyone have a working CentOS initramfs and kernel for qemu? _______________________________________________ Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
On 10/06/15 15:54, Johnny Hughes wrote:
On 06/06/2015 07:25 PM, Mandar Joshi wrote:
You'll have to run dracut yourself to build one, as far as I am aware, I'm used to a raspi which needs to use binary firmware, and the generic kernel doesn't work as well as the one compiled by the raspi foundation
cc35359, Running dracut manually did the trick. I am able to use CentOS7 stock kernel on my Cubietruck3.
Gordan, I am using the kernel that is available in the CentOS Repo vmlinuz-4.0.0-1.el7.armv7hl
Ok, so the next task I created a disk image using dd and installed @core and kernel. This works on the Cubietruck3.
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I have a cubietruck and have installed Fedora20 .. I have no idea how to do anything else with it, but I would like to learn how to take either a chroot'ed area or a mounted SD Card and create a bootable image for that.
If I can get something decent working, we'll be showing it at Red Hat Summit in a couple of weeks at the CentOS room.
I can't help you with a Cubietruck specifically as I don't own one, but if there is an existing dd-and-go bootable image somewhere that you can point me at, I could cook you up a RedSleeve EL7 (or EL6 if you prefer) image that you could test. :)
Gordan
On 06/10/2015 10:01 AM, Gordan Bobic wrote:
On 10/06/15 15:54, Johnny Hughes wrote:
On 06/06/2015 07:25 PM, Mandar Joshi wrote:
You'll have to run dracut yourself to build one, as far as I am aware, I'm used to a raspi which needs to use binary firmware, and the generic kernel doesn't work as well as the one compiled by the raspi foundation
cc35359, Running dracut manually did the trick. I am able to use CentOS7 stock kernel on my Cubietruck3.
Gordan, I am using the kernel that is available in the CentOS Repo vmlinuz-4.0.0-1.el7.armv7hl
Ok, so the next task I created a disk image using dd and installed @core and kernel. This works on the Cubietruck3.
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I have a cubietruck and have installed Fedora20 .. I have no idea how to do anything else with it, but I would like to learn how to take either a chroot'ed area or a mounted SD Card and create a bootable image for that.
If I can get something decent working, we'll be showing it at Red Hat Summit in a couple of weeks at the CentOS room.
I can't help you with a Cubietruck specifically as I don't own one, but if there is an existing dd-and-go bootable image somewhere that you can point me at, I could cook you up a RedSleeve EL7 (or EL6 if you prefer) image that you could test. :)
Well, I understand everything that was done using yum and --installroot previously in this thread .. what I don't understand is how this thing actually boots and how to create that. In Fedora20, /boot/ is empty, so I am lost :)
What I would like to be able to do, if possible, is figure out make the root above into an image that I could install into the nand, etc. I would also be fine to put it on an sdcard as well. But knowing how to actually create all this stuff would be very nice to know :)
It seems that Mandar has all the knowledge I need .. is there a good blog post somewhere that details actually creating the bootable images, etc? Or would you post detailed commands like the one you did for the creation of the root, etc.
I created a sparc version beta of CentOS-4 and I know how to use UEFI on the armv8 stuff .. it's just these armv7 boards that are throwing me for a loop. But hopefully once I see some examples I can figure this stuff out.
Thanks, Johnny Hughes
On 10/06/15 16:18, Johnny Hughes wrote:
On 06/10/2015 10:01 AM, Gordan Bobic wrote:
On 10/06/15 15:54, Johnny Hughes wrote:
On 06/06/2015 07:25 PM, Mandar Joshi wrote:
You'll have to run dracut yourself to build one, as far as I am aware, I'm used to a raspi which needs to use binary firmware, and the generic kernel doesn't work as well as the one compiled by the raspi foundation
cc35359, Running dracut manually did the trick. I am able to use CentOS7 stock kernel on my Cubietruck3.
Gordan, I am using the kernel that is available in the CentOS Repo vmlinuz-4.0.0-1.el7.armv7hl
Ok, so the next task I created a disk image using dd and installed @core and kernel. This works on the Cubietruck3.
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I have a cubietruck and have installed Fedora20 .. I have no idea how to do anything else with it, but I would like to learn how to take either a chroot'ed area or a mounted SD Card and create a bootable image for that.
If I can get something decent working, we'll be showing it at Red Hat Summit in a couple of weeks at the CentOS room.
I can't help you with a Cubietruck specifically as I don't own one, but if there is an existing dd-and-go bootable image somewhere that you can point me at, I could cook you up a RedSleeve EL7 (or EL6 if you prefer) image that you could test. :)
Well, I understand everything that was done using yum and --installroot previously in this thread .. what I don't understand is how this thing actually boots and how to create that. In Fedora20, /boot/ is empty, so I am lost :)
It will depend on youboot loader. It could be that the kernel lives in NAND.
What I would like to be able to do, if possible, is figure out make the root above into an image that I could install into the nand, etc. I would also be fine to put it on an sdcard as well. But knowing how to actually create all this stuff would be very nice to know :)
Unfortunately, that is device specific, and as I mentioned, I don't own a Cubie.
You can find installation guides for RS here: https://wiki.redsleeve.org/index.php/Main_Page If cubie is similar to any of those, you should be able to adapt the process.
It seems that Mandar has all the knowledge I need .. is there a good blog post somewhere that details actually creating the bootable images, etc? Or would you post detailed commands like the one you did for the creation of the root, etc.
I created a sparc version beta of CentOS-4 and I know how to use UEFI on the armv8 stuff .. it's just these armv7 boards that are throwing me for a loop. But hopefully once I see some examples I can figure this stuff out.
Does it use uboot? If so, can you interrupt the boot and look at printenv for clues?
Gordan
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I generated it using the RootFS Build Factory I am developing along with Ian for GSoC. The repositories used are the ones created by Fabian http://armv7.dev.centos.org/repodir/c7-buildroot/ http://armv7.dev.centos.org/repodir/c7-pass-1/ http://armv7.dev.centos.org/repodir/comps/
The development code is on Github. You can try if it works for you. I have generated the images on Fedora 21 ARM running on the Cubietruck. I've tested generating images for Raspberry Pi 2 and Cubietruck. There is a provision in the RootFS Build Factory to extend support for boards using simple Bash scripts. But I'll not get into the details of that right now.
The generated image has to be written to a microSD card using dd/dcfldd The README.md on github has everything to get you started.
On 06/10/2015 11:44 AM, Mandar Joshi wrote:
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I generated it using the RootFS Build Factory I am developing along with Ian for GSoC. The repositories used are the ones created by Fabian http://armv7.dev.centos.org/repodir/c7-buildroot/ http://armv7.dev.centos.org/repodir/c7-pass-1/ http://armv7.dev.centos.org/repodir/comps/
The development code is on Github. You can try if it works for you. I have generated the images on Fedora 21 ARM running on the Cubietruck. I've tested generating images for Raspberry Pi 2 and Cubietruck. There is a provision in the RootFS Build Factory to extend support for boards using simple Bash scripts. But I'll not get into the details of that right now.
The generated image has to be written to a microSD card using dd/dcfldd The README.md on github has everything to get you started.
I used RBF to generate a CentOS-7 image for the cubietruck and it works. Mandar, this is going to be a great GSoC project .. I am impressed with RBF so far !!!
I did the build using this Fedora 20 image from dl.cubieboard.org in the nand:
http://dl.cubieboard.org/software/a20-cubietruck/fedora/ct-fedora20-lxde-v2/
File: fedora20-nand-lxde-vga.img.gz in the above link.
My generated image is 4 GB is size. 1GB for swap, 2 GB for root partition, 500MB for /boot
The VGA connector works for console output. none of the blinky lights on the cubietruck work.
I have a Logitec wireless MK710 keyboard and M705 mouse that works via USB, and both of these work on the cubietruck via a USB port.
Initially, one has to use the console to login ... root user, no password. You can not do this via SSH as a blank root password will not be accepted via ssh. Obviously, you need to change the root password once you login.
Here is the uname -a:
[root@cubietruck ~]# uname -a Linux cubietruck 4.0.0-1.el7.armv7hl #1 SMP Thu May 14 05:35:19 EDT 2015 armv7l armv7l armv7l GNU/Linux
I have not yet tried to flash this image to nand, so no idea if it works from there or how one would go about putting it there.
You can use Mandar's RBF program (above) to generate this for yourself as well .. but you do need enough space on a non NFS partition (fallocate, used to create the image, is not supported via NFS) for the image. In my case, I had to get a sata drive connected to the cubietruck in order to create the image as I did not have 4 GB free.
========================================================================== Are there others on the list where this image would be useful? Again, it is for the cubietruck (cubieboard3) only. I will make it available via this link:
http://people.centos.org/hughesjr/armv7hl/cubietruck/images/
File: cubietruck-centos-image.img.gz sha256sum: 335cd781d329a54ddece5924e7b94a52f294c633523dfdf775ab162a0b1ab1af
unzipped sha256sum: b9ba48e2df4a8729f7eb0ab916365cd4a98c0bb661df12d1d9bc7f6cf2b0f5bf ==========================================================================
gunzip it to use.
NOTE: None of the packages are signed and this is very much pre-alpha .. right from the builder with absolutely no QA of any kind.
Instructions:
1. I had to insert SD Card and zero out the first MB of the SDCard with this command:
(my card was at /dev/mmcblk0 .. yours may be somewhere else for the of=)
dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=1
2. dd the image to the sdcard with this command:
dd if=./cubietruck-centos-image.img of=/dev/mmcblk0
(again, your of= may vary)
3. Plug it into the cubietruck and boot :)
4. Login via the console, can not initially SSH in as the root password is blank. You can use the UART cable (http://www.cubietruck.com/products/usb-to-ttl-uart-serial-cable) or I was able to use the VGA port and a usb keyboard.
Thanks, Johnny Hughes
On 06/11/2015 08:29 PM, Johnny Hughes wrote:
On 06/10/2015 11:44 AM, Mandar Joshi wrote:
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I generated it using the RootFS Build Factory I am developing along with Ian for GSoC. The repositories used are the ones created by Fabian http://armv7.dev.centos.org/repodir/c7-buildroot/ http://armv7.dev.centos.org/repodir/c7-pass-1/ http://armv7.dev.centos.org/repodir/comps/
The development code is on Github. You can try if it works for you. I have generated the images on Fedora 21 ARM running on the Cubietruck. I've tested generating images for Raspberry Pi 2 and Cubietruck. There is a provision in the RootFS Build Factory to extend support for boards using simple Bash scripts. But I'll not get into the details of that right now.
The generated image has to be written to a microSD card using dd/dcfldd The README.md on github has everything to get you started.
I used RBF to generate a CentOS-7 image for the cubietruck and it works. Mandar, this is going to be a great GSoC project .. I am impressed with RBF so far !!!
I did the build using this Fedora 20 image from dl.cubieboard.org in the nand:
http://dl.cubieboard.org/software/a20-cubietruck/fedora/ct-fedora20-lxde-v2/
File: fedora20-nand-lxde-vga.img.gz in the above link.
My generated image is 4 GB is size. 1GB for swap, 2 GB for root partition, 500MB for /boot
The VGA connector works for console output. none of the blinky lights on the cubietruck work.
I have a Logitec wireless MK710 keyboard and M705 mouse that works via USB, and both of these work on the cubietruck via a USB port.
Initially, one has to use the console to login ... root user, no password. You can not do this via SSH as a blank root password will not be accepted via ssh. Obviously, you need to change the root password once you login.
Here is the uname -a:
[root@cubietruck ~]# uname -a Linux cubietruck 4.0.0-1.el7.armv7hl #1 SMP Thu May 14 05:35:19 EDT 2015 armv7l armv7l armv7l GNU/Linux
I have not yet tried to flash this image to nand, so no idea if it works from there or how one would go about putting it there.
You can use Mandar's RBF program (above) to generate this for yourself as well .. but you do need enough space on a non NFS partition (fallocate, used to create the image, is not supported via NFS) for the image. In my case, I had to get a sata drive connected to the cubietruck in order to create the image as I did not have 4 GB free.
========================================================================== Are there others on the list where this image would be useful? Again, it is for the cubietruck (cubieboard3) only. I will make it available via this link:
http://people.centos.org/hughesjr/armv7hl/cubietruck/images/
File: cubietruck-centos-image.img.gz sha256sum: 335cd781d329a54ddece5924e7b94a52f294c633523dfdf775ab162a0b1ab1af
unzipped sha256sum: b9ba48e2df4a8729f7eb0ab916365cd4a98c0bb661df12d1d9bc7f6cf2b0f5bf ==========================================================================
gunzip it to use.
NOTE: None of the packages are signed and this is very much pre-alpha .. right from the builder with absolutely no QA of any kind.
Instructions:
- I had to insert SD Card and zero out the first MB of the SDCard with
this command:
(my card was at /dev/mmcblk0 .. yours may be somewhere else for the of=)
dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=1
- dd the image to the sdcard with this command:
dd if=./cubietruck-centos-image.img of=/dev/mmcblk0
(again, your of= may vary)
Plug it into the cubietruck and boot :)
Login via the console, can not initially SSH in as the root password
is blank. You can use the UART cable (http://www.cubietruck.com/products/usb-to-ttl-uart-serial-cable) or I was able to use the VGA port and a usb keyboard.
NOTE: You will need to set 'enabled=0' for [base], [updates], and [extras] in /etc/yum.repos.d/CentOS-Base.repo for now. The 3 repos Mandar listed from the plague server output are also there and enabled.
Obviously, those repos may or may not have closure at any given point in time as they are the initial builders.
On 12/06/15 02:29, Johnny Hughes wrote:
On 06/10/2015 11:44 AM, Mandar Joshi wrote:
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I generated it using the RootFS Build Factory I am developing along with Ian for GSoC. The repositories used are the ones created by Fabian http://armv7.dev.centos.org/repodir/c7-buildroot/ http://armv7.dev.centos.org/repodir/c7-pass-1/ http://armv7.dev.centos.org/repodir/comps/
The development code is on Github. You can try if it works for you. I have generated the images on Fedora 21 ARM running on the Cubietruck. I've tested generating images for Raspberry Pi 2 and Cubietruck. There is a provision in the RootFS Build Factory to extend support for boards using simple Bash scripts. But I'll not get into the details of that right now.
The generated image has to be written to a microSD card using dd/dcfldd The README.md on github has everything to get you started.
I used RBF to generate a CentOS-7 image for the cubietruck and it works. Mandar, this is going to be a great GSoC project .. I am impressed with RBF so far !!!
I did the build using this Fedora 20 image from dl.cubieboard.org in the nand:
http://dl.cubieboard.org/software/a20-cubietruck/fedora/ct-fedora20-lxde-v2/
File: fedora20-nand-lxde-vga.img.gz in the above link.
My generated image is 4 GB is size. 1GB for swap, 2 GB for root partition, 500MB for /boot
Is swapping onto cheap SD card really a viable option? Would someting like zram be of more practical use?
Gordan
On 06/12/2015 03:17 AM, Gordan Bobic wrote:
On 12/06/15 02:29, Johnny Hughes wrote:
On 06/10/2015 11:44 AM, Mandar Joshi wrote:
Do you mind sharing how you created the disk image and kernel .. did you write it to nand or sd card.
I generated it using the RootFS Build Factory I am developing along with Ian for GSoC. The repositories used are the ones created by Fabian http://armv7.dev.centos.org/repodir/c7-buildroot/ http://armv7.dev.centos.org/repodir/c7-pass-1/ http://armv7.dev.centos.org/repodir/comps/
The development code is on Github. You can try if it works for you. I have generated the images on Fedora 21 ARM running on the Cubietruck. I've tested generating images for Raspberry Pi 2 and Cubietruck. There is a provision in the RootFS Build Factory to extend support for boards using simple Bash scripts. But I'll not get into the details of that right now.
The generated image has to be written to a microSD card using dd/dcfldd The README.md on github has everything to get you started.
I used RBF to generate a CentOS-7 image for the cubietruck and it works. Mandar, this is going to be a great GSoC project .. I am impressed with RBF so far !!!
I did the build using this Fedora 20 image from dl.cubieboard.org in the nand:
http://dl.cubieboard.org/software/a20-cubietruck/fedora/ct-fedora20-lxde-v2/
File: fedora20-nand-lxde-vga.img.gz in the above link.
My generated image is 4 GB is size. 1GB for swap, 2 GB for root partition, 500MB for /boot
Is swapping onto cheap SD card really a viable option? Would someting like zram be of more practical use?
This is a pre-alpha, proof of concept kind of image with unsigned packages as they come out of the plague-servers .. not one to use in production. Really just a proof that this OS can boot on the device. A 2GB root partition is also not very useful, so eventually a 5 to 5.5 GB root partition should be created (which would, if we get this all running in nand, be the limit with a 1GB swap and 500MB /boot). One of my goals with this was also to NOT break the other, bootable install in rand.
There is various talk on the cubieforums as to whether the nand (on board storage) is faster or slower than the SD Card storage. I have not run any tests at this point.
I don't even see the nand with an "fdisk -l" when this image is booted from the SD card.
Hopefully some really smart people who have this device and know how to use it can figure out what needs to be done to make this better. I am sure lots of time here: http://linux-sunxi.org/LiveSuite_images will be required to get a nand image going.
Since the indicator lights (blinky lights :D) on the board are not working, I am sure there are a couple of tweaks that can be made to the kernel configs as well.
Thanks, Johnny Hughes
On 06/06/15 17:50, Mandar Joshi wrote:
The two repositories you are pointing yum at are only "raw" trees with rpms/srpms so I created an empty comps repository containing the comps.xml file and repodata needed around it (for my first test with appliance-creator some days ago) :
Thanks. That worked. I am facing one problem though I did
yum --installroot=/tmp/temp install kernel
but there is no initramfs in /tmp/temp/boot Any idea what might be going wrong?
You will probably have to run dracut yourself, but do you actually need initramfs? What kernel are you using? Is a kernel rpm for your device available, or are you winging it like most of the rest of us with dodgy unpackaged kernels?
Gordan
I wrote up a document for creating the necessary raspi image based off of a generic rootfs. Whenever you get the wiki positioned the way you want, let me know and I can wikify my instructions. In regards to the generic rootfs, I started to play with a couple ideas on a raspberry pi itself, pushing the packages from rpm/yum onto a separate partition (USB stick) to see if that does work well enough. I'm going to time travel back and see if I can see how fedora had started to build their's in case there was a more efficient method we handnt thought of.
----------------------------
If you decide where to plant the wiki page, I'll be happy to document all the steps necessary to go from rootfs to a running raspi. I can toss on the extra steps I took for this "proof of concept" I built as well for now, though those steps will be irrelevant when there is a CentOS rootfs. It does use the kernel compiled specifically for the board from the raspi foundation, as well as the necessary binary firmware. One thing to consider is that when it comes to the arm boards, in my opinion, where people will be turning to CentOS is for their home servers. They want the security, stability and support cycle that centos provides for the Pi that's their file server, or owncloud server, or dovecot/postfix, that is running non stop and problem free in the closet. Its unlikely that the media lovers will be turning to CentOS except for minidlna or media tomb. Starting developers may also be attracted to using an enterprise grade system instead of the bleeding edge distros, so some basic gpio pin usage may be done. So at the very least, a collection of how to's in regard to common home server applications may be beneficial, as a lot of these devices aren't targeted to those of us using Linux the last 20 years, but for those who are starting out learning. I'll be happy to write any up that we feel would be good to have. Maybe we even want to think of including some things like samba, owncloud, dlna server, etc in an image for that reason as well (things that centos already provides for the x86-64). Just some thoughts. I'll paste the link to the image below. I did build it on a 16gb SD card as I had nothing smaller laying around, but I can always find a $4 4gb card to help generate future images depending on how its decided to generate them in the future- if we provide a full image for different boards, or just instruct on how to use the generic image. Maybe we'll want a minimal image and a GUI image even. I shrunk it up a bit more to what I felt was a good balance of what a minimal install should have, and I exported the list from yum to the /root/ directory, so you can mount the image and grab the list without having to extract it from the yum or rpm databases. The / partition has 672mb of data on it. Also, I didn't notice a dhcp service built, so to use the image you will need to set a static one the old fashioned way (ifconfig and 'route add default x') . The pass1 and buildroot repos added are disabled by default. Root password is blank, and obviously would need to be set before allowing the internet (and all its lovely bots) to touch it. -David https://drive.google.com/open?id=0B6w0L-XWgP4sVGpkS1l5dnE2bkk&authuser=0
-
cc35359＠gmail.com -
Fabian Arrotin -
Gordan Bobic -
Johnny Hughes -
Mandar Joshi