On Mon, 24 Jun, at 10:27:52AM, Thomas B?chler wrote:> Am 24.06.2013 04:10, schrieb Gene Cumm: > > In trying Syslinux-6.00 bios/core/pxelinux.0 with a 3.0.21 kernel, I got" > > > > "No linux boot function registered for firmware > > Booting kernel failed: Bad file number" > > > > Using Syslinux-5.10, the same kernel/initrd succeeds. > > > > Screenshot, kernel and initrd available but I'm figuring this is an > > issue in the BIOS loader not handling things as it should. > > As far as I can see, this is an issue of the BIOS firmware not handling > things at all - there is not even a code path to the function that boots > Linux via BIOS. I can only guess that this is a result of a failed merge > followed by not testing 6.00 on BIOS before releasing it.Urk, sorry about that. This is fixed in 6.01-pre1, which I just released. This isn't the result of a failed merge, but I did (clearly) fail to remember to test booting a kernel under BIOS before releasing 6.00. Apologies. -- Matt Fleming, Intel Open Source Technology Center
Am 24.06.2013 11:25, schrieb Matt Fleming:> On Mon, 24 Jun, at 10:27:52AM, Thomas B?chler wrote: >> Am 24.06.2013 04:10, schrieb Gene Cumm: >>> In trying Syslinux-6.00 bios/core/pxelinux.0 with a 3.0.21 kernel, I got" >>> >>> "No linux boot function registered for firmware >>> Booting kernel failed: Bad file number" >>> >>> Using Syslinux-5.10, the same kernel/initrd succeeds. >>> >>> Screenshot, kernel and initrd available but I'm figuring this is an >>> issue in the BIOS loader not handling things as it should. >> >> As far as I can see, this is an issue of the BIOS firmware not handling >> things at all - there is not even a code path to the function that boots >> Linux via BIOS. I can only guess that this is a result of a failed merge >> followed by not testing 6.00 on BIOS before releasing it. > > Urk, sorry about that. This is fixed in 6.01-pre1, which I just > released. > > This isn't the result of a failed merge, but I did (clearly) fail to > remember to test booting a kernel under BIOS before releasing 6.00.Thanks. It seems kind of inconsequent though: Why is EFI boot defined in efi/main.c, but BIOS boot in libcom32, instead of being part of the firmware definition? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://www.zytor.com/pipermail/syslinux/attachments/20130624/220c9a8f/attachment.sig>
On Mon, 24 Jun, at 11:37:42AM, Thomas B?chler wrote:> Thanks. It seems kind of inconsequent though: > > Why is EFI boot defined in efi/main.c, but BIOS boot in libcom32, > instead of being part of the firmware definition?I explained that in the commit log, The usual way to handle this kind of abstraction would be to move bios_load_linux() to core/bios.c and assign it to .load_linux, but that would necessitate pulling the movebits and shuffler code into the core. For now, leave the BIOS loader where it is and use it as the default. In future we will want to move this to BIOS-specific code (though not necessarily in the core) because, by having it in the generic loader code, it is currently being built for the EFI backends even though it is never used. Historically, the loader code for BIOS has always been part of libcom32. -- Matt Fleming, Intel Open Source Technology Center
On Mon, 24 Jun 2013, Matt Fleming wrote:> On Mon, 24 Jun, at 10:27:52AM, Thomas B?chler wrote: > >> As far as I can see, this is an issue of the BIOS firmware not handling >> things at all - there is not even a code path to the function that boots >> Linux via BIOS. I can only guess that this is a result of a failed merge >> followed by not testing 6.00 on BIOS before releasing it. > > Urk, sorry about that. This is fixed in 6.01-pre1, which I just > released. > > This isn't the result of a failed merge, but I did (clearly) fail to > remember to test booting a kernel under BIOS before releasing 6.00.What could help here is to announce an imminent release on this mailinglist. In the past Peter communicated his wish to release a few days, or a week beforehand which allowed me to test the compilation and packaging on RHEL, and test a few boots in order to test the packages. In this case I was surprised (yet pleased) to hear about the 5.10 and 6.00 release. Announcing doesn't guarantee anything (as people might have no time to test it within the given timeframe) but it allows some to test the pre-releases one more time. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, contact at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
On Mon, 24 Jun, at 11:55:08AM, Dag Wieers wrote:> What could help here is to announce an imminent release on this > mailinglist. In the past Peter communicated his wish to release a > few days, or a week beforehand which allowed me to test the > compilation and packaging on RHEL, and test a few boots in order to > test the packages. > > In this case I was surprised (yet pleased) to hear about the 5.10 > and 6.00 release. Announcing doesn't guarantee anything (as people > might have no time to test it within the given timeframe) but it > allows some to test the pre-releases one more time.Sure, that seems worthwhile. I'll bear this in mind for the next releases. -- Matt Fleming, Intel Open Source Technology Center