[syslinux] SysLinux 5.0 - Problems booting via PXE

[Schlomo Schapiro]

Hi,

nice to hear that 5.01 is coming.

On 10 January 2013 16:17, Matt Fleming <matt at console-pimps.org> wrote:

> >    - The HTTP download was the same slow as with 4.05
>

Any plans on fixing this issue? Seems to be only on VMware VMs.


> >    - The kernel command line was not passed to the system which caused
> our
> >    installations to fail (obvious if no install= parameter is given).
>
> How many bytes was your kernel command line? If it was >= 256 bytes this
> bug has now been fixed and will be available in the 5.01 release.


The append parameter has 221 chars, maybe it got expanded to a bit more
somehow. I can retest with 5.01


>
> >    - The PATH setting did not work which is very inconvenient as I would
> >    like to put all syslinux components (*.c32, *.0) into /bin so that I
> can
> >    switch pxelinux+c32 files with a symlink.
>
> What was the PATH string that you used in your config file? What error
> message did you get when it didn't work?
>

PATH /bin

$tftp_prefix/bin contains all the syslinux stuff. I had to symlink the
lib*c32 files to $tftp_prefix (which is HTTP based).


>
> >    - Loading vesamenu.c32 more than once did not work (I was doing this
> to
> >    jump to other menus). As a "workaround" I restructured my menu system
> to
> >    only do config xxx.txt which luckily also works with 4.05
>
> Oh, that's interesting. This use case is currently explicitly forbidden
> because of the way that the module loading code *used* to work. Because
> ldlinux.c32 used to be listed as a dependency for those modules that
> linked against its exported symbols, we had to forbid re-loading
> executable modules (as opposed to library modules) otherwise everytime a
> module, such as menu.c32, was loaded, it would reload ldlinux.c32 and
> drop the user at a prompt!
>

I noticed that. I think that it helps to allow repeated loading of
executable modules as that allows users to chain existing syslinux
configurationes, e.g. copied from a tool CD.


>
> Luckily, the module dependency code doesn't work this way anymore, and
> we no longer need this restriction. I've got a fix for this in my patch
> queue. It will be in 5.01.
>

When should I plan some time to test 5.01?

Regards,
Schlomo