[syslinux] VirtualBox 4.1.x can reproduce bug 45
ady-sf at hotmail.com
Sat Mar 1 01:54:06 PST 2014
> 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.
More information about the Syslinux