search for: prlw1

On Tue, Apr 14, 2015 at 03:20:08PM -0400, Gene Cumm wrote: > > I thought I would try to find out how pxelinux copes with this, by trying > > to insert printfs in pxe_init, but nothing gets printed. > > This is normal. Can you give me hint as to why setting > > DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 changes that state of normality? (AFAICT dprintf.h

On Tue, Apr 14, 2015 at 7:13 PM, Patrick Welche <prlw1 at cam.ac.uk> wrote: > On Tue, Apr 14, 2015 at 03:20:08PM -0400, Gene Cumm wrote: >> > I thought I would try to find out how pxelinux copes with this, by trying >> > to insert printfs in pxe_init, but nothing gets printed. >> >> This is normal. > > Can you...

I just idly git cloned head and roughly compiled it on a stock ubuntu 18 box. Using the generated pxelinux.0 and ldlinux.c32, I see "Failed to load ldlinux.c32" If I replace those files with the ones out of the ubuntu installer, I get the prompt (i.e., ldlinux.c32 is loaded). Is head known to have issues, or is there a way of building broken binaries? Cheers, Patrick

On Thu, Mar 21, 2019 at 04:15:48PM +0000, Patrick Welche via Syslinux wrote: > I just idly git cloned head and roughly compiled it on a stock ubuntu 18 box. > Using the generated pxelinux.0 and ldlinux.c32, I see > > "Failed to load ldlinux.c32" > > If I replace those files with the ones out of the ubuntu installer, I get > the prompt (i.e., ldlinux.c32 is

I was compiling R on a system which admittedly was in the odd situation that it declared a function in math.h, but didn't have the associated implementation in libm, and the R 2.15.1 compilation failed. It turns out that R_CHECK_FUNCS is rather less robust than the standard AC_CHECK_FUNCS which actually attempts to link. On my temporarily broken system, AC_CHECK_FUNCS would not have been

On Thu, Mar 21, 2019 at 04:26:19PM +0000, Patrick Welche via Syslinux wrote: > On Thu, Mar 21, 2019 at 04:15:48PM +0000, Patrick Welche via Syslinux wrote: > > I just idly git cloned head and roughly compiled it on a stock ubuntu 18 box. > > Using the generated pxelinux.0 and ldlinux.c32, I see > > > > "Failed to load ldlinux.c32" > > > > If I

I have reason to believe that an odd box that is having boot trouble has three instances of "!PXE" in the chunk of memory that "Method D" should look at. I thought I would try to find out how pxelinux copes with this, by trying to insert printfs in pxe_init, but nothing gets printed. I can spew lots of output if I set DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 but