search for: roozen

Update: I added my debugging stuff (just a bunch of Print()s and dprintf()s) to the branch without the multinic fix to see if I could find a common cause somewhere. This is based on commit 8702009f. Where I expected the machine to crash again, it just exited back to the bootloader without crashing. So.. somehow adding this debug code solved the crashing problem? Or did it? Then I went back

..., my guess is it will take some time understanding them. I'm just becoming a bit more comfortable reading syslinux code. > By the way, what version/commit? A fresh syslinux-6.03.tar.gz from kernel.org. I also tried 81ad566f155fac31089fde69c87059b217e7e9b6 with the same results. -- Oscar Roozen Linux Developer Bright Computing BV

...f option architecture-type = 00:09 { filename "efi64/syslinux.efi"; option pxelinux.pathprefix "http://myserverip/tftp/efi64/"; } elsif option architecture-type = 00:07 { # efi32 not supported. } else { filename "bios/pxelinux.0"; } Thanks! -- Oscar Roozen Linux Developer oscar.roozen at brightcomputing.com Bright Computing BV Kingsfordweg 151 1043 GR Amsterdam The Netherlands Tel: +31 20 491 9324 www.BrightComputing.com

On Tue, Aug 4, 2015 at 2:42 PM, Oscar Roozen via Syslinux <syslinux at zytor.com> wrote: > On 04-08-15 17:38, Oscar Roozen wrote: >> Any suggestions while I keep on debugging? > Got some result! > > I was using 'vesamenu.c32' to display a menu. Changing this to 'menu.c32' > resulted in a booting s...

On 05-08-15 12:05, Gene Cumm wrote: > > I recompiled with this in mk/devel.mk <http://devel.mk>: > > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 > > 0x2f8 is a BIOSism. Is this a problem? The example in the comments said 0x3f8 which is COM1.

On Wed, Aug 5, 2015 at 8:06 AM, Oscar Roozen <oscar.roozen at brightcomputing.com> wrote: > On 05-08-15 12:05, Gene Cumm wrote: >> >> > I recompiled with this in mk/devel.mk <http://devel.mk>: >> > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a prob...

...ue. So... How is it possible that a simple recompile with some debugging turned on, resolved the crashing issue. Unfortunately I can't test anymore until Friday. Maybe gnu-efi got updated? I seem to remember seeing a shell script pulling in the newest version during compilation... -- Oscar Roozen Linux Developer oscar.roozen at brightcomputing.com Bright Computing BV Kingsfordweg 151 1043 GR Amsterdam The Netherlands Tel: +31 20 491 9324 www.BrightComputing.com

On 04-08-15 14:42, Patrick Masotta wrote: > I think we solved a bug but we found a new one. > AFAIK you were not able to retrieve anything after loading syslinux.efi > Now you retrieve ldlinux.e32, libcom32.c32, etc but it crashes when loading a png. > If this is the case then the multi-nic issue is solved; the new code is able to > find the NIC that booted syslinux.efi and then

On 04-08-15 17:38, Oscar Roozen wrote: > Okay, the code in efi/ uses Print() from gnu_efi, but generic code from > core/ like core/elflink/load_env32.c prints their messages and debugging > stuff using printf(). These messages end up nowhere. This may explain > why I never saw anything beyond a certain point, even wit...

Updating myself again: On 07-08-15 16:03, Oscar Roozen wrote: > e466d24 still has an issue with png's in vesalinux causing crashes I can confirm this remaining crash is caused by the line "MENU BACKGROUND bootlogo.png". The original bootlogo.png is 640x480. Forcing the videomode with "MENU RESOLUTION 640 480" did not res...

On Wed, Aug 5, 2015 at 3:03 PM, Oscar Roozen via Syslinux <syslinux at zytor.com> wrote: > Unfortunately I can't test anymore until Friday. Maybe gnu-efi got > updated? I seem to remember seeing a shell script pulling in the > newest version during compilation... It's version locked to a certain commit ID. -- -Gene

...roms in qemu or by chainloading from snponly.efi, ipxe.efi or any other way, please tell me more about your setup? Can there be some mis-configuration somewhere that can lead to this error? Or the TL;DR version: HELP! ;-) In any case, thanks for reading this far into this mail! Regards, Oscar Roozen Linux Developer

On 04-08-15 15:42, Oscar Roozen wrote: > I'm adding debug statements as we speak... Okay, the code in efi/ uses Print() from gnu_efi, but generic code from core/ like core/elflink/load_env32.c prints their messages and debugging stuff using printf(). These messages end up nowhere. This may explain why I never saw anyt...

On Aug 4, 2015 2:45 PM, "Oscar Roozen via Syslinux" <syslinux at zytor.com> wrote: > Still miss the printf output, though, so error messages from the shared code don't reach the user. > > I recompiled with this in mk/devel.mk: > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 0x2f8 is a BIOSism. --Gene

>>> On 07-08-15 16:03, Oscar Roozen wrote: e466d24 still has an issue with png's in vesalinux causing crashes I can confirm this remaining crash is caused by the line "MENU BACKGROUND bootlogo.png". <<< Since last week I've been able to reproduce this problem. This is a weird bug affecting zlib but...

...ble.? See also "[syslinux] EFI & PXE-booting: very slow TFTP performance on a VMWare test setup" http://www.syslinux.org/archives/2015-June/023634.html -Gene <<< Gene, As I see it there are two completely different TFTP problems here: The one initially reported by Oscar Roozen lead to this bug report https://communities.vmware.com/message/2536774 Later I detected a completely different VMware problem (related to IP fragmentation) that lead to this other bug report: https://communities.vmware.com/message/2536960 Then; where do you see the quite recognizable pattern w/o...

...unusual scenario. I hope to have another set shortly after I test this again. -- -Gene > -----Original Message----- > From: Geert Stappers [mailto:stappers at stappers.nl] > Sent: Wednesday, October 07, 2015 12:04 PM > To: Gene Cumm; Da Shi Cao; S. Schauenburg; Michael Glasgow; Oscar Roozen; jeff_sloan at selinc.com; Cao, Da-Shi (EG-China-Presales-CPC-GZ); holger.baust at freenet.ag; For discussion of Syslinux and tftp-hpa; Ashish, Shivendra; Derrick M > Subject: Re: [syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32 > > On Tue, Oct 06, 2015 at 10:27:15PM -0400, Gene Cum...

On 05-08-15 15:28, Gene Cumm wrote: >>> 0x2f8 is a BIOSism. > >> Is this a problem? The example in the comments said 0x3f8 which is COM1. > > It means that a BIOS IO port for a UART won't work for EFI. No value > for DEBUG_PORT will do anything unless someone's got some translation > "glue" to take the attempts to open the UART and use an EFI handle

On Mon, Sep 21, 2015 at 8:16 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > > > > I have seen this before; Are you using VMware 12 ? > > try changing the virtual driver. > > I have reported a bug on certain VMware drivers that > > mistakenly set TFTP blocksize to 1486 instead of 1468, > > That leads to IP fragmentation and

Hi, Assume you are in hostile environment, as in you can't trust the DHCP serversss nor the TFTP/HTTP server. So you would want a checksum on kernel and initrd. Which checksum algoritme is available in pxelinux.0? Which checksum algoritme could be integrate into pxelinux.0? In other words: Please advice what could be done to verify what pxelinux.0 did download. Cheers Geert Stappers --