david/ipxe
Archived
1
0
Commit Graph

6 Commits

Author SHA1 Message Date
Michael Brown
22001cb206 [settings] Explicitly separate the concept of a completed fetched setting
The fetch_setting() family of functions may currently modify the
definition of the specified setting (e.g. to add missing type
information).  Clean up this interface by requiring callers to provide
an explicit buffer to contain the completed definition of the fetched
setting, if required.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-12-05 00:37:02 +00:00
Stefan Hajnoczi
7d64abbc5d [iscsi] Include 802.1Q VLAN identifier in iBFT
The iBFT NIC section has a VLAN field which must be filled in so that
iSCSI booting works over VLANs.

Unfortunately it is unclear from the IBM specification linked in
ibft.c whether the VLAN field is just the 802.1Q VLAN Identifier or
the full 802.1Q TCI.  For now just fill in the VID, the Priority Code
Point and Drop Eligible Indicator could be set in the future if it
turns out they should be present too.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-01 16:22:23 +00:00
Michael Brown
960dee6dd0 [iscsi] Change default initiator IQN
The default initiator IQN is "iqn.2000-09.org.etherboot:UNKNOWN".
This is problematic for two reasons:

  a) the etherboot.org domain (and hence the associated IQN namespace)
     is not under the control of the iPXE project, and

  b) some targets (correctly) refuse to allow concurrent connections
     from different initiators using the same initiator IQN.

Solve both problems by changing the default initiator IQN to be

  iqn.2010-04.org.ipxe:<hostname> if a hostname is set, or

  iqn.2010-04.org.ipxe:<uuid> if no hostname is set.

Explicit initiator IQNs set via DHCP option 203 are not affected by
this change.

Unfortunately, this change is likely to break some existing
configurations, where ACL rules have been put in place referring to
the old default initiator IQN.  Users may need to update ACLs, or
force the use of the old IQN using an iPXE script line such as

  set initiator-iqn iqn.2000-09.org.etherboot:UNKNOWN

or a dhcpd.conf option such as

   option iscsi-initiator-iqn "iqn.2000-09.org.etherboot:UNKNOWN"

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-03-03 22:23:44 +00:00
Michael Brown
def5b67560 [iscsi] Fix minor typo in ibft_set_ipaddr()
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-02-24 23:39:38 +00:00
Michael Brown
94cdad9c0e [iscsi] Include both DNS addresses in iBFT, if available
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-12-09 15:35:02 +00:00
Michael Brown
220495f8bf [block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism.  Bring this old code up to
date, with the following benefits:

 o  Block device commands can be cancelled by the requestor.  The INT 13
    layer uses this to provide a global timeout on all INT 13 calls,
    with the result that an unexpected passive failure mode (such as
    an iSCSI target ACKing the request but never sending a response)
    will lead to a timeout that gets reported back to the INT 13 user,
    rather than simply freezing the system.

 o  INT 13,00 (reset drive) is now able to reset the underlying block
    device.  INT 13 users, such as DOS, that use INT 13,00 as a method
    for error recovery now have a chance of recovering.

 o  All block device commands are tagged, with a numerical tag that
    will show up in debugging output and in packet captures; this will
    allow easier interpretation of bug reports that include both
    sources of information.

 o  The extremely ugly hacks used to generate the boot firmware tables
    have been eradicated and replaced with a generic acpi_describe()
    method (exploiting the ability of iPXE interfaces to pass through
    methods to an underlying interface).  The ACPI tables are now
    built in a shared data block within .bss16, rather than each
    requiring dedicated space in .data16.

 o  The architecture-independent concept of a SAN device has been
    exposed to the iPXE core through the sanboot API, which provides
    calls to hook, unhook, boot, and describe SAN devices.  This
    allows for much more flexible usage patterns (such as hooking an
    empty SAN device and then running an OS installer via TFTP).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-14 20:37:15 +01:00