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

Wed Jun 3 20:44:40 UTC 2015
cc35359 at gmail.com <cc35359 at gmail.com>

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>