Great. Also confirmed cross-prelink independently derived my patch. Strong confidence there but still concerns overall that I have the ball on. Thanks very much, Brendan.
Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/04/2012 02:24 AM, Jon Masters wrote:
> Try this trivial patch to src/get.c that educates prelink about our
> linker (so it won't try to prelink the linker itself). This will then
> pass the testsuite. On the one hand, if this is all it is it's almost
> annoying that I went to the lengths to understand how it works before
> looking at it in detail, but on the other Jakub has told me there's not
> a lot of good data on prelink-on-arm so I need to do more code review
> /anyway/. Please try this patch and see what happens.
I've installed the prelink package from arm.koji on an armv5tel rootfs,
let prelink run its cron job, and the resulting system appears to be
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
arm mailing list
I did some crazy interesting reading regarding some people in the past (including some really bright people who have worked at RedHat :)
This included many funny/entertaining bug reports containing comments from Drepper vs Stallman vs Torvalds etc...
Some of the highlights from those included:
Then I went back and wanted to look at what requirements primary/fesco requested in specific of ARM here:
Anyway then I was really bored and wanted to work on looking at the source code to Anaconda
Little did I know that dmarlin is also doing some great work on the various needed layers to make Anaconda run sensibly on our platforms (I'm sorry for that!)
I think to, tho, that we are tackling different areas of it so we can also possibly combine our work later on and have a better result in the end hopefully :)
So I took a Guru from Jordan & Max and used Paul's computer since it has 2 NICs so it can NAT the WAN and installed pbrobinson's F17 on it
Without all of your hard work efforts (from the entire ARM community!) on F17, I wouldn't have even been able to test it or even get it running on an ARM device so thank you all as well! :D
Anyway, I know I may be jumping the gun here on how all of these things should work but I'm really trying hard to prove useful to the hard working community...
Basically here's what I have to offer to help out with the push to primary (keep in mind that I am by no means a programmer so I'm sorry for the bad code!):
An "easy-to-use", cross-platform, generalized, GUI Fedora ARM Installer: http://fossjon.wordpress.com/2012/02/15/fedora-arm-image-installer-faii/
Some simple shell scripts to help us show the others of our current build status (error number/build times): http://fossjon.wordpress.com/2012/03/27/some-koji-scripts-the-push-for-pr...
The initial workings of Anaconda & Firstboot on Fedora ARM devices: http://fossjon.wordpress.com/2012/04/05/tweaking-anaconda-to-run-on-arm/
With those parts above, some of them can be used in conjunction with each other (like the installer with an Anaconda-based image) to show our value,
Anyway, sorry for the long email,
I've just had a lot on my mind lately and needed to talk to you guys about it,
Hopefully my coding skills are at least able to help us demonstrate that ARM is a serious contender for primary as we're all working extremely hard to get all the parts in place,
Thanks for all your time and patience with my long (possibly bad) e-mailing-list-items,
Slight disruption over the weekend, but I re-read the ELF spec, Jakub's
paper, and started poking at the source. In large part, I wanted to make
sure someone was tracking this for future AArch64 stuff. But now, I'll
get back to actually fixing the problem, with an update to follow.
When I tried to run a QEMU virtual machine for fedora-17 using kernel-3.3.0-0.rc4.git3.1.fc17.armv5tel, the kernel displayed the message:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.3.0-0.rc4.git3.1.fc17.armv5tel (mockbuild(a)hsv-trimslice-7-v5tel.farm.hsv.redhat.com) (gcc version 4.7.0 20120206 (Red Hat 4.7.0-0.11) (GCC) ) #1 Thu Feb 23 13:10:33 EST 2012
[ 0.000000] CPU: ARM926EJ-S  revision 5 (ARMv5TEJ), cr=00093177
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: ARM-Versatile PB
[ 0.000000] INITRD: 0x00d00000+0x00a89878 overlaps in-use memory region - disabling initrd
...and the system failed to boot.
I am currently running Fedora-17 with the Fedora-15 kernel, but I want to try compiling the kernel from http://fedora.c3sl.ufpr.br/linux/development/17/source/SRPMS/k/kernel-3.3... as a binary RPM for both QEMU and a development board I have.
So, what went wrong in the generation of kernel-3.3.0-0.rc4.git3.1.fc17.armv5tel ? I want to avoid making the same mistake and ending up with an unbootable kernel. Is it enough to have this updated source RPM?