[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EB05441.8040904@msgid.tls.msk.ru>
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.
