Bug 483051

+++ This bug was initially created as a clone of Bug #483041 +++

+++ 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.

--- Additional comment from jwboyer on 2009-01-29 08:56:14 EDT ---

I believe we need to fix yaboot in F-10 (and probably F-9) as well for preupgrade to work properly.