> On 06/28/2013 05:32 PM, Patrick Verner wrote: > > I have updated syslinux in Parted Magic's test version to the 5.10 release. > > With 4.06 I booted plop like this: > > > > LINUX /boot/plpbt/plpbt.bin > > > > Now it says /boot/plpbt/plpbt.bin... ok > > Booting kernel failed: Invalid argument > > > > Other "extras" like IPXE, HDT, memtest86+, chntpw, Super Grub Disk, etc... > > all work with 5.10. Revert to 4.06 and plop works again. > > > > Is this a problem with syslinux or plop? > > > > I suspect this is the "ancient kernel" problem again. Do you have a > point to the specific plpbt.bin you are using? > > -hpa >If with "ancient kernel" you are referring to the memtest(86|86+) issue, I don't see the same *exact* problem / behavior. FWIW, let me give you some examples, with Syslinux 6.01-pre5 BIOS, and/or with 5.11-pre3, testing with the same VBox 4.2.14 VM. I have also deleted the ".bin" filename extension from the kernels. Note: In this context, when I mention "plop" here, I am referring to "PLoP boot manager" only, and not to other products which include the word "PLoP" in it from the same developer. _ I am able to boot ISOLINUX -> memtest, but not ISOLINUX -> plop. _ memtest seems to fail mostly from PXELINUX, or when using linux.c32. _ Some versions of memtest seem to start booting (from ISOLINUX, for example) but then hang within memtest itself (possible memtest bug?). OTOH, when trying to boot plop, is Syslinux the one refusing to boot the plop kernel at all, giving some error message. BTW, to be sure you can see the exact error message, you might need to use CLI; using menu.c32 might immediately erase the error message from the screen, going back to display the Syslinux menu. Note that the error message is not the same, depending on whether linux.c32 was used or not. _ Using MEMDISK -> plpbt.img (FAT12 bootable floppy image with plop as boot loader in it), plop can be booted. This is a particular case, since plop itself is a boot loader; this is not applicable to memtest. So the problem with plop seems to be trying to boot the kernel directly, from whichever variant of Syslinux 5+, while memtest can still be booted directly with at least some variants of Syslinux 5+. Using MEMDISK, plop can be booted. Of course, please keep in mind that these tests were performed in one VM only, and different real hardware might behave differently. Regards, Ady.
On Sat, Jun 29, 2013 at 3:04 PM, Ady <ady-sf at hotmail.com> wrote:> If with "ancient kernel" you are referring to the memtest(86|86+) > issue, I don't see the same *exact* problem / behavior.My cuent understanding is as follows: HPA is using the label "ancient kernel" for any kernel that has a hard-coded load address and that linux.c32 and all 5.xx+ (they're actually the same code) are less likely to be able to succeed in loading these kernels due to how the core/linux.c32 responds to the memory map passed to it by the BIOS(INT 15h E820h). Let's say the kernel must be loaded to 0x100000 but the core sees that the memory at that address is reserved (and not by itself). At this point, the core/linux.c32 refuses to execute it for safety reasons. My guess at the PXE-smasher is that the BIOS doesn't properly report the memory that the PXE stack uses and the core/linux.c32 loads on top of this used memory, corrupting the environment. Ady, hope this helps. -- -Gene
> On Sat, Jun 29, 2013 at 3:04 PM, Ady <ady-sf at hotmail.com> wrote: > > > If with "ancient kernel" you are referring to the memtest(86|86+) > > issue, I don't see the same *exact* problem / behavior. > > My cuent understanding is as follows: HPA is using the label "ancient > kernel" for any kernel that has a hard-coded load address and that > linux.c32 and all 5.xx+ (they're actually the same code) are less > likely to be able to succeed in loading these kernels due to how the > core/linux.c32 responds to the memory map passed to it by the BIOS(INT > 15h E820h). > > Let's say the kernel must be loaded to 0x100000 but the core sees that > the memory at that address is reserved (and not by itself). At this > point, the core/linux.c32 refuses to execute it for safety reasons. > > My guess at the PXE-smasher is that the BIOS doesn't properly report > the memory that the PXE stack uses and the core/linux.c32 loads on top > of this used memory, corrupting the environment. > > Ady, hope this helps. > > -- > -Gene > _______________________________________________I understand the "hard-coded memory address" concept. I am just trying to help by describing different behaviors that might point to different or alternative workarounds / solutions. Regarding linux.c32, it is not "exactly" the same code as 5.xx+. Certainly not from the point of view of the simple user, seeing that the behavior is different. Part of the behavior I described is also related to linux.c32 as of 4.06, and although it might attempt to behave as 5.xx, we all know there are several months and commits in between. Even within Syslinux 5.xx+, linux.c32 behaves differently than when using the LINUX directive. As example, see the 2 different behaviors I described before in this same email thread, regarding PLoP manager kernel when booted from Syslinux 5.11-pre3 and from 6.01-pre5 respectively (not just the error message itself - which might be understandable - but also when started from menu.c32: one error message is immediately overwritten by the automatically reloaded menu, while the other is displayed and it ends in CLI). So, by providing those different behaviors and the specific error messages, I am hoping there could be a chance of some workaround / solution. Otherwise, either: A_ Those "hard-coded memory address" kernels won't be usable; or, B_ Users and/or distros needing / wanting those kernels won't update Syslinux; or, C_ Some form of chain-loading from Syslinux 5+ to prior versions or to other boot loaders will be necessary, just to be able to execute those ""hard-coded memory address" kernels. BTW, to add to the behaviors I described before, I also tried ifplop.c32 (BIOS) from ISOLINUX 6.01-pre5 in Vbox 4.2.14, and it behaves in a third (or fourth) way: _ from CLI, it's the same as "LINUX plop": "Booting kernel failed: Invalid argument"; _ from menu.c32, the same error message is shown, but then it gets to CLI. As a remainder, "LINUX plop" from menu.c32 immediately overwrites the error message, going back to display the menu. Hopefully, all these descriptions are helpful so to find some workaround / solution, at least for some of those "ancient kernels" (which are still useful and very popular). Best Regards, Ady.
On 06/30/2013 09:45 AM, Gene Cumm wrote:> > My cuent understanding is as follows: HPA is using the label "ancient > kernel" for any kernel that has a hard-coded load address and that > linux.c32 and all 5.xx+ (they're actually the same code) are less > likely to be able to succeed in loading these kernels due to how the > core/linux.c32 responds to the memory map passed to it by the BIOS(INT > 15h E820h). >Not quite. "Ancient kernel" means Linux kernel boot protocol < 2.00. This hard-codes memory use at address 0x90000, which is almost universally occupied by the PXE stack. What we need to do is estimate how much memory will be freed up by the PXE stack on unload -- unless we are doing keeppxe -- and if we have used that memory and the unload fail... print a warning and run anyway? -hpa