Date: Wed, 02 Nov 2011 00:19:13 +0400 From: Michael Tokarev <mjt@....msk.ru> To: owl-dev@...ts.openwall.com Subject: Re: syslinux [Sadly I missed whole thread while it were happening, I was able to save lots of this conversation and work.] On 26.10.2011 12:11, Vasiliy Kulikov wrote: > Solar, > > On Wed, Oct 26, 2011 at 12:02 +0400, Solar Designer wrote: >> On Wed, Oct 26, 2011 at 11:44:46AM +0400, Vasiliy Kulikov wrote: >>> The syslinux.spec is attached. For isolinux we need only the core >>> package, syslinux. The full list of generated RPMS is as follows: >>> >>> syslinux-4.04-owl1.i686.rpm >>> syslinux-devel-4.04-owl1.i686.rpm >>> syslinux-extlinux-4.04-owl1.i686.rpm >>> syslinux-perl-4.04-owl1.i686.rpm >>> syslinux-tftpboot-4.04-owl1.i686.rpm The extlinux package isn't needed anymore in 4.x versions of syslinux. It is just one executable that installs the same loader as everything else but into mounted directory in linux, as opposed to syslinux which installs into a (block) device. All of syslinux, extlinux and isolinux are just different installers which installs just the same actual boot code which is named ldlinux.sys. ldlinux.sys supports all filesystems (except networking). pxelinux is actual boot code itself, it is not installer, it contains the same code as ldlinux.sys, plus some network- related stuff, including network drivers and processing of pxe-related parameters (like ipappend). So there's just no reason to keep syslinux-extlinux package, it is historical artifact from pre-4.x days, and it belongs to main syslinux package. But syslinux installer is a bit problematic: under linux it uses mtools package to deal with fat-based filesystems, so to be fair, it depends on mtools (or else needs to be slightly patched to produce a nice error message in case mtools is not installed). There's alternative syslinux implementation available, which tries filesystem manipulation internally, but it is not as mature and tested as mtools-using version (both are in original source tarball). Both bootloaders will record boot device information into ldlinux.sys written into the destination place (or, rather, should - module minor bugs) - so that it should be possible to boot correctly even if the previous bootloader in the chain (be it BIOS (actually mbr code) or M$ bootloader or grub or whatever called ldlinux.sys) didn't pass correct boot info to it. The bootloader - be it ldlinux.sys or pxelinux.0 - uses the same set of modules (.c32 binaries), which is where all the interesting functionality comes from. First is menu.c32 (or vesamenu.c32 which is the same but in graphic mode) which makes boot interactive, with menu and ability to edit entries. Also chain.c32 to chainload other vbr (partiton boot record). linux.c32 isn't needed, but may be used to load linux-like kernels instead of a built-in ability to load it by ldlinux.sys or (vesa)menu.c32. And so on. One note: the set of modules used is better match version of ldlinux.sys which loads them. Speaking of tftpboot package - interesting approach, packaging the same stuff but in alternative place. Maybe it's better to use a trigger to copy the necessary modules from /usr/lib/ on update of syslinux package... :) Yes, syslinux distribution is rather large, and yes, it is due to inclusion of (former) etherboot code for all different network cards it supports. But in practice, only about 1% of that code (i never bothered to check actual numbers) is used in pxelinux -- namely, the pxe network driver. It is possible to build custom images of pxelinux using different drivers (e1000linux someone? :), but that's of little relevance to current discussion. As far as I understand, HPA just took whole thing and used only relevant places from it. Concerning rock ridge and symlinks support in iso9660 - it is interesting that it hasn't been raized before. I always tried to keep filenames very small on various non-unix filesystems myself, including my limited usage of iso9660 and derivates and fat-related filesystems. And especially not using symlinks on such filesystems - that's probably I haven't hit this problem myself. But the thing is: at this stage, it isn't really interesting to support iso9669 at all. hybrid boot images is what should be used - just IMHO. There, any filesystem may be used, without restrictions on filenames and symlinks, and you get usb booting for free too. That's probably the main reason this restriction does not pop up around syslinux - neither in the mailinglist nor in wiki nor in irc. Hybrid images may not work on some old hardware, but I'm not sure it is worth the effort to support or even use such a hardware - it is energy-inefficient compared with current systems. But may be working just fine anyway... :) That's just a few points, to sum stuff which were referenced and weren't answered in full in this discussion. One more note: if you want to experiment chainloading syslinux from windows bootloader, a small patch for extlinux (if that's the installer of choice) needed to record default boot partition properly in ldlinux.sys proper, or else it wont find itself from bootsec.dos file loaded by ntldr. Thanks, /mjt
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.