Bug 376310

This is not the whole story.

It would also be preferable (but probably worth another bug) for kernel packages to automatically run mkzimage on kernel installation, otherwise security updates and updated kernels may not actually be deployed properly.

Juhliarik, yours or Kernel-maintainers'?

The bug is about installing kernel. I don't know decide if it is bug of bootloader or kernel. 

Calling mkzimage can finish like (bug# 374693):

iMac:~ # mkzimage --initrd /boot/initrd --vmlinux /boot/vmlinux --output
/boot/zImage
board_type NewWorld kernel_type 32bit zimage_sh make_zimage_pmac_newworld.sh
output file /boot//zImage is 2773200 bytes too large
booting from openfirmware prompt will not work
iMac:~ # 

Alexander could you decide what to do with this bug?

Reading the output of the command executed in comment #3 tells that the produced output file is 2773200 bytes too large.


Could it be that the partition where /boot is located is simply too small?

(In reply to comment #4 from Alexander Osthof)
> Reading the output of the command executed in comment #3 tells that the
> produced output file is 2773200 bytes too large.
> 
> Could it be that the partition where /boot is located is simply too small?

NewWorld Macs have a size limit on the size of the bootable image. But, you have yaboot to work around it - just don't boot the zImage, boot Yaboot and use that to boot the vmlinux and load the initrd seperately.

Regardless, the bug has been posted because without a zImage with a combined initrd, Pegasos and Efika can't boot (yaboot is not entirely usable). On NewWorld Macs, yaboot can run with the files in the kernel package and a seperate initrd.. so it's not exactly a requirement to generate the image on ALL platforms, although it wouldn't hurt as long as on NewWorld and other systems, yaboot was still the preferred loader.

How about this. Can it be determined if the bootloader is installed or not, and then mkzimage is run if it's not? If you have yaboot, it's a waste of time to generate the combined zImage+initrd, on some other systems it's also pretty useless. It's only really common, I should expect, to disable the boot loader on Pegasos and Efika, and the disabling has already been fixed.

The different PPC boards can be detected by hwinfo, this is already used in many situations by the installer (YaST) and lilo (the boot loader installer / configurator package on PPC, which mkzimage is part of). The output of 'mkzimage' boots fine on Pegasos and EFIKA machine, and as EFIKA has no and Pegasos only partial support for yaboot, 'mkzimage' is the preferred method.

not critical

I have updated lilo to handle efika as pegasos

Hi Olaf,

This isn't working in Factory, and never worked on 11.0.

I am working on a bootloader solution (a modification of YaST2-bootloader possibly, plus some support utilities for a Forth boot menu) which should solve a bunch of stuff but it will not be ready for 11.1 and I doubt it would make it onto the CD for release anyway.

I would really like to know what you actually patched to handle pegasos in the first place and where you modified YaST2-bootloader or LILO to support mkzimage (and how you detect Pegasos or Efika, since both of them can be detected in the same way by looking at /proc/device-tree/openprom/CODEGEN,vendor = "bplan" so the check should not even have had to be updated?) 

If anything I would like to patch it back out when I have finished my support tools, but it is also a good start on where to throw patches at to gain support for the new bootloader tools (the idea is to mimic "grub" as much as possible, so that mkzimage can be run, forth scripts can be generated from efika.forth, a custom menuing solution can be installed and updated). I have had a chat with Josef Uhliarik who agreed to at least help.

I would much rather take on the burden and responsibility myself if possible so as not to waste time during the release process, however a couple questions remain; where is the canonical source for YaST2-bootloader and what did you modify to fix this patch?

Bump, it is still not working.

The "correct solution" to building a zImage kernel is here;

http://en.opensuse.org/Efika#Making_a_zImage_Kernel

bootloader should also remove old zImage-version files when it is doing a kernel upgrade.

I'd really like to know what is exactly going on with this and how Efika and Pegasos are detected (and why it doesn't work). I grabbed the lilo source rpm from powerpc.opensuse.org and had a browse around.

I see a few spelling mistakes in many files - mkimage.sh and mkimage_zimage_chrp.sh (copy & paste abuse, "diretory" instead of "directory", the CHRP script has "pSeries" in it's help text) and also that Efika detection is set to


 		  *EFIKA5K2*)	board_type="pmac" ;;

Which is just plain wrong.

There are also a few inefficiencies; you do not need the RS6000 note added to Efika and Pegasos kernels.

I simply cannot find the place in YaST2-bootloader or Perl-Bootloader which actually affects Efika and Pegasos though. Any hints here?

Created attachment 255953 [details]
Boot Menu Forth Script

yast or perl bootloader have no code for efika or pegasos.
board_type does not really matter, it affects the link address. its now 16mb instead of 64mb.

Can I make a case for fixing mkzimage so that it treats Efika properly? pmac is so wrong I don't know what to say.. this is causing mkzimage to require an extra argument when it kind of shouldn't (it is a kernel mishap that /proc/cpuinfo doesn't mention CHRP)

We would really like some code somewhere that automates bootloader stuff for Efika and Pegasos. I've been hammering away at something but the organization of yast2-bootloader and perl-bootloader are really disgusting.. some of the nastiest perl I have ever read. While the concept is sound (treat every bootloader as LILO) it takes so long to even find the part of the code that could even support the "ppc" bootloader (which I still did not find).

Is there a hint as to the code that parses out lilo.conf and generates bootloaders (for instance prep partitions, yaboot configuration etc.) so I can try and submit a patch for efika/pegasos to maintain this method?

I'm still beating my head on the desk over this.

yast2-bootloader has ample code to support iSeries and PREP with mkzimage, and it's well known that yaboot simply doesn't work on most configurations (here it installed /yaboot file but it's in the root directory, not /boot, and the firmware may not be able to read the root directory which is why /boot exists in the first place).

Running yaboot from the disk on my Pegasos does not successfully boot, and it's running a 1.2 firmware (i.e. production) and ext3 (with 128 byte inode) partitions throughout (I accepted the default partitioning proposal in 11.1)

Can't we just treat Efika/Pegasos or any Genesi/bplan machine exactly the same?- let's remove the dependencies on specific board names, let's assume yaboot needs mkzimage to be run like yast2-bootloader for PREP and iSeries does, and that all Genesi systems will ship with "broken" firmware and everyone would prefer just to boot the zImage directly)?

yast2-bootloader and /lib/lilo/ etc. scripts all detect Efika and Pegasos just fine.. just some wrong decision has been made about what these boards SHOULD run. This is just not the reality, though, and no amount of breaking Linux distributions to try and "coerce" firmware teams into releasing updates should be done, as it annoys users and causes systems to be unbootable even after installation.

All this running around working out workarounds and driver updates to resolve issues with a 3 year old decision to force people to try and use yaboot when it would clean up and code fix a lot of problems by simply not supporting it.. it simply makes me want to cry  with frustration that nobody can see the real issue here, which is that trying to imply that yaboot is the standard bootloader is both 1) not born out by the code in the ppc bootloader support since it can support mkzimage just fine and 2) never going to work this way anyway

Created attachment 263044 [details]
lilo spelling fixes

Simply fixes the spelling bugs in mkzimage scripts

The version with which you had the bug is now obsolete. I'll close this as NORESPONSE. If you can still reproduce it in current 11.4, please reopen the bug and move it to the appropriate version. Thanks!