[syslinux] VirtualBox 4.1.x can reproduce bug 45

[Ady]

> 
> I recall an issue with VirtualBox and a version 6.x some time ago, but then a 
> newer version of VirtualBox worked fine with it. The message mentions 
> version 4.1.x, but I'm using 4.3.6 and 4.3.8 was just released. Is there a 
> reason the 4.1.x version is being used?
 
Note: This specific email is not about the issue in Syslinux, but 
about the above question about VBox.

Short answer: There is no particular reason to choose one version of 
VBox over others. Keep using whichever you want.

Just for the curious ones, the (longer) story...

Your wording ("is being used") might imply that there is some 
specific reason for users / Syslinux testers / developers to rather 
consistently use version 4.1.x of VBox over others. This is not the 
case, so let me clarify.

Indeed, for over a year VBox 4.1.x has been unusable for testing 
Syslinux 6.xx (the behavior might have also been affecting Syslinux 
5.xx; I don't accurately recall). When the problem initially showed 
up, VBox 4.2.x was released and the assumption (back then) was that 
VBox 4.2.x solved an issue that was present in prior versions.

I have been experiencing crashes with Vbox 4.2.x (in this case, in a 
Windows host) since its release. Downgrading back to 4.1.x always 
worked OK (except for Syslinux 6.xx), and "upgrading" again to VBox 
4.2.x brings the same crashes again.

After downgrading back to VBox 4.1.x yet again, I took a shot at 
testing Syslinux 6.xx under it, again, hoping I could avoid the 
crashes in VBox 4.2.x by keeping version 4.1.x. While testing, I 
noticed that the behavior was similar to some reports about Syslinux 
6.xx failing in real hardware, while Syslinux 4.xx works as expected 
(with every other condition being the same).

Testing with qemu 0.11.1 resulted in the *same* behavior: Syslinux 
4.xx worked, and Syslinux 6.xx did not. Thus, the tests negate the 
initial assumption (from over a year ago) that VBox 4.2.x seemed to 
solve some problem present in VBox 4.1.x that was just incidentally 
being triggered by Syslinux 6.xx.

We could also say that VBox 4.2.x seemed to be "more flexible" than 
VBox 4.1.x with regards to Syslinux 6.xx; the latter (4.1.x) froze 
while the former (4.2.x) kept going (that is, until VBox 4.2.x 
crashes in my system).

So, to answer Michael's question... The reason to test the problem 
with VBox 4.1.x and qemu 0.11.1 was that these particular versions 
were able to replicate the problematic behavior seen on some real 
hardware, while newer versions did not.

The result: Syslinux 6.03-pre5 is out.

Regards,
Ady.