The fix for Bug #472981 that was supposed to make it boot on grub broke memtest's ability to boot from syslinux. This means memtest on the Fedora installer and Fedora LiveCD's do not work from the syslinux menu. syslinux says the kernel image is corrupted. Curiously enough, I haven't seen memtest86+ fail booting from grub as mentioned in Bug #472981. I might note this is *exactly* why I suggested the new maintainer talk to upstream about upstreaming these proposed changes. They might have told us that these changes would break non-grub ways of booting it like syslinux. It appears that it breaks PXE netboot memtest as well. [warren@newcaprica tmp]$ file memtest86+-2.11-3.fc11.x86_64/boot/memtest86+-2.11 memtest86+-2.11-3.fc11.x86_64/boot/memtest86+-2.11: Linux x86 kernel [warren@newcaprica tmp]$ file memtest86+-2.11-6.fc11.x86_64/boot/memtest86+-2.11 memtest86+-2.11-6.fc11.x86_64/boot/memtest86+-2.11: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped memtest86+-2.11-3.fc11 boots successfully from syslinux. memtest86+-2.11-6.fc11 fails to boot. If a fix cannot be found before the Fedora 11 development freeze, we should revert to -3, because it is more important that the install media memtest86+ works. The -3 did successfully boot and run from grub on many machines.
We could have two different rpm versions for memtest86+. Maybe memtest86+-2.11-3 and memtest86+.elf-2.11-6 Is this acceptable?
How about memtest86+ .src.rpm build two copies of itself, the "old" type at the current filename, and ELF at a new filename? Then memtest-setup configures only the ELF file.
I built another version http://orion.lcg.ufrj.br/RPMS/src/memtest86+-2.11-7.fc10.src.rpm It should create two rpms: memtest86+-elf-2.11-7.fc10.x86_64.rpm memtest86+-2.11-7.fc10.x86_64.rpm I tested the elf version and it is working for me. Now I have a /boot/memtest86+-elf-2.11, and the two scripts were adapted for using the new name. Could you please rebuilt the rpms and test the bin version? The bin version only has three files: /boot/memtest86+-2.11 /usr/share/doc/memtest86+-2.11 /usr/share/doc/memtest86+-2.11/README Of course, one can install both versions, if wanted. Thanks.
Is it really necessary to have two separate binary RPMS?
BTW, have you asked upstream about the original bug? Presumably it is a problem that they need to solve? Please talk to upstream. The -3 binary worked fine on all of my systems via grub. Perhaps this bug is only on rare systems? You might also want to consider trying mkelfimage to make an ELF bootable image during memtest-setup instead of shipping a separate binary. Have you tested that? wraplinux will also wrap a kernel image and output ELF. mklefimage however has the benefit that it boots on coreboot systems as well.
(In reply to comment #5) > BTW, have you asked upstream about the original bug? Presumably it is a > problem that they need to solve? Please talk to upstream. I saw the problem reported on the x86-secret forum a couple of years ago (http://www.x86-secret.com/), but the thread does not exist any more. The solution came from there too. Therefore, I am pretty sure they know about this issue. > > The -3 binary worked fine on all of my systems via grub. Perhaps this bug is > only on rare systems? I only use Intel motherboards. They are very common. The problem is worse with with newer BIOS. The best explanation for the problem can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319837#21 > > You might also want to consider trying mkelfimage to make an ELF bootable image > during memtest-setup instead of shipping a separate binary. Have you tested > that? No. I have never used mkelfimage before. I think we need a temporary solution that works either for the install media or a grub.conf on a workstation. Having two binaries should allow us to automatically update grub.conf, the same way it is done for new kernels. Specially if grubby is improved a bit. The two binaries can be in the same rpm if you prefer.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319837#21 "Memtest uses the old format." Then why can't memtest86+ instead be fixed to use the new kernel format? That seems like the proper fix? Until the proper fix can be done, shipping a second memtest86+ binary in the same RPM used by memtest-setup script seems OK. Please do this for now so Fedora 11 can ship. Just be sure the original binary is at the old filename.
(In reply to comment #7) > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319837#21 > "Memtest uses the old format." > > Then why can't memtest86+ instead be fixed to use the new kernel format? That > seems like the proper fix? Anything can be fixed, once there is good will. In memtest86+/memtest86 case, I think the developers do not see booting via grub as an important issue. Their main target is any type of external media (CD, floppy, or pendrive). > > Until the proper fix can be done, shipping a second memtest86+ binary in the > same RPM used by memtest-setup script seems OK. Please do this for now so > Fedora 11 can ship. Just be sure the original binary is at the old filename. I changed the .src.rpm and both binaries are in a single rpm. My question is, should I update grub.conf automatically? Since you are going to use the bin version, if I update grub.conf for adding an entry for the elf version, do you see any issue for the install media? When the F11 version is ready, I will see with the developers what can be done to fix memtest86+ once for all. http://orion.lcg.ufrj.br/RPMS/src/memtest86+-2.11-7.fc10.src.rpm
No, do not update grub.conf automatically. Jeremy Katz said this is not desired, and you also have the problem of it adding as the first entry in grub.conf. Don't post packages here. Just commit it to rawhide.
Done.
memtest86+-2.11-7.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/memtest86+-2.11-7.fc10
memtest86+-2.11-7.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/memtest86+-2.11-7.fc9
The long-term bug is filed as Bug 49444.
memtest86+-2.11-7.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update memtest86+'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3511
memtest86+-2.11-7.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update memtest86+'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3526
Oops, I mean Bug #494448.
Should this be closed out?
Did somebody test it?
(In reply to comment #18) > Did somebody test it? I tested the elf version, booting via grub. No problem. Have you tried booting from syslinux with the bin version? I also posted a message on memtest86+ forum, but no answer yet.
Putting on Preview and marking as NEEDSRETESTING
Bad news, new liveimg built today, it is still broken. Investigating.
Works for me, using the staged Preview i686 live image. Maybe your build is bad?
imgcreate/live.py def __get_memtest_stanza(self, isodir): memtest = glob.glob(self._instroot + "/boot/memtest86*") if not memtest: return "" shutil.copyfile(memtest[0], isodir + "/isolinux/memtest") The glob is pulling in the wrong memtest binary that is incapable of booting from syslinux. I'm rebuilding memtest86+ with the elf binary renamed to workaround this issue. The elf binary will need to disappear when Bug #494448 is fixed later.
OK, that wasn't it. This exposed two separate bugs. * memtest86+ uninstall no longer removes the grub.conf stanza, fixed in -9. * livecd-iso-to-disk was failing to overwrite the memtest binary. Curiously, after blowing away the directories and writing from scratch, I cannot reproduce this bug again. =( In any case, I'm pretty sure this is fixed. Closing.
memtest86+-2.11-9.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
memtest86+-2.11-9.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
After updating memtest86+ in F10 from 2.10 to 2.11, the old Memtest86+ stanza in grub.conf was NOT deleted, unlike the previous version's behavior. However, after running memtest-setup and fixing grub.conf, if I then delete the memtest86+ package, THAT causes the Memtest86+ stanza to be deleted. Is this behavior intentional?
We are shipping now two versions of memtest86+: elf-memtest86+-2.11 and memtest86+-2.11 The first one is intended to be used for booting from grub, and memtest-setup produces an entry like this for it: title Memtest86+ (2.11) root (hd0,0) kernel --type=netbsd /elf-memtest86+-2.11 The previous version did not have "elf-" in its name, and this is the reason for the stanza not being deleted in the update process, I guess. However, from now on, everything should work as before, for future new versions.