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