Bill Peck wrote:
> Suggestions on how to resolve this? Is there interest in just
another
> parameter added that most users would ignore? Suggestions for a better
> way to handle it?
>
> Doug
>
Would the new tornado based tftp.py help here?
It has. But there's the remaining issue of "I need an extra data
field". I tried to make the new server combatible with everything
existing, and want to keep that sort of logic (changes between distros)
out of it. I need to represent things as data so that the logic in the
server can be fixed.
So, the boot process, for FreeBSD, in a little more detail (as I've got
it implemented now, with the pytftp sever)
... irrelevant bits.
client loads pxelinux.0
pxelinux.0 tftp RRQs pxelinux.cfg/<client id>
pxelinux.0 sees a kernel to load.
pxelinux.0 RRQs it's kernel (FreeBSD's pxeboot.bs)
I have to tell cobbler that "pxeboot.bs" is the kernel, so that the
generated pxelinux.cfg points to it.
pxelinux.0 chains to the kernel.
pxeboot.bs RRQs it's config (/boot/stuff.4th)
pxeboot.bs RRQs it's initrd
Right now, this is something tftp.py solves. I put a remap line
in fetchable files that looks like "/boot/mfsroot.gz=$initrd"
pxeboot.bs RRQs it's kernel
I can put a line in fetchable files that looks like
"/boot/kernel/kernel=$kernel", but that's pointing to pxeboot.bs,
so intead I have to point it at
/var/www/cobbler/ks_mirrors/$distro/boot/kernel/kernel, which is ugly.
pxeboot.bs chains to it's kernel.
Thus ...
It would be cleaner if the datastore had some sense of "chaining
bootloaders", so that it would be clear code in pxegen.py: if I need to
chain a bootloader, chain to a bootloader (ending the name of the
bootloader in .bs always, so that pxelinux doesn't try and load it like
a linux kernel). Otherwise, just skip directly to the kernel.
Doug
--
Doug Kilpatrick
kilpatds(a)oppositelock.org