Hide Forgot
There's no kexec-tools in rawhide. This is because we have crappy heuristics about which ppc64 packages should be shipped in the biarch PowerPC repo, and kexec-tools doesn't match them. Since there's no 32-bit kexec-tools package, it doesn't get shipped at all. We can make 32-bit kexec userspace actually work for 64-bit kernels. Then it'll get shipped -- and it'll be a lot smaller when we put it into an initrd for the PlayStation 3 bootloader too. Attaching a _really_ ugly patch which I'll hopefully get round to cleaning up some time next week.
Created attachment 151921 [details] kexec-tools-1.101-ppc-boots-ppc64.patch
--- kexec-tools.spec 26 Mar 2007 13:22:11 -0000 1.79 +++ kexec-tools.spec 7 Apr 2007 21:44:29 -0000 @@ -23,8 +23,7 @@ Requires: busybox >= 1.2.0 BuildRequires: zlib-devel elfutils-libelf-devel glib2-devel pkgconfig BuildRequires: elfutils-libelf-devel elfutils-devel-static gettext -ExcludeArch: ppc -%ifarch %{ix86} x86_64 ppc64 ia64 +%ifarch %{ix86} x86_64 ppc64 ia64 ppc Obsoletes: diskdumputils netdump %endif @@ -65,6 +64,7 @@ Patch304: kexec-tools-1.101-ppc64-platform-fix.patch Patch305: kexec-tools-1.101-ppc64-64k-pages.patch Patch306: kexec-tools-1.101-ppc64-memory_regions.patch +Patch307: kexec-tools-1.101-ppc-boots-ppc64.patch # # Patches 401 through 500 are meant for s390 kexec-tools enablement @@ -118,6 +118,9 @@ %patch304 -p1 %patch305 -p1 %patch306 -p1 +%ifarch ppc +%patch307 -p1 +%endif %patch401 -p1 %patch501 -p1 %patch601 -p1 @@ -133,6 +136,10 @@ tar -z -x -v -f %{SOURCE13} +%ifarch ppc +%define archdef ARCH=ppc64 +%endif + %build %configure \ %ifarch ppc64 @@ -142,15 +149,15 @@ --sbindir=/sbin rm -f kexec-tools.spec.in cp %{SOURCE10} . -make -%ifarch %{ix86} x86_64 ia64 ppc64 +make %{?archdef} +%ifarch %{ix86} x86_64 ia64 ppc64 ppc make -C makedumpfile %endif make -C po %install rm -rf $RPM_BUILD_ROOT -make install DESTDIR=$RPM_BUILD_ROOT +make install %{?archdef} DESTDIR=$RPM_BUILD_ROOT make -C po install DESTDIR=$RPM_BUILD_ROOT mkdir -p -m755 $RPM_BUILD_ROOT%{_sysconfdir}/rc.d/init.d mkdir -p -m755 $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig @@ -169,7 +176,7 @@ install -m 644 kexec/kexec.8 $RPM_BUILD_ROOT%{_mandir}/man8/kexec.8 install -m 755 %{SOURCE11} $RPM_BUILD_ROOT%{_datadir}/kdump/firstboot_kdump.py install -m 644 %{SOURCE12} $RPM_BUILD_ROOT%{_mandir}/man8/mkdumprd.8 -%ifarch %{ix86} x86_64 ia64 ppc64 +%ifarch %{ix86} x86_64 ia64 ppc64 ppc install -m 755 makedumpfile/makedumpfile $RPM_BUILD_ROOT/sbin/makedumpfile install -m 755 makedumpfile/makedumpfile-R.pl $RPM_BUILD_ROOT/sbin/makedumpfile-reasm %endif
Created attachment 152118 [details] somewhat cleaner patch
Since we've ripped out the platform determination code (since its not overly reliable), I'm just going to reduce the max rmo_top value to 0x7c000000UL for now. Being rawhide, If that has any adverse affects on anything else, we'll catch it early and be able to come up with something better.
sorry, wrong bug, please disregard comment #4
David, I'm a little concerned about this change. We initially removed 32 bit ppc from the build because (prior to PS3) we had no need for it. Now that we do, I want to be extra sure that that we don't bust any of the ppc64 systems with this. What testing have you done to ensure that this works with ppc64 systems?
You're thinking of RHEL. We _can't_ bust ppc64 kexec in Fedora because we aren't even _shipping_ kexec-tools in Fedora -- which in fact is because there is no 32-bit version of the package and this is one of the places where the "does it have a -devel subpackage?" heuristic for choosing which packages to ship 64-bit gets the answer wrong (cf. bug #235758) We removed the 32-bit kexec package because kexec of 32-bit machines isn't functional. That remains the case; this patch makes the 32-bit userspace package capable of booting 64-bit machines. I'll get to 32-bit machines eventually (probably after Fedora 7), and then I'll make the 32-bit package capable of _both_. For the time being, this patch is _only_ about kexec of 64-bit machines. It's been tested on Mac G5 and PlayStation 3. I haven't just done empirical testing by booting into new kernels; I also hacked the debug output to print a crc32 of each memory section passed to kexec, and compared with the native 64-bit userspace.
Wait, one more concern...I've got this checked in against -67.fc7, but I'm concerned about this: +%ifarch ppc +%patch307 -p1 +%endif this is a mess to maintain for me, and I can't see any reason why the changes you made to kexec-ppc64.c warrant this conditional application. Can you explain to me why you did this? Thanks!
That was done because my _original_ patch was an evil hack -- it didn't just change ppc64-specific things; it did things like unconditionally adding '-m64 -mcall-aixdesc' to CFLAGS when building purgatory. That wasn't really something you wanted to do elsewhere. The _new_ patch I filed last night doesn't have those problems. The only remaining change to generic code is making the fields in struct sha256_region into uint64_t, and building sha256.c using purgatory's CFLAGS instead of building it once in the util_lib/ directory and using the same object in both kexec and purgatory. Those changes should be perfectly OK on all platforms. So it's OK to drop the %ifarch ppc. I haven't tested on non-ppc64 though. Note that although I think I enabled makedumpfile on ppc in my specfile patch, I haven't actually checked that it's 64-bit clean. I don't even know what it does, further the the obvious inferences from the name.
(In reply to comment #4) > Since we've ripped out the platform determination code (since its not overly > reliable), I'm just going to reduce the max rmo_top value to 0x7c000000UL for > now. That would be an increase. Hopefully you mean 0x07c00000 :)
in reply to comment #10: yes, bad eyes :) This is checked in as -67.fc7. Thanks!