Bug #494157 it became necessary to ship a second build of memtest86+ in the package because the original build works with syslinux, while it fails on some systems when booted from grub. The second build should work from grub. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319837#21 This bug explains the reason for this, essentially memtest86+ uses the old zImage kernel format. It must be fixed to build into the new kernel format. When this is fixed, our memtest86+ can eliminate the second binary.
memtest86+ is based on a fork of an ancient Linux kernel. It builds into the zImage format. We need to make it build as the newer bzImage format which is capable of booting with both syslinux and grub on all systems.
memtes86+ only has a forum ("features requests and bug fixes requests" both point to the forum). I posted a message in the forum in 04/15/2009, which has been viewed 275 times. In this post, I described the problem, and mentioned the patch we are using. However, I only got one reply: "Is the patch provided there solve your problem ?" In my opinion, the developers do not consider this a bug.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Moving back to rawhide. Starting to investigate.
So after looking at this fairly extensively... Converting from zImage to bzImage is NOT trivial. Like many other folks apparently, I'd assumed a big part of the change was the compression type used (i.e. gzip -> bzip2). Not so. bzImage is short for 'big zImage', the difference is how the image is decompressed into system memory. A bzImage is split into multiple areas of memory when its decompressed, and requires a fair amount of assembly-level changes to implement this. To make it more interesting, memtest86+ would have to be adapted as well, to understand where things are now being decompressed, so as to not overwrite those areas when doing memory testing. In short, this involves a LOT of work and a lot of regression-testing, to the point where I don't think its worth the effort. The current two-image solution works and really doesn't cause any major hardships on anyone.