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
commandline [2008/07/07 21:43]
hawke
commandline [2010/02/16 08:24]
pscheie
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. 
 + 
 +**imgstat** ​ List images currently held in memory. 
 + 
 +**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 52:
 **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 65:
   * **[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 75:
  
 **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 93:
 **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) 
 + 
 +**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, 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
  
 **uuid** The system'​s UUID **uuid** The system'​s UUID
  
 ====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 107: Line 122:
 ====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)