+++ This bug was initially created as a clone of Bug #480842 +++ Description of problem: Attempting to boot F11 rawhide on a IBM Power5 ppc64 system fails. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Download rawhide vmlinuz and ramdisk.image.gz to my running F10 ppc system 2. Add boot entries in /etc/yaboot.conf for the rawhide kernel+initrd.img 3. Reboot Actual results: Elapsed time since release of system processors: 18805 mins 25 secs Config file read, 1024 bytes Welcome to Fedora! Hit <TAB> for boot options Welcome to yaboot version 1.3.14 (Red Hat 1.3.14-6.fc10) Enter "help" to get some basic usage information boot: install Please wait, loading kernel... /vmlinuz: Not a valid ELF image boot: Expected results: The kernel should boot when requested from yaboot Additional info: Running the F10 and the rawhide vmlinuz through the 'file' command shows: # file /boot/*vmlinuz* /boot/vmlinuz: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, stripped /boot/vmlinuz-2.6.27.5-117.fc10.ppc64: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, stripped Is it a problem that the bootable F10 vmlinuz is a "MSB executable" while the failing rawhide vmlinuz is a "MSB shared object"? --- Additional comment from jlaska on 2009-01-21 11:40:04 EDT --- I'm at a loss, not sure why the kernel filename has changed in rawhide (http://download.fedora.redhat.com/pub/fedora/linux/development/ppc/os/ppc/ppc64/vmlinuz). Nothing in the kernel changelog jumps out at me. Adding dhowells to the cc list, perhaps he may have some insight. --- Additional comment from jwboyer on 2009-01-21 20:09:30 EDT --- I've been doing some local mock builds of the rawhide kernel. I disabled the debuginfo RPM creation in the kernel.spec file, and added a 'file $1' command to the local cp_vmlinux function. The results are below: + '[' -f arch/powerpc/boot/zImage.stub ']' + cp_vmlinux vmlinux /builddir/build/BUILDROOT/kernel-2.6.29-0.43.rc2.git1.fc11.ppc/boot/vmlinuz-2.6.29-0.43.rc2.git1.fc11.ppc64 + file vmlinux vmlinux: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, not stripped So as you can see, the kernel build itself seems to be spitting out the "shared object" vs. the "executable", and it's not elfutils or RPM messing it up during debuginfo creation. I'll poke at it a bit more and see if anything happens. --- Additional comment from jwboyer on 2009-01-21 22:24:27 EDT --- A 'make local' on an F-10 G5 shows the same issues. Trying just a raw git build on the F-10 box to see what that produces. --- Additional comment from jwboyer on 2009-01-21 22:30:27 EDT --- LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map [jwboyer@localhost linux-2.6]$ ls arch drivers Kbuild Module.markers scripts vmlinux block firmware kernel Module.symvers security vmlinux.o COPYING fs lib net sound CREDITS include MAINTAINERS README System.map crypto init Makefile REPORTING-BUGS usr Documentation ipc mm samples virt [jwboyer@localhost linux-2.6]$ file vmlinux vmlinux: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, not stripped [jwboyer@localhost linux-2.6]$ Curious. --- Additional comment from jwboyer on 2009-01-22 11:24:39 EDT --- James tried http://koji.fedoraproject.org/koji/buildinfo?buildID=79697 as well, which is a 2.6.28 kernel. Same failure, and the vmlinuz is still detected as a "shared object". I'm doing a git bisect on the kernel to figure out what change upstream caused this. --- Additional comment from jwboyer on 2009-01-22 12:10:25 EDT --- Ok, so the problem appears to be having CONFIG_RELOCATABLE=y set. This builds the kernel with -pie and changes the elf type to ET_DYN instead of ET_EXEC. Apparently, yaboot doesn't like that so much. I'm doing a scratch build of the rawhide kernel with CONFIG_RELOCATABLE disabled. We'll test that out and see what happens. --- Additional comment from jwboyer on 2009-01-22 12:32:09 EDT --- Methinks yaboot needs this: http://ozlabs.org/pipermail/yaboot-devel/2008-December/000250.html --- Additional comment from jwboyer on 2009-01-22 12:43:11 EDT --- Please try the scratch yaboot build here: http://kojipkgs.fedoraproject.org/scratch/jwboyer/task_1074563/ --- Additional comment from jlaska on 2009-01-22 13:10:03 EDT --- (In reply to comment #8) > Please try the scratch yaboot build here: > > http://kojipkgs.fedoraproject.org/scratch/jwboyer/task_1074563/ Thanks this resolved the problem! 1) Install Fedora-10 2) Installed the yaboot.ppc provided in the scratch build 3) Download vmlinuz+ramdisk.image.gz for rawhide-ppc (http://download.fedora.redhat.com/pub/fedora/linux/development/ppc/os/ppc/ppc64/) 4) Add a boot target into existing yaboot.conf to load the rawhide vmlinuz+ramdisk.image.gz 5) reboot Expected Results: yaboot loads and boots the rawhide kernel Actual Results: It worked :) Elapsed time since release of system processors: 21542 mins 40 secs^M ^M Config file read, 1024 bytes^M ^LWelcome to Fedora!^M Hit <TAB> for boot options^M Welcome to yaboot version 1.3.14 (Red Hat 1.3.14-9.fc11)^M Enter "help" to get some basic usage information^M boot: kick1232647182^M Please wait, loading kernel...^M Elf64 kernel loaded...^M Loading ramdisk...^M ramdisk loaded at 03600000, size: 19861 Kbytes^M OF stdout device is: /vdevice/vty@30000000^M Hypertas detected, assuming LPAR !^M command line: ro console=hvc0 rhgb quiet root=UUID=c65dc57b-e333-4642-b542-aaae336fd3dd ksdevice=link ip=dhcp ks=http://dell-t5400.test.redhat.com/cblr/svc/op/ks/system/ibm-505-lp1 serial kssendmac ^M --- Additional comment from jwboyer on 2009-01-22 13:24:56 EDT --- Yaboot spec file changes: cvs diff: Diffing . Index: yaboot.spec =================================================================== RCS file: /cvs/pkgs/rpms/yaboot/devel/yaboot.spec,v retrieving revision 1.56 diff -u -p -r1.56 yaboot.spec --- yaboot.spec 27 Nov 2008 15:38:18 -0000 1.56 +++ yaboot.spec 22 Jan 2009 18:24:24 -0000 @@ -1,7 +1,7 @@ Summary: Linux bootloader for Power Macintosh "New World" computers. Name: yaboot Version: 1.3.14 -Release: 8%{?dist} +Release: 9%{?dist} License: GPLv2+ Group: System Environment/Base Source: http://yaboot.ozlabs.org/releases/yaboot-%{version}.tar.gz @@ -24,6 +24,7 @@ Patch28: yaboot-1.3.13-dontwritehome.pat Patch29: yaboot-1.3.14-baseaddr.patch Patch30: yaboot-1.3.14-fix-bootonce-nvram.patch Patch31: yaboot-1.3.14-bigger-max-token.patch +Patch32: yaboot-relocatable-kernel.patch URL: http://yaboot.ozlabs.org/ BuildRoot: %{_tmppath}/%{name}-root @@ -58,6 +59,7 @@ yaboot can also bootload IBM pSeries mac %patch29 -p1 -b .baseaddr %patch30 -p1 -b .bootonce %patch31 -p1 -b .maxtoken +%patch32 -p1 -b .relocatable %build make VERSIONEXTRA='\ (Red Hat %version-%release)' @@ -93,6 +95,9 @@ rm -rf $RPM_BUILD_ROOT %ghost %config(noreplace) %{_sysconfdir}/yaboot.conf %changelog +* Thu Jan 22 2009 Josh Boyer <jwboyer> - 1.3.14-9 +- Add patch to handle relocatable kernels + * Thu Nov 27 2008 Roman Rakus <rrakus> - 1.3.14-8 - Bumped release, so preupgrade is now silent and go through --- Additional comment from jwboyer on 2009-01-22 13:26:06 EDT --- Created an attachment (id=329726) Patch to allow yaboot to deal with relocatable kernels --- Additional comment from jwboyer on 2009-01-22 13:36:52 EDT --- Spoke with Jesse and James about this. David is at LCA and this is marked as an Alpha blocker, so I committed the changes and did a build. It should show up in tomorrow's rawhide. As an added note, this same bug had the potential to affect F-10 when that migrated to using 2.6.28 kernels. I had davej disable the kernel config option in F-10 to allow things to progress. If yaboot gets fixed in F-10, we can turn that back on in the kernel.
I believe we need to fix yaboot in F-10 (and probably F-9) as well for preupgrade to work properly.
yaboot-1.3.13-14.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
yaboot-1.3.14-9.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.