[syslinux] How to support iSCSI multipath...

Miller, Shao Shao.Miller at yrdsb.edu.on.ca
Mon Oct 5 12:41:24 PDT 2009


Good day Alex,

You have been talking about grabbing an iBFT file from a TFTP server
versus using a gPXE-built one.  Perhaps you could set up your network
interfaces in the initrd using the gPXE-built iBFT, then use a TFTP
client in the initrd to grab something better.

Perhaps you'd be interested in passing gPXE environment variables to the
kernel/initrd via the kernel command-line.  You can do:

#!gpxe
kernel tftp://${next-server}/vmlinuz my_ip=${ip}
initrd tftp://${next-server}/my_initrd

So you see, a gPXE variable like 'ip' will be available in /proc/cmdline
with a "my_ip=" prefix which an initrd script could parse.

I'm not sure how many users would be interested in manually building
iBFT files for gPXE to download and use.  What if an iBFT contained
information that didn't match gPXE's 'route' command?  How should gPXE
behave?

If you really want to, you could do something like this:

- Install one of the Syslinux suite of boot-loaders to the SAN
(SYSLINUX/EXTLINUX)
- Code up a cheap COM32 module which searches memory for the iBFT,
invalidates it, writes an alternative iBFT
- Have the SAN-boot process run this program as part of the boot process

OR:

- Use gPXE's 'keep-san' setting
- Cause the SAN's MBR to return to gPXE through INTerrupt 0x19
- Have gPXE run a cheap COM32 module which searches memory for the iBFT,
invalidates it, writes an alternative iBFT (perhaps downloaded via TFTP)
- Use chain.c32 to boot a bootable partition on the still-attached SAN

Just some thoughts, though their results would be roughly equivalent to
what you could possibly accomplish in the initrd with scripts.

- Shao Miller




More information about the Syslinux mailing list