Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
commandline [2009/02/09 07:10]
andytim URIString
commandline [2010/01/30 06:57]
stefanha
Line 1: Line 1:
 =====Etherboot command-line===== =====Etherboot command-line=====
 ====Network Interfaces==== ====Network Interfaces====
-Etherboot names interfaces following the pattern "​net#"​.+Etherboot names interfaces following the pattern "​net#"​.  The special network interface alias "​netX"​ refers to the last opened network interface.
  
 **ifstat [interfaces...]** Displays information and statistics about the specified interface. ​ If no interface is specified, displays information about all detected interfaces. ​ Information includes MAC address, PCI bus/​slot/​function identiers, and packet counts. **ifstat [interfaces...]** Displays information and statistics about the specified interface. ​ If no interface is specified, displays information about all detected interfaces. ​ Information includes MAC address, PCI bus/​slot/​function identiers, and packet counts.
Line 35: Line 35:
 **boot [image name]** Equivalent to **imgexec** **boot [image name]** Equivalent to **imgexec**
  
-**imgfree** Remove all fetched/​loaded images.+**chain [image name/URI]** This will fetch, load, then execute either an embedded image or one specified by the URI.  Equivalent to **imgfetch**,​ then **imgload**,​ and then **imgexec**.
  
-**kernel [-n|--name <image name>] <​filename>​ [arguments]** Fetch and load a bzImage format Linux kernel. ​ Equivalent to an imgfetch followed by imgload.+**imgfree [image name]** Free one or all executable/​loadable images. 
 + 
 +**kernel [-n|--name <image name>] <​filename>​ [arguments]** Fetch and load a bzImage format Linux kernel. ​ Equivalent to an **imgfetch** followed by **imgload**.
  
 ====Runtime configuration==== ====Runtime configuration====
Line 48: Line 50:
 **clear <​identifier>​** ​ Clear the value of //​identifier//​ **clear <​identifier>​** ​ Clear the value of //​identifier//​
 ===Identifiers=== ===Identifiers===
 +Identifiers could be considered "​variables"​ in the gPXE shell (CLI and scripts). ​ You can type:
 +  ${identifier}
 +as part of a command, and it will be substituted for the fetched setting corresponding to that identifier. ​ For example:
 +  chain http://​${next-server}/​boot.php?​mac=${net0/​mac}
 +is a command which would have the //​next-server//​ setting substituted into the URI, as well as pass the //net0// interface'​s MAC address as a parameter to a PHP script on the web-server.
 +
 All identifiers are set within a scope. All identifiers are set within a scope.
   * **root** (scope unspecified)   * **root** (scope unspecified)
Line 55: Line 63:
   * **[interface].nvo**. ​ Read/write settings in NVRAM on certain supported cards. ​ **//​WARNING//​** this permanently modifies settings on your network card.  It is possible to **damage** your network card by changing settings in this context. ​ Use at your own risk.   * **[interface].nvo**. ​ Read/write settings in NVRAM on certain supported cards. ​ **//​WARNING//​** this permanently modifies settings on your network card.  It is possible to **damage** your network card by changing settings in this context. ​ Use at your own risk.
   * **smbios**. ​ Read-only access to settings in the System Management BIOS (see below)   * **smbios**. ​ Read-only access to settings in the System Management BIOS (see below)
-Identifiers follow the format [scope/​]identifier:[type]. ​ For example, to set the IP address of the '​net0'​ card use //set net0/ip XXX.XXX.XXX.XXX//​+Identifiers follow the format [scope/​]identifier[:type]. ​ For example, to set the IP address of the '​net0'​ card use //set net0/ip XXX.XXX.XXX.XXX//​
  
 Options not specified in a higher scope will be read from a lower one.  So if the option //ip// is unspecified,​ it will be read from //​net0/​ip//;​ if the option //net0/ip// is unspecified,​ it will be read from //​net0.dhcp//​. Options not specified in a higher scope will be read from a lower one.  So if the option //ip// is unspecified,​ it will be read from //​net0/​ip//;​ if the option //net0/ip// is unspecified,​ it will be read from //​net0.dhcp//​.
Line 65: Line 73:
  
 **root-path** NFS/iSCSI root path.  The path to a network root filesystem. ​ Equivalent to DHCP option 17 (Root Path) **root-path** NFS/iSCSI root path.  The path to a network root filesystem. ​ Equivalent to DHCP option 17 (Root Path)
 +  iSCSI root path syntax: iscsi:<​servername>:​[protocol]:​[port]:​[LUN]:<​targetname>​
  
 **username** Username to be used for any authentication. ​ Currently only used by iSCSI. **username** Username to be used for any authentication. ​ Currently only used by iSCSI.
Line 82: Line 91:
 **dhcp-server** The dhcp server from which settings were obtained **dhcp-server** The dhcp server from which settings were obtained
  
-**dns-server** The DNS server to use for resolving hostnames+**dns** The DNS server to use for resolving hostnames
  
 **next-server** The (TFTP) server from which to obtain files when not specifying an HTTP URL **next-server** The (TFTP) server from which to obtain files when not specifying an HTTP URL
  
-**initiator_iqn_setting** The iSCSI initiator name+**initiator-iqn** The iSCSI initiator name
  
 **<​dhcp_opt_num>:<​format>​** Set a DHCP option by its number (ie. //​209:​string//​ for PXELINUX config file override) **<​dhcp_opt_num>:<​format>​** Set a DHCP option by its number (ie. //​209:​string//​ for PXELINUX config file override)
 +
 +**busid** This yields a five-byte hexadecimal code representing the adapter'​s bus type, followed by the two-byte vendor ID, followed by the two-byte device ID.  This could be handy for fetching an initrd or other RAM disk image containing the OS driver for the particular network adapter. ​ For example:
 +  gPXE> initrd http://​webserver/​initrd-${net0/​busid}
 ==SMBIOS== ==SMBIOS==
 Read-only access to the system'​s Systems Management BIOS.  Identifiers follow the format <​type>​.<​offset>​.<​length>:<​format>​. ​ Example: To read the Manufacturer name, //get smbios/​1.4.0:​string//​ will read SMBIOS offset 4 as a string. ​ Valid formats: string, uristring (for URI-friendly string format), ipv4, int8, int16, int32, uint8, uint16, uint32, hex, uuid Read-only access to the system'​s Systems Management BIOS.  Identifiers follow the format <​type>​.<​offset>​.<​length>:<​format>​. ​ Example: To read the Manufacturer name, //get smbios/​1.4.0:​string//​ will read SMBIOS offset 4 as a string. ​ Valid formats: string, uristring (for URI-friendly string format), ipv4, int8, int16, int32, uint8, uint16, uint32, hex, uuid
Line 95: Line 107:
  
 ====Other==== ====Other====
-**autoboot** Attempts to boot the system, as follows:+**autoboot** Attempts to boot the system, on each network interface in turn, as follows:
   * Wait for a link on ethernet   * Wait for a link on ethernet
   * Configure via DHCP   * Configure via DHCP
-  * Boot an embedded image (?) +  * Download ​(and exec) the DHCP-specified boot filename 
-  * download ​(and exec) the DHCP-specified boot filename +  * Boot from the DHCP-specified root path, using iSCSI or ATA-over-Ethernet (AoE)
-  * boot from the DHCP-specified root path, using iSCSI or ATA-over-Ethernet (AoE)+
  
 **exit** Exits gPXE, and passes boot control back to the BIOS, which generally attempts to boot the system using the next available boot method. **exit** Exits gPXE, and passes boot control back to the BIOS, which generally attempts to boot the system using the next available boot method.
Line 109: Line 120:
 ====Outstanding questions==== ====Outstanding questions====
   * What does autoboot do?  Does it simply execute a script, pre-defined at compile time?  Does it follow its own sequence of boot operations?   * What does autoboot do?  Does it simply execute a script, pre-defined at compile time?  Does it follow its own sequence of boot operations?
 +
 +> Autoboot is a hardcoded boot policy (at least in gPXE 0.9.7), with behavior as described above. ​ Eventually it would be nice to implement it as the default embedded gPXE script so it can be easily customized by users. ​ Today, if you don't like autoboot'​s behavior, you can try embedding a gPXE script (which will take precedence over autoboot). ​ You would have to modify the gPXE source code if scripts were not powerful enough for the behavior you want.
 +
 +-- [[stefanha@gmail.com|Stefan Hajnoczi]] 2009/03/24
 +
   * When multiple images of the same name are fetched, which one will takes precedence?   * When multiple images of the same name are fetched, which one will takes precedence?

Navigation

* [[:start|Home]] * [[:about|About our Project]] * [[:download|Download]] * [[:screenshots|Screenshots]] * Documentation * [[:howtos|HowTo Guides]] * [[:appnotes|Application Notes]] * [[:faq:|FAQs]] * [[:doc|General Doc]] * [[:talks|Videos, Talks, and Papers]] * [[:hardwareissues|Hardware Issues]] * [[:mailinglists|Mailing lists]] * [[http://support.etherboot.org/|Bugtracker]] * [[:contributing|Contributing]] * [[:editing_permission|Wiki Edit Permission]] * [[:wiki:syntax|Wiki Syntax]] * [[:contact|Contact]] * [[:relatedlinks|Related Links]] * [[:commerciallinks|Commercial Links]] * [[:acknowledgements|Acknowledgements]] * [[:logos|Logo Art]]

QR Code
QR Code commandline (generated for current page)