<html><head></head><body>Used a 1gb usb card, formatted to xfs and mounted to /mnt/rootfs<br>
<br>
<br>
<br>
$ mkdir -p /mnt/rootfs/var/lib/rpm<br>
<br>
$ rpm --root /mnt/rootfs --initdb<br>
<br>
$ yumdownloader --destdir=/var/tmp centos-release<br>
<br>
$ cd /var/tmp<br>
<br>
$ rpm --root /mnt/rootfs -ivh --nodeps centos-release*rpm<br>
<br>
$ cp /etc/yum.repos.d/pass1.repo /mnt/rootfs/etc/yum.repos.d/<br>
<br>
$ cp /etc/yum.repos.d/buildroot.repo /mnt/rootfs/etc/yum.repos.d/<br>
<br>
$ yum --installroot=/mnt/rootfs -y groupinstall @core<br>
<br>
<br>
<br>
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).<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><br><div class="gmail_quote">On June 3, 2015 4:36:03 AM CDT, Gordan Bobic <gordan@redsleeve.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2015-06-03 07:55, Fabian Arrotin wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> -----BEGIN PGP SIGNED MESSAGE-----<br /> Hash: SHA1<br /> <br /> On 02/06/15 11:07, Gordan Bobic wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On 2015-06-02 02:23, cc35359@gmail.com wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> I just read about the Google summer of code project in regards<br /> to repacking/customizing arm 32 images, how does that effect what<br /> we are looking to accomplish? I don't mind assisting in the<br /> rootfs build (the right way), but I've never tried it in my 20<br /> years of nix :-). I'm wondering if I use my pi image, chroot into<br /> a new pqrtition and do the installs in that? That sounds
easy,<br /> but not sure if it is that easy.<br /></blockquote> <br /> On the subject of images, it also occurs to me that it would make<br /> sense to standardise the image contents between CentOS and<br /> RedSleeve to keep them at least similar if not 100% identical.<br /> <br /> Gordan<br /></blockquote> <br /> That's a good idea, so we can discuss that.<br /> My idea was to have "minimal" reflecting what we have for x86_64 (and<br /> i686 now in beta !)<br /></blockquote><br />Good to hear you guys got there with the i686 build in the end. I'd<br />been using the Scientific Linux i686 port as a base to build my own,<br />but the main reason I've needed it for is WINE builds and the odd<br />Steam and Optimus/Bumblebee dependency, so once I had a complete<br />mock chroot build set for those I didn't bother with completing the<br />package build.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> for
CentOS 7, so reusing the comps.xml and<br /> installing @core. I've quickly done a test yesterday , and built an<br /> initial test image through appliance-creator (thanks Howard for the<br /> pointer !) but without "cleaning up" the comps.xml so it installed<br /> some firwmare (noarch) files that aren't needed at all on the arm<br /> platform.<br /></blockquote><br />Do you have a link handy to a copy of the CentOS 7 (and CentOS 6 for<br />that matter) comps.xml file?<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> It needed 706Mb on / (normal for @core), but we can reduce that.<br /></blockquote><br />I am not even sure it is worth wasting too much time trying to skim<br />that down a bit. I find that having a few extra things is really<br />quite handy, and helps greatly to get up and running quickly.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px
solid #729fcf; padding-left: 1ex;"> I've only tested that image through qemu-system-arm and here are the<br /> results :<br /> <br /> uname -a ; rpm -q centos-release ; cat /proc/cpuinfo<br /> Linux localhost 3.18.7-200.el7.0.1.armv7hl #1 SMP Tue Jun 2 10:18:14<br /> UTC 2015 armv7l armv7l armv7l GNU/Linux<br /> centos-release-7-1.1503.el7.centos.2.7.armv7hl<br /> processor : 0<br /> model name : ARMv7 Processor rev 0 (v7l)<br /> BogoMIPS : 695.09<br /> Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32<br /> CPU implementer : 0x41<br /> CPU architecture: 7<br /> CPU variant : 0x0<br /> CPU part : 0xc09<br /> CPU revision : 0<br /> <br /> Hardware : ARM-Versatile Express<br /> Revision : 0000<br /> Serial : 0000000000000000<br /> <br /> Now if someone can have a look at the required bits for various boards<br /> (my time is very limited actually, so just spending some "free" time<br /> on armv7hl at the moment)<br /></blockquote><br />I'm not sure what your plans
are for CentOS, but given the sheer volume<br />of various hardware, I don't think it is reasonable for the core project<br />to try to cover everything. My experience with RedSleeve is that most<br />people are using R-Pi (1 and 2), Odroid, Cubies and CuBox-es - which<br />interestingly means next to no overlap with my own hardware so I can't<br />support it. I mostly use Kirkwood devices (*Plug, QNAP NAS), Tegra2<br />(Toshiba AC100) and Chromebook (Exynos) machines, I was donated a<br />CuBox to get an image built for it, and other than that I have a few<br />relatively obscure machines that I have on the shelf that I have not<br />yet had a chance to even look at getting up and running yet, and<br />since I got them the manufacturers of some of them appear to have gone<br />out of business. :(<br /><br />The point I'm getting to is that some engagement from the community<br />is likely to be necessary for such things, purely because to support<br />the hardware you have to have
the hardware, and without a substantial<br />toy and manpower budget it will almost certainly have to fall to the<br />community members to figure out and support anything but the most<br />widely used hardware.<br /><br />This is also made more difficult by the fact that even when the sources<br />are available, the kernels in use are massively heavily patched, and<br />pretty ancient. Ignoring the issue of bugs and security with such <br />ancient<br />kernels, it is still a case of having to have a separate specific kernel<br />build for many devices, some of which require various additional bodges <br />to<br />make them work. For example, on the Exynos Chromebook, the kernel <br />firmware<br />loader isn't quite up to the task of loading the firmwares itself, which<br />means much of the hardware won't work with the 3.4 kernel built from <br />sources<br />in the usual way. The only workaround that makes it work with systemd is <br />to<br />glue the firmware blobs into the
kernel itself. Getting to a fully <br />working<br />system took me most of the last weekend, and from experience much ARM<br />hardware is like that. And that is a LOT of man-days to spend on an<br />unfunded project to support a wide range of hardware.<br /><br />Gordan<br /><hr /><br />Arm-dev mailing list<br />Arm-dev@centos.org<br /><a href="http://lists.centos.org/mailman/listinfo/arm-dev">http://lists.centos.org/mailman/listinfo/arm-dev</a><br /></pre></blockquote></div></body></html>