please upgrade syslinux from 3.63 to latest debian sid version

[Fernando Miguel]

Binary package hint: syslinux

I know we are past FF, but currently we have syslinux intrepid 2:3.63+dfsg-2ubuntu3 and debian and upstream has syslinux (2:3.71+dfsg-5)
Projects like Clonezilla require 3.71 to make their USB images bootable.

Can someone please file a FFe?

Thanks in advance

[Fernando Miguel (fernandomiguel)]

Forgot the links:
http://packages.debian.org/sid/syslinux
http://packages.ubuntu.com/search?keywords=syslinux&searchon=names&suite=intrepid&section=all
http://www.clonezilla.org/ "Make sure syslinux 3.71 or later is available on your GNU/Linux system."

[Dimitrios Symeonidis (azimout)]

The clonezilla requirement for syslinux 3.71 can be found here:
http://www.clonezilla.org/clonezilla-live/

[plun (plun)]

Also in Lenny and Ubuntus version is out of order for Parted Magic

http://packages.debian.org/lenny/syslinux

About Parted Magic
http://partedmagic.com/wiki/PartedMagic.php?n=PartedMagic.CreatingTheMedia

[Fernando Miguel (fernandomiguel)]

Why wasnt syslinux upgraded with the auto sync from debian?

it might help fix bug 277903

[Kristi (kristi109)]

Any news on this? Ubuntu 9.04 Jaunty is out and we're still using 3.63. I was having trouble making a gparted live cd until I realized that it required syslinux 3.71 and Ubuntu only has 3.63.

[Kristi (kristi109)]

Sorry, I meant live usb, not cd.

Gparted Live USB
http://gparted.sourceforge.net/liveusb.php

[Dimitrios Symeonidis (azimout)]

And now debian has 3.80: http://packages.debian.org/sid/syslinux

[Colin Watson (cjwatson)]

BUGabundo: the clue's in the name, "auto sync". This isn't a sync, it's a very complicated merge that I didn't have time for.

I'll be happy to review patches in the form of a diff against Debian unstable, but ask that anyone doing this actually test their work with current CD images to make sure it doesn't break the world. This is a critical component.

[Colin Watson (cjwatson)]

Or at least, potentially very complicated. If the new gfxboot module from upstream works properly for Ubuntu then of course it will be relatively simple. It's possible that it might require changes to the gfxboot package as well, though, which would make life Interesting.

[Pierre-Alexandre Meyer (pam-mouraf)]

Did a first pass on the merge with some basic testing (extlinux and
vesamenu.c32 on hp2530p).

Among major changes is the deletion of the gfxboot patches: an upstream version is available as a com16 module. This has some impact on configuration files. I am still trying to figure out how the official Ubuntu CD is built to test that part (maybe as simple as gfxboot-theme-ubuntu + mkisofs?).

   PPA: https://launchpad.net/~pam-mouraf/+archive/ppa

[Pierre-Alexandre Meyer (pam-mouraf)]

Tested with Karmic Alpha 2 ISO (still downloading Alpha 3) and a nightly Karmic chroot as build environment.

Testing Done: updated isolinux.bin and vesamenu.c32 with the ones built in my PPA. Added gfxboot.com.
Built with: sudo mkisofs -r -V 'Ubuntu 9.10 i386' -o karmic-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new_iso

Bad news: isolinux.cfg needs to be patched otherwise the CD triggers a reboot (triple fault?).

gfxboot.com seems to procure the list of labels from isolinux.cfg to gfxboot but doesn't respect
"include" directives: it only parses isolinux.cfg.

Ubuntu's gfxboot script (menuconfig.inc from gfxboot-theme-ubuntu) does the right thing though and
successfully parses all cfg files, but then tries to match the labels provided by the com module
with the labels it has parsed (to set the human readable names). Because of this mismatch, labels
in other config files but isolinux.cfg are not displayed.

The following patch is need to isolinux.cfg (explicitely states labels in isolinux.cfg):

isolinux > diff -du isolinux.cfg.orig isolinux.cfg
--- isolinux.cfg.orig 2009-07-25 08:43:55.000000000 -0700
+++ isolinux.cfg 2009-07-26 20:27:24.000000000 -0700
@@ -2,4 +2,8 @@
 default vesamenu.c32
 prompt 0
 timeout 0
-gfxboot bootlogo
+label install
+label check
+label memtest
+label hd
+ui gfxboot.com bootlogo

Tested all four labels and played with the UI (modes, ...). Worked fine.

It seems that with Syslinux 4, gfxboot scripts won't have to parse configuration files anymore. In the meantime,
gfxboot-theme-ubuntu may need to be patched to avoid the previous hack. Shouldn't be too hard though.

[Pierre-Alexandre Meyer (pam-mouraf)]

Patching gfxboot-theme-ubuntu to make it parse labels that are not in isolinux.cfg was indeed easy.

The tough part is to fix the bug that makes gfxboot crash if no label is specified in isolinux.cfg (my patch still requires a dummy foo label). Couldn't find the problem. I may need some help on that one.

[Colin Watson (cjwatson)]

Please attach your gfxboot-theme-ubuntu patches so far so that I can
review them?

[Pierre-Alexandre Meyer (pam-mouraf)]

About the crash when no label is specified: it seems actually that gfxboot core never runs menuconfig.init (the menu parsing function).

Running under Bochs, it appears that gfxboot core does its initialization (gfx_init_51 is run since the hello msg is displayed) and the VGA initialization too (the console get redrawn). But shortly thereafter, bochs reboots
(maybe around gfx_init_59 when it looks at the stack?). In the logs:

00258214795i[BIOS ] Booting from 0000:7c00

Maybe gfxboot core returns somewhere when it realizes that label count (passed by gfxboot.com) is zero.

About the gfxboot-theme-ubuntu patch: attached to this comment and test case description below.

Testing Done:

Installed pristine gfxboot-theme-ubuntu-0.8.1 bootlogo to Karmic alternate CD (isolinux/bootlogo).
Patched isolinux.cfg:

--- isolinux.cfg.orig 2009-08-10 00:05:48.000000000 +0000
+++ isolinux.cfg 2009-08-10 00:04:11.000000000 +0000
@@ -2,4 +2,4 @@
 default vesamenu.c32
 prompt 0
 timeout 0
-gfxboot bootlogo
+ui gfxboot.com bootlogo

Copied usr/lib/syslinux/isolinux.bin and usr/lib/syslinux/gfxboot.com from

   https://launchpad.net/~pam-mouraf/+archive/ppa/+build/1132652/+files/syslinux-common_3.82+dfsg-1ubuntu1_all.deb

to the CD isolinux directory.

Packed the ISO with

   mkisofs -r -V 'Ubuntu 9.10 i386' -o karmic-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new_iso

Booting karmic-alternate-i386-hacked.iso under Qemu makes it reboot.

Adding 'label foo' in isolinux.cfg makes the UI appear but only one label (foo) is displayed.

Patching menuconfig.inc with the attached patch makes the other labels appear. The keyboard is broken though (stack corruption due to either the confusion between the added labels and the stack presented by gfxboot.com or a bug that I introduced).

[Alkis Georgopoulos (alkisg)]

I know that this doesn't help in packaging some newer version,
but I'd like to add that with the current 2:3.63+dfsg-2ubuntu3 version my clients fail to pxe boot, while they successfully boot with the 2:3.83+dfsg-1 version currently in Debian sid.

I know that things are pressed now with Karmic, so I'll just say that it would be nice if syslinux was upgraded even after the Karmic release. I'm willing to test any proposed patches by building the .iso and testing on multiple PCs.

[John Doe (jodo-deactivatedaccount)]

Could this be linked against Lucid Development? Would be a good thing to have an actual build of syslinux in 10.04.

[Hubi5171 (hubert-huber)]

Please upgrade. thks

[Alkis Georgopoulos (alkisg)]

Feature freeze is in 2 days. Would it be possible to sync syslinux in time for Lucid?

I'm getting more and more problems booting newer hardware with the 2:3.63+dfsg-2ubuntu3 Lucid version... problems that disappear when I use the Debian testing 2:3.83+dfsg-3 version.

[John Doe (jodo-deactivatedaccount)]

Lucid +1 ? This really should be done.

[Shriramana Sharma (jamadagni)]

Hello. For my purposes of working with Parted Magic, I am backporting syslinux 3.85 from Debian unstable to Kubuntu Koala. In the process, I get the error:

nasm -O9999 -f elf -g -F stabs -DDATE_STR="'debian-20100329'" \
                -DHEXDATE="0x4bb0227c" \
                -l ldlinux.lsr -o ldlinux.o ldlinux.asm
ld -m elf_i386 -Wl,-Bsymbolic-functions -T syslinux.ld -M -o ldlinux.elf ldlinux.o > ldlinux.map
ld: unrecognized option '-Wl,-Bsymbolic-functions'
ld: use the --help option for usage information
make[3]: *** [ldlinux.elf] Error 1
make[3]: Leaving directory `/home/samjnaa/sr/_backport/syslinux-3.85+dfsg/core'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/samjnaa/sr/_backport/syslinux-3.85+dfsg'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/home/samjnaa/sr/_backport/syslinux-3.85+dfsg'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
$

I found that the offending line was syslinux-3.85+dfsg/core/Makefile line 81:

 $(LD) $(LDFLAGS) -T syslinux.ld -M -o $@ $< > $(@:.elf=.map)

where for some reason LDFLAGS holds -Wl,-Bsymbolic-functions. However, doing rgrep on the build tree for -Wl,-Bsymbolic-functions or even -Bsymbolic turns out nothing. I even tried resetting the environment variable LDFLAGS to "" before beginning the build process but no use. So at what point in the build process does LDFLAGS get set to -Wl,-Bsymbolic-functions?

Obviously -Wl is only for passing ld arguments *via* gcc and not directly. Obviously the programmer who wrote the Makefile is expecting the flag to hold only -Bsymbolic-functions (and apparently this build works correctly on Debian sid else the package would not have been successfully uploaded). Anyway, I changed the line to hold the flag verbally:

 $(LD) -Bsymbolic-functions -T syslinux.ld -M -o $@ $< > $(@:.elf=.map)

since I did not want to tinker with the environment variable which may be needed who knows where elsewhere in the build process, and this worked correctly. Maybe this should be incorporated and the latest version of syslinux be made available for Ubuntu. The following "patch" may fix it:

--- core/Makefile 2010-03-29 09:26:31.000000000 +0530
+++ core/Makefile 2010-03-29 09:26:12.000000000 +0530
@@ -80,3 +80,3 @@
 %.elf: %.o syslinux.ld
- $(LD) $(LDFLAGS) -T syslinux.ld -M -o $@ $< > $(@:.elf=.map)
+ $(LD) -Bsymbolic-functions -T syslinux.ld -M -o $@ $< > $(@:.elf=.map)
        $(OBJDUMP) -h $@ > $(@:.elf=.sec)

Anyway, if there were a way to vote, I would vote for the latest syslinux from Debian sid to be included in Ubuntu.

[Vladimir Ushakov (ush)]

I have updated the branch with Debian's 3.86. The clone is currently available as my personal branch:

 https://code.launchpad.net/~ush/+junk/syslinux

and seems to be ready for integration and testing. The compiled version is available at

 https://launchpad.net/~ush/+archive/meego-tools

Possible regressions concern the removal of Ubuntu's gfxboot patch (it is now integrated upstream, but is implemented differently) and the default64 keyword (then again it can now be done a different way).

[Martin Jackson (mhjacks)]

I have successfully tested the PPA version by creating USB images with both grml and System Rescue CD. The stock Lucid version failed in both cases, but this version worked. System Rescue CD version tested was 1.5.4, GRML version 2010.04, via grml2usb.

[Colin Watson (cjwatson)]

I've finally uploaded this, discarding previous Ubuntu modifications and adding these new ones (all of which I've forwarded to the appropriate places):

syslinux (2:4.01+dfsg-3ubuntu1) maverick; urgency=low

  * Unexport LDFLAGS in debian/rules in case it was passed by
    dpkg-buildflags (the LDFLAGS there is expected to be passed to gcc, not
    ld; thanks, Vladimir Ushakov).
  * gfxboot module:
    - Add include and menu include support.
    - Fix buffer overrun when loading kernel/initramfs.
    - Allow boot entry to start with label instead of menu_label.

 -- Colin Watson <email address hidden> Wed, 14 Jul 2010 14:26:52 +0100

Thanks particularly to Pierre Meyer and Vladimir Ushakov for their work, although in the end I didn't use Pierre's patch to gfxboot-theme-ubuntu but took a different approach instead. I think I was right to be cautious before; this took a full day of staring very hard at crash dumps to sort out, and based on that there may well be some knock-on problems in Maverick which we'll need to sort out.

[Fernando Miguel (fernandomiguel)]

Thank you Colin.
Your work on this is appreciated!