[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