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 at 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 at 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 at centos.org >http://lists.centos.org/mailman/listinfo/arm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20150603/b85169b6/attachment-0006.html>