Bug 494157

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.