> > > Short summary: > > I think bug #45 > > http://bugzilla.syslinux.org/show_bug.cgi?id=45 > > "Regression in Syslinux 6.xx. Doesn't 'hand over' to linux kernel" > > can be reproduced using VirtualBox 4.1.x while trying to boot a > > relatively-newish Linux kernel. > >Just to report an update... After confirming that the same behavior can be reproduced under old versions of qemu too, there are now patches committed (commit a06818d and some prior ones, since 6.03-pre3) to the Syslinux 'master' branch (at least in the git.zytor repo). Some tests were already performed, suggesting that the problem should be solved. It might be relevant (for Syslinux testers) to mention that Syslinux 6.03-pre4 will fail (under any conditions). The next 6.03-prerelease should include the patches. To The Syslinux Team, my gratitude. Regards, Ady.
Michael D. Setzer II
2014-Mar-01 06:57 UTC
[syslinux] VirtualBox 4.1.x can reproduce bug 45
On 1 Mar 2014 at 5:42, Ady wrote: From: Ady <ady-sf at hotmail.com> To: syslinux at zytor.com Date sent: Sat, 1 Mar 2014 05:42:25 +0200 Priority: normal Subject: Re: [syslinux] VirtualBox 4.1.x can reproduce bug 45 Send reply to: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>> > > > > Short summary: > > > I think bug #45 > > > http://bugzilla.syslinux.org/show_bug.cgi?id=45 > > > "Regression in Syslinux 6.xx. Doesn't 'hand over' to linux kernel" > > > can be reproduced using VirtualBox 4.1.x while trying to boot a > > > relatively-newish Linux kernel. > > > > > Just to report an update... > > After confirming that the same behavior can be reproduced under old > versions of qemu too, there are now patches committed (commit a06818d > and some prior ones, since 6.03-pre3) to the Syslinux 'master' branch > (at least in the git.zytor repo). > > Some tests were already performed, suggesting that the problem should > be solved. > > It might be relevant (for Syslinux testers) to mention that Syslinux > 6.03-pre4 will fail (under any conditions). The next 6.03-prerelease > should include the patches. >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?> To The Syslinux Team, my gratitude. > > Regards, > Ady. > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux > Please do not send private replies to mailing list traffic. >+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes at kuentos.guam.net mailto:msetzerii at gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC at HOME CREDITS ROSETTA 11936336.446682 | SETI 20372342.618395 ABC 16613838.513356 | EINSTEIN 18320952.977648
> > 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.