> If I may... If I were to say something like "Syslinux doesn't boot", I > would mean that I cannot even get to a simple Syslinux's "boot:" > prompt. In other words, I would mean that _Syslinux_ (in one of its > variants / family members) is failing to boot. Whether the problem is > in Syslinux itself or in some other area (HW, FW, user error, > inadequate configuration...), that would be the first troubleshooting > matter.I don't think I bluntly stated it this way. If I did, I apologise. I do admit that there are a few issues being discussed that maybe should have their own thread. Right now I have the following issues discussed in these two threads i started last week: 1) qemu + ipxe.rom + syslinux = 0xC (discussed in the other thread) 2) HP FW + ipxe.efi + syslinux = 0xC (also discussed there) 3) multinic (solved) 4) crashing when multinic fails 5) crashing when vesalinux fails 6) possibly some stupidity on my part with lib*.c32 so I have to retest 5. 7) suddenly solving 4 after recompiling with extra debugging info. 8) a possible problem with printf not working in EFI mode 9) running out of allocated time (not really a syslinux issue) (Where crashing == exceptions + stack traces, sudden reboots, etc) I'm having a hard time keeping track of this myself. I can imagine it's even more difficult to follow if you're just lurking in the list. I put number 1 and 2 on hold, by the way. The solution (reading three threads and drawing my own conclusions from there) is too time consuming for me. I'll wait for the official ipxe to include the necessary stuff and will try to find some time by then. Did I already mention that I had to learn more about git than I needed the past few years? ;-)> Problems with vesamenu.c32 (in BIOS too, but especially in UEFI) are > _not_ a surprise :O. Although we yet don't know whether it is related > to the multi-nic feature, we should probably not assume such relation, > and the investigation should be focused, IMHO, on narrowing down what > does trigger the behavior, and what does not.The only relation I could find was that something fails, the system crashes instead of printing an error and failing gracefully...> Therefore, IMHO, the problem is not exactly defined as a "booting > problem in Syslinux" (in the same sense as the multi-nic issue was). > Obviously, it is something related to "booting", but it is not the same > as "Syslinux fails to boot". Clearly stating which step / feature / > component is failing (vesamenu.c32 in this case) is essential, whether > you add some debugging "prints" or not.I am trying to find out whether vesamenu.c32 was crashing or the code that was loading/starting vesamenu.c32. I haven't found that out yet.> Let me state this clearly: your efforts / feedback / reports / > contributions are useful and appreciated. I was just trying to make an > important distinction between something like "my problem is that > ldlinux.e64 is not being loaded" and "vesamenu.c32 is making my booting > experience less enjoyable".Thanks! ;-) I think Gene and Patrick were following me when the exchange went from the first case to the next one. Unfortunately the thread spread out like a tree, so if you're reading them by reference instead of chronological, the confusion is understandable.> I sincerely understand the desire to have > vesamenu.c32 working "as it should" (hey, I am still waiting for lss16 > and the CLI to work as expected, for about 3 years now :), but if we > are troubleshooting, I think we need to be clear about the (source of > the) problem; right?> What do you mean with "nope"? I think I saw some IPAPPEND somewhere; am > I wrong? Am I mixing email threads (again)?No you're right. Is IPAPPEND family of SYSAPPEND? I'm not so fluent in syslinux configuration yet. And I just discovered how loading just menu.c32 instead of vesamenu.c32 stopped the machine from crashing. I really haven't had time to dig deeper into the 'why' since discovering this. I also understand that I need to learn more about the configuration parser now..> Or perhaps you meant that you have triple-checked and thoroughly tested > that strange behavior we saw last month regarding some "space-like > characters" and concluded, without a doubt, that such problem does not > exist in your scenario / hardware?Uh oh... more reading to do for me. I did not fully understand your question there. But the menu entry is working. If syslinux starts and menu.c32 loads, all menu entries work perfectly fine. No crashing there. Is IPAPPEND or "space-like characters" (whatever these are) still relevant?>> This all only got relevant yesterday, when I found out that replacing >> vesamenu.c32 with menu.c32 solved the crashes in this case. Are there > As I said, taking vesamenu.c32 out of the scene would had been one of > my first steps (before any reading of the code, "standards", > "protocols" and what not).You probably have a different background than me. There was no hint at all that this could be a problem. I was confronted with a machine that was crashing without any helpful hints while running code that I'm barely beginning to understand. From the tftp-logs I could see that the multinic patch worked, because the rest of the files were being downloaded, but then the machine crashed, just like it did before.> There is not one crash, but multiple > different crashes. The multi-nic situation was one thing (and good to > know about one additional case that was solved with the new branch > code), the vesamenu.c32 is another situation. Other than the in-common > hardware, and the people testing / participating, we shouldn't assume > they are related.I'm not assuming. I'm just asking. What I see is a crash when it should just handle an error situation. Maybe the longjmp() back to the exit handling code is borken? Who knows? I wanted to find out, so that's why I started to enable debugging and adding extra printf() everywhere. To see how far it got. And then I ran into more problems on that, which is a pity because I want to be as detailed as possible or even find and fix the problem myself. And now, just before I had to leave the office to return only on Friday, I found that most crashes mysteriously disappeared. Go figure... I *really* want to dive into it now, but I can't..
> > I am trying to find out whether vesamenu.c32 was crashing or the code > that was loading/starting vesamenu.c32. I haven't found that out yet.For testing this case with vesamenu.c32 I would suggest a very simple cfg with 2 or 3 entries (not just one entry, as the behavior would be slightly different) as first step. For example: *** syslinux.cfg start *** # Note that labels are not using the same name as actual files, in purpose. DEFAULT pwdlabel LABEL pwdlabel COM32 pwd.c32 LABEL lslablel COM32 ls.c32 *** syslinux.cfg end *** For a KISS troubleshooting, *all* the c32 files should be located together, in the root of the filesystem, where syslinux.efi and ldlinux.e64 (for EFI x86_64) should be located too. Note that all the Syslinux-related files should come from the same exact build. With the above syslinux.cfg, you should be booting to the Syslinux "boot:" prompt and immediately you should see the result of pdw.c32, and then back to the prompt. At that point, type-in vesamenu.c32 [enter]. If / when everything works as expected, you should see a (not-so-appealing and possibly with an inadequate screen resolution) vesamenu. But, in practice, other things could happen instead: _ Vesamenu attempts to show a menu, but your UEFI's GOP or UGA (whichever one of those your particular firmware supports) might not support the default screen resolution of vesamenu.c32, 640X480. There is a chance that your UEFI might not even support 800 x 600 either. _ From the prior possibility, after pressing [enter] you might or might not be able to see the result of pwd.c32 and the boot prompt. _ Or maybe vesamenu.c32 might crash at some point; when it is loading the menu, or when you try to execute one of the menu entries, or when exiting from the c32 module back to the boot prompt. A reminder: (vesa)menu.c32 uses a different parser than the CLI. The next step would be to add 'MENU RESOLUTION' with relevant values in syslinux.cfg and test several standard resolutions (including 'MENU RESOLUTION 1024 768', even if your screen is not 4:3). Whether there is some improvement at this point or not, only now (after all prior tests) I would also add a matching MENU BACKGROUND directive. When I say "matching", I mean that the values used for the 'MENU RESOLUTION' directive shall match the resolution used in the background image. Additional tests could include testing whether a png background behaves the same as a jpg file; always with the adequate resolution according the values in the MENU RESOLUTION directive being used in each test.> > > What do you mean with "nope"? I think I saw some IPAPPEND somewhere; am > > I wrong? Am I mixing email threads (again)? > > No you're right. Is IPAPPEND family of SYSAPPEND? I'm not so fluent in > syslinux configuration yet. And I just discovered how loading just > menu.c32 instead of vesamenu.c32 stopped the machine from crashing. I > really haven't had time to dig deeper into the 'why' since discovering > this. I also understand that I need to learn more about the > configuration parser now..First, see my reminder above about having different parsers in Syslinux. Regarding IPAPPEND / SYSAPPEND, see: http://www.syslinux.org/wiki/index.php/Config#SYSAPPEND> > > > Or perhaps you meant that you have triple-checked and thoroughly tested > > that strange behavior we saw last month regarding some "space-like > > characters" and concluded, without a doubt, that such problem does not > > exist in your scenario / hardware? > > Uh oh... more reading to do for me. I did not fully understand your > question there. > > But the menu entry is working. If syslinux starts and menu.c32 loads, > all menu entries work perfectly fine. No crashing there. Is IPAPPEND > or "space-like characters" (whatever these are) still relevant?There were discussions (and patches) related to this "space-like characters" about a month ago or so. I'm not sure you would be interested (or have the time) now for the prior conversation about the matter. There are additional places where the code might need some similar reviewing (IIRC, no less than 5 lines, and up to 20 perhaps). Let me emphasize the term *review* (with a pair of eyes, a brain, and some relevant knowledge, or whichever alternatives are available); whether there is a real need for patches about the issue, I do not know.> > And now, just before I had to leave the office to return only on > Friday, I found that most crashes mysteriously disappeared. Go > figure... I *really* want to dive into it now, but I can't..Considering that Syslinux itself is booting in your system now, you might be interested in debug.c32, to be executed with relevant arguments before launching your kernel (or before any kind of image / module for these tests). See: http://www.syslinux.org/wiki/index.php/Development/Debugging#Syslinux_Dy namic_Debugger Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
> > For a KISS troubleshooting, *all* the c32 files should be located > together, in the root of the filesystem, where syslinux.efi and > ldlinux.e64 (for EFI x86_64) should be located too. >I should clarify, just in case. In my previous email, when I mentioned "all" the c32 files, I actually meant all the c32 files that pertain to the adequate firmware's architecture. If we are talking about UEFI x86_64, then the c32 files are all those located under the "efi64" directory tree of the Syslinux build. Plus, the relevant "ldlinux.*" core module. I am clarifying (or attempting to) my prior statements about "all" the c32 files because of some recurrent problems: _ mixing files from different builds; _ mixing c32 files from one firmware's architecture (BIOS, EFI32, EFI64) with another; _ not having all the required library modules in the right place. These are the reasons for a frequent request: add some kind of "version" ID to each and all c32 files in some "standard" way. One reason to recommend the root directory as the "installation" directory for the bootloader (and its core "ldlinux" module) file(s) and the modules at this stage of testing is to avoid (or rather workaround) any potential "path" troubles; relevant for the configuration file content, actual location of files, filesystem support, the PATH directive (which is still in need to be patched, see bugzilla) and, of course, KISS. Regards, Ady.
On 06-08-15 18:47, Ady via Syslinux wrote: > For testing this case with vesamenu.c32 I would suggest a very simple > cfg with 2 or 3 entries (not just one entry, as the behavior would be > slightly different) as first step. [ full text: http://www.syslinux.org/archives/2015-August/023950.html ] Thanks for this troubleshooting guide! Hopefully the search engines will pick up on this and help people in the future. For me it helps me understanding syslinux and its configuration better.