=Comment: #0================================================= Mohammed Omar <mohd.omar.com> - 2008-02-28 04:24 EDT ----Problem description:---- ppc64-utils rpm is empty.Actually I was searching for mkzimage, which is part of ppc64-utils package. rpm: ppc64-utils-0.14-1.fc9.ppc version: 0.14-1.fc9.ppc Distro: Fedora 9 Alpha ---additional info--- I cheked with rawhide rpm (ppc64-utils-0.14-2.fc9.ppc) .Which is also null. --Regards Omar M =Comment: #1================================================= Suzuki Kp <suzukikp.com> - 2008-02-28 10:50 EDT Please provide additional informations, like : 1) Where did you download the ppc64-utils rpm ? 2) How did you confirm the rpm is empty ? Thanks Suzuki =Comment: #2================================================= Mohammed Omar <mohd.omar.com> - 2008-02-28 23:34 EDT ppc64-utils rpm shipped with DVD iso. Downloaded from http://software.linux.ibm.com/pub/fedora/releases/test/9-Alpha/Fedora/ppc/iso ---rpm -qa | grep ppc64-util---- ppc64-utils-0.14-1.fc9 ---rpm -ql ppc64-utils-0.14-1.fc9--- (contains no files) Even if you open this rpm with archive manager, you can confirm. --Regards Omar M =Comment: #3================================================= Suzuki Kp <suzukikp.com> - 2008-02-29 00:35 EDT I verified the rpm downloaded from http://download.fedora.redhat.com/pub/fedora/linux/releases/test/9-Alpha/Fedora/ppc/os/Packages/ It also shows the same message. Looks to be a packaging issue
------- Comment From skannery.com 2008-03-05 02:03 EDT------- Redhat Team, Any updates here.. Thanks, Supriya
Yes, it's empty. It's _supposed_ to be empty. It was a dumping ground for a whole load of cruft, and all that cruft has been moved out into separate packages, which ppc64-utils now requires. I'd like to drop the ppc64-utils package from the distro but I lack the wit -- I'm not sure what magic causes it to be installed in the first place, and hence how to ensure that the replacement packages are installed in its place. Especially on upgrades.
Either yaboot requiring or more likely the comps file. To remove on upgrades we can do in anaconda. I'll come up with a patch on the w/e if someone doesn't get there first.
What about yum upgrades? Special cases in anaconda are frowned upon, aren't they?
Special cases are frowned upon in anaconda, yes. Unfortunately, with 'yum upgrade' there's not much we can do since a single package can't really offer an Obsoletes on ppc64-utils. However, with the latest version in rawhide being empty, it won't do harm if people leave it around. If the comps file is updated to have it removed and the replacement packages listed in the base or core install (whatever the name is), the repodata will get updated and people can clean up their systems by doing 'yum list extras' to see what packages have been removed from the distribution but are still on their system. That's a cleanup step I perform from time to time and I think it's acceptable for people taking the yum route for system upgrades.
The current state with the empty ppc64-utils package is reasonable enough. To kill ppc64-utils off for real, we need to get the dependencies right for all the new packages. ppc64-utils is currently required by mkinitrd, and it requires the following packages: yaboot powerpc-utils powerpc-utils-papr ps3pf-utils kernel-bootwrapper I think mkinitrd only really needs kernel-bootwrapper, and then only on iSeries. I don't think anything else requires yaboot or any of the other packages (the utils packages are new). Strictly speaking, we only need powerpc-utils-papr on pSeries (and maybe iSeries). We need ps3pf-utils on PS3, of course. And on a similar note, ideally we'd only install iprutils on pSeries too. yaboot should probably require powerpc-utils. There's more, but keeping the ppc64-utils package around with no files was the safe answer for now.
------- Comment From mohd.omar.com 2008-03-06 01:18 EDT------- I basically searching for mkzImage to create zImage for PPC. I was looking for creating a diskless environment for PowerPCs. mkinitrd --with "${MODULES[*]}" --net-dev "${NETDEV}" --fstab my-fstab initrd-nfs-${KERN_VERSION}.img ${KERN_VERSION} mkzimage vmlinuz-${KERN_VERSION} config-${KERN_VERSION} System.map-${KERN_VERSION} \ initrd-nfs-${KERN_VERSION}.img /usr/share/ppc64-utils/zImage.stub zImage-nfs-${KERN_VERSION}.img How do I get mkzImage for F9Alpha ? --Regards Omar M
We no longer have our own 'speshul' script for this. We use the bootwrapper which comes directly from the kernel, and which is now built as a sub-package of the kernel by using the kernel's 'make bootwrapper_install' target. This uses a script named 'wrapper', used as follows: # This script takes a kernel binary and optionally an initrd image # and/or a device-tree blob, and creates a bootable zImage for a # given platform. # Options: # -o zImage specify output file # -p platform specify platform (links in $platform.o) # -i initrd specify initrd file # -d devtree specify device-tree blob # -s tree.dts specify device-tree source file (needs dtc installed) # -c cache $kernel.strip.gz (use if present & newer, else make) # -C prefix specify command prefix for cross-building tools # (strip, objcopy, ld) # -D dir specify directory containing data files used by script # (default ./arch/powerpc/boot) # -W dir specify working directory for temporary files (default .) This should suffice to replace your above command: wrapper -i initrd-nfs-${KERN_VERSION}.img -o zImage-nfs-${KERN_VERSION].img vmlinuz-${KERN_VERSION}
------- Comment From mohd.omar.com 2008-03-11 01:24 EDT------- David, >>wrapper -i initrd-nfs-${KERN_VERSION}.img -o zImage-nfs-${KERN_VERSION].img >>vmlinuz-${KERN_VERSION} Using this script I am able to create zImage, which worked fine.
Perhaps we could capture this on https://fedoraproject.org/wiki/Docs/Beats/ArchSpecific/PPC
I've added a basic comment about ppc64-utils.
------- Comment From suzukikp.com 2008-03-11 08:16 EDT------- (In reply to comment #22) > David, > > >>wrapper -i initrd-nfs-${KERN_VERSION}.img -o zImage-nfs-${KERN_VERSION].img > >>vmlinuz-${KERN_VERSION} > > Using this script I am able to create zImage, which worked fine. > Since this is NOTABUG and we have a well documented alternate solution available, I am going to reject this one as NOTABUG. Thanks Suzuki