Hi Jacco.
Did you get the rbf to work out of the box?
I had to made some patches to make it run on Redsleeve 6 / Raspberry Pi.
I posted them on
https://github.com/mndar/rbf/issues
I do not like how he hardcode links to tools in the scripts. He should
either trust the users environment or do a search for the needed tools
before running them.
I took a "core" comps file list from a CentOS 6 x86_64 (all the
mandatory files in
http://www.mirrorservice.org/sites/mirror.centos.org/6/os/x86_64/repodata/4df092633ebecaeebdd78359a11a3c13f619f22605322e15e5e307beebd8e641-c6-x86_64-comps.xml
)
BR
Bjarne
On 21-10-2015 22:48, Jacco Ligthart wrote:
Hi,
both :)
I think Mandar uses some directory trees under files/<board> to store
kernels/modules or other artifacts, which can be copied over at image
creation time. However, as it will install everything else from RPMs,
it's easy to add the kernel rpm to the list of RPMs to install.
I include in this mail the templates I used for rpi2 and dreamplug.
For the rpi2 you can see that the kernel (and some other RPMs which I
find that should be installed on a rpi2) are just listed in the
<package> section.
For the dreamplug that did not quite work, as the kernel (from F18)
requires "/sbin/new-kernel-pkg", which is provided by grubby. However
this is not as such listed in the provides section of grubby. This
creates a dependency failure and thus a non working image.
So I installed the kernel afterwards by hand (loop mount the image and
"yum install --installroot=" etc.
The "right" way would probably have been to create a board script to yum
install the kernel. Such a script could then f.i. adjust dracut.conf
beforehand etc.
You might notice that I included a local repo called comps. This is
because our repo does not include a "core" group currently. I think I
included the contents of this group in an earlier email.
Jacco
On 21-10-15 13:05, Gordan Bobic wrote:
Does rbf do rpm installing itself or is it image based? I ask because
I'm hoping to get this to the point where we have a kernel rpm for
Kirkwood devices that works transparently on upgrades like on x86.
On 2015-10-21 11:59, Jacco Ligthart wrote:
I think it would be good to include this in a rbf template. This will
allow for a repeatable process of image creation.
I'll post mine later today, when I'm home.
Jacco
On Wednesday, 21 October, 2015 11:20 CEST, Gordan Bobic
<[email protected]> wrote:
It's not a kernel bug, it's a dracut bug that I was talking about.
The problem is that dracut wasn't including ehci-orion USB driver
in the initramfs. Once you figure out what the root cause of the
problem is, it is trivially fixable with the configuration option
I listed below.
From here I should be able to follow the standard RSEL recipe:
1) Grab a working kernel uImage, /lib/firmware, and
/lib/modules/$kernel/
2) Drop them into the RSEL image
3) Make the configuration changes mentioned below (also remember to
blacklist the orion_nand driver due to the GuruPlug/DreamPlug machid
confusion issue, as loading the orion_nand driver on DreamPlug will
hang)
4) Rebuild initramfs using dracut, and uboot it using mkimage
And that should just work.
For completeness and neatness, I will put together a kernel package
that can be installed using rpm and facilitate seamless kernel
upgrades.
Another package that may require revisiting in RSEL to facilitate
seamless kernel upgrades is grubby, as this handles re-packing
vmlinux and initramfs into uImage/uInitrd.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
