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