[Arm-dev] enough packages for a @core install ?

[Gordan Bobic]

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