58 replies to this topic

[Wonko the Sane]

what else can I do when the developers make no fixed version available?

Use a post-processing approach.

I mean, since you already are running RMPREPUSB, wouldn't it be easier to insert in it a check IF the grub4dos PBR contains the 5 bytes as "GRLDR", and IF YES, replace them?

This way you keep using an "official" release AND your app is compatible BOTH with the current "botched" versions AND with future hopefully "fixed" releases.

Same approach used by fuwi to "fix" the problems with the HP USB Format tool (which has not source code available).


Wonko

[steve6375]

I thought about that, but it would mean that the bug would only be fixed when using RMPrepUSB which would not suit people wanting to use grubinst separately - besides I stopped believing in vinegar and brown paper when I was 3!

[Wonko the Sane]

I thought about that, but it would mean that the bug would only be fixed when using RMPrepUSB which would not suit people wanting to use grubinst separately

Yep , but how would people know to use your particular "fixed" grubinst.exe?
And what would happen when (and if) the new grubinst.exe is released, fixed for the PBR and with added features?
Would people use the new "right" version or remain using your unofficial patched one?

You could provide a "fixer" (nothing but a hex edit/patch) capable of post-processing the PBR without using RMPRREPUSB (or simply give the info, after all it's a 5 key presses in a hex/disk editor).

besides I stopped believing in vinegar and brown paper when I was 3!

For the benefit of those less fluent in English:
http://en.wikipedia...._(nursery_rhyme)

The remedy was also cited by Charles Dickens:
http://quezi.com/4066

and appears like having been used (successfully?) for decades....


Wonko

[Icecube]

@ steve6375
Did you ever try to patch those bytes in the VBR in memory only? So that you still have the GRLDR string in the VBR on disk and only patch the string in memory whem you chainload io.sys. Or won't this way work (VBR read again from disk by io.sys instead of from memory)?

[steve6375]

@ steve6375
Did you ever try to patch those bytes in the VBR in memory only? So that you still have the GRLDR string in the VBR on disk and only patch the string in memory whem you chainload io.sys. Or won't this way work (VBR read again from disk by io.sys instead of from memory)?

No, I didn't try it in the end. Even if it worked it would mean a fix in every menu.lst that uses MS-DOS and so could not be included in RMPrepUSB but would have to be included/ammended by the user themselves and most would not bother to find and fix the problem.
I must admit I am slightly suprised by the attitude of the grub4dos/grubinst maintainers. Recently, two long-standing and serious bugs (i.e. no boot) in grub4dos/grubinst/grldr.mbr code have been reported and the maintainers do not seem to consider them important enough to fix them. Instead they offer that I make a new divergent stream for the code source? I am not at all experienced in linux or using and maintaining such code and if I tried to do it, I would probably do it wrong!

1. MS-DOS does not boot when grub4dos code installed to VBR
2. Acer Travelmate BIOSes (and probably many others too) do not like the MBR code start bytes used by grub4dos and refuse to boot.

Surely these two bugs are worth fixing in the main code source files? Apparently not

[Icecube]

No, I didn't try it in the end. Even if it worked it would mean a fix in every menu.lst that uses MS-DOS and so could not be included in RMPrepUSB but would have to be included/ammended by the user themselves and most would not bother to find and fix the problem.

Since I don't have any MS-DOS here, and since it isn't free available, I can't test it myself. I would like to know if my approach works, so it can be used in chain.c32 of Syslinux to automatically patch the necessary bytes in memory when io.sys is chainloaded. So if it isn't to much trouble for you to test...

[Wonko the Sane]

Since I don't have any MS-DOS here, and since it isn't free available, I can't test it myself. I would like to know if my approach works, so it can be used in chain.c32 of Syslinux to automatically patch the necessary bytes in memory when io.sys is chainloaded. So if it isn't to much trouble for you to test...

Just for the record, the syslinux wiki recommends to get a floppy image from bootdisk.com... :
http://syslinux.zyto...S_floppy_images






Wonko

[tinybit]

I tend to think the leading "0xEB" byte should not change. It is not a sin or a crime to use 0xEB here, despite Acer will hang it up.

I think it is a bug from Acer. I even would like to consider it a potential attack on boot-loaders/boot-utilities such as grub4dos and fbsinst. (Edit: I should add that the real attacker is not necessarily Acer, or even Acer could be also a "victim".)

If we change 0xEB to other values, many things will be affected. Triple MBR, or some third party tools to check existence of grldr-MBR, ....

I think we can face the reality and accept the reality that grldr-MBR won't work on Acer. Users may choose other MBRs such as syslinux or MS-DOS, and then run grub4dos afterwards.

[steve6375]

If we change 0xEB to other values, many things will be affected. Triple MBR, or some third party tools to check existence of grldr-MBR, ....

If 3rd party tools check for the existence of grub4dos mbr by checking the first byte of the MBR then they are as bad coders as the Acer BIOS writers! I have modified a new version of grubinst to use EB and released it with RMPrepUSB beta versions. I have also been using it for a few weeks now. I agree it may be too risky to change the main release just yet, but maybe in time, if we get reports of my version being more compatible than v1.1, you would consider changing it?

PS. My version also boots to MSDOS via grub PBR code, which 1.1 does not (due to the GRLDR000 string bug)!