PXE has a long history
PXE Server Dell PowerEdge T300 Windows Server 2008 R2 Enterpriese x64 JP Altiris DS 6.9 SP3 DHCP Options: gPXE Boot Strap: Either of below files has same issue. Pxe But Gpxe Extensions Not Detected Working Pxe But Gpxe Extensions Not Detected On Ipad gPXE is an implementation of the PXE specification for networkbooting, with extensions to allow additional features such as bootingvia HTTP, iSCSI, and AoE. PXE in this case is simply a BIOS extension. Most modern motherboards have a NIC integrated (and the PXE capability in the 'main' BIOS). If you buy a NIC without the (programmed) EPROM, you can program an EPROM or an EEPROM by yourself and put it in it.
But essentially its a 16 Bit program that uses the environment setup by an x86 BIOS bootloader to then pull another bootloader across a network and then starts that.PXE is a routine that implements a [step] on the way from boot a machine to executing an operating system.
BIOS gets a motherboard, systemboard, or pc computer running, from power on it tests then manually configures all the attached devices to make them ready for the programs that follow.
BIOS also has a long history, from the IBM PC to the Phoenix and AMI versions of the original up to the present day.
IBM published its BIOS code and the versions that came after used it as a means to produce a set of assumptions called the Application Program Interface (API) to then write code that could take over and continue the process of getting work done.
Microsoft wrote a 'kernel' to take over this job and it had a driver API and a DOS programming API.
Linux had similar 'kernels' and a choice of pre Linux kernel 'bootloaders', Lilo, Grub, Syslinux
PXElinux is a variant of the last to pull the final Linux kernel piece over the network and start it up.
Etherboot was a project to place a netboot or PXE code in a network adapter ROM so that BIOS would chain to it and start it up, by-passing the need for a local mass storage device, or to rewrite the BIOS code such that it included these routines.
gPXE was an attempt to modularize and enhance Etherboot.
iPXE was a branch or fork from gPXE that took a different direction to do similar things
Meanwhile Syslinux continued to do what it did very well, it bootstraped existing BIOS boot devices from anything the BIOS could itself boot from, into later bootstrap or kernel code.
Syslinux support for iPXE was attempted to unify and benefit both, letting each specialize in what it did best.
Neither Syslinux or iPXE had code to support USB devices.. exactly, some BIOSes will support native Flash or Memory chips which are inserted into SD or USB slots for booting. But generally do not have generic support for all the possible types of USB devices that might be inserted into a slot connected to a USB controller that is supported by a BIOS.
A USB network adapter is a USB device with an Ethernet controller at the end of a USB cable. When it is inserted into a USB slot, the BIOS must recognize the event, then initalize or setup the device and support communications with it. Then any program that needs to use it for network communications, like a PXE routine, must further initialize the network controller across the USB bus for communications and then carry out a few simple operations to download and execute an additional bootstrap or kernel code.
In order to add USB network adapter support to the Syslinux or iPXE bootloader code, a driver needs to be created to seek out and start or work with a USB controller, then command it to find the USB network adapter on the USB bus and initialize it for communications and carry those communications out.
First we need a development platform.
Then we need a USB network adapter and a USB bus and controller to work with.
VMware Player is known for good USB 2.0 controller support.
So we can connect a USB network adapter to the VMware Player host and connect it to the virtual machine, then run the command 'lsusb' to detect the USB device the Linux kernel detected upon insertion.
This obviously worked indicating I attached a ASIX AX87722A Fast Ethernet 10/100 Adapter
Technical documentation and driver source code for a Linux kernel is available here:
AX88772A Drivers Download
For Linux kernel 2.6.9 to 2.6.13 ( 9-11-2007 )
The driver source appears as a single .C file and .H header file that produces a single usbnet.ko module file which can be compiled and linked with linux kernel libraries and code to produce a driver to support the AX88772A chipset, taking advantage of the linux kernel support for the USB bus chipsets.
The [Readme] file in the source code tarball seems to indicate it supports both types of ASIX adapter
ASIX AX88178 USB2.0 Gigabit Ethernet Network AdapterBalaji Rao already appears to have tried to add USB network adapter support to gPXE here
ASIX AX88772 USB2.0 Fast Ethernet Network Adapter
Enabling gPXE to use USB Ethernet Adapters
iPXE shares a common ancestry with gPXE, so it would make sense to investigate the approach he took and see if it could be used to enable iPXE to use USB Ethernet Adapters.
As far as I could tell (and this is second hand information) Balaji started the project inbetween jobs and ceased working on the project after acquiring a new position.
He did create a Git repository which can be checked out:
# git clone git://git.etherboot.org/people/balajirrao/gpxe.git -b usb
There is a browse-able Git repository view here:
http://git.etherboot.org/people/balajirrao/gpxe.git/
The work appears to have stopped 8-21-2008 around 5:50 pm
From the log entries it appears he got support for OHCI and UHCI controllers working, and targeted specifically the USB network chipsets
Changing into the locally git clone repository and then into the src directory and typing the 'make' command results in a stream of compilation messages including :
Then we need a USB network adapter and a USB bus and controller to work with.
VMware Player is known for good USB 2.0 controller support.
So we can connect a USB network adapter to the VMware Player host and connect it to the virtual machine, then run the command 'lsusb' to detect the USB device the Linux kernel detected upon insertion.
This obviously worked indicating I attached a ASIX AX87722A Fast Ethernet 10/100 Adapter
Technical documentation and driver source code for a Linux kernel is available here:
AX88772A Drivers Download
For Linux kernel 2.6.9 to 2.6.13 ( 9-11-2007 )
The driver source appears as a single .C file and .H header file that produces a single usbnet.ko module file which can be compiled and linked with linux kernel libraries and code to produce a driver to support the AX88772A chipset, taking advantage of the linux kernel support for the USB bus chipsets.
The [Readme] file in the source code tarball seems to indicate it supports both types of ASIX adapter
ASIX AX88178 USB2.0 Gigabit Ethernet Network AdapterBalaji Rao already appears to have tried to add USB network adapter support to gPXE here
ASIX AX88772 USB2.0 Fast Ethernet Network Adapter
Enabling gPXE to use USB Ethernet Adapters
iPXE shares a common ancestry with gPXE, so it would make sense to investigate the approach he took and see if it could be used to enable iPXE to use USB Ethernet Adapters.
As far as I could tell (and this is second hand information) Balaji started the project inbetween jobs and ceased working on the project after acquiring a new position.
He did create a Git repository which can be checked out:
# git clone git://git.etherboot.org/people/balajirrao/gpxe.git -b usb
There is a browse-able Git repository view here:
http://git.etherboot.org/people/balajirrao/gpxe.git/
The work appears to have stopped 8-21-2008 around 5:50 pm
From the log entries it appears he got support for OHCI and UHCI controllers working, and targeted specifically the USB network chipsets
Changing into the locally git clone repository and then into the src directory and typing the 'make' command results in a stream of compilation messages including :
Which indicates [bin/usbcore.o][bin/urb.o][bin/uhci_hcd.o][bin/ohci_hcd.o] all cleanly compiled for gPXE. Those 'appear' to be similarly named components for a USB bus support system under Linux recreated in a gPXE kernel environment.
Later [bin/asix.o] 'appears' to be cleanly compiled
This entry suggests ASIX 88772 support might exist within the code
struct usb_driver asix_88772_usb_driver
This entry suggests he was using QEMU to start and test the code in a virtual machine and ran into some problems around 8-3-2008
[USB] Control transfers work properly as verified by qemu debugging messages. But its still qemu crashes for some reason.
This entry on 8-12-2008 suggests he got ohci code working
[USB] OHCI now works on bare metal.
This entry on 8-14-2008 suggests he got USB working
[USB] Kind of works..
from this we can [kind of] conclude he got it working.
It appears to me he based his design on the modular USB support developed for the Linux kernel and ported or re-implemented it in the gPXE kernel environment. Because of the mention of URBs I assume once he got the OHCI controller working, adding support for the UHCI support did not take much more effort (or he didn't have the hardware to test it).
Specifically it looks like he got an OHCI controller to work with possibly an ASIX AX88771 based USB network adapter after modifications to the OHCI and ASIX code.
Replicating his success, would be a good first step to broadening the support.
Another interesting tidbit:
Balaji seems to have documented using qemu to test gPXE.usb compilations here:
Using gPXE with QEMU
Build the gPXE from the instructions in the gPXE tarball. There will be a gpxe.usb file created in src/bin/ directory. That will be the USB image of the gPXE ROM which can be put into a bootable USB mass storage device. Now execute the following command
qemu -hda bin/gpxe.usb -net nic -net user -bootp http:/etherboot.org/gtest/gtest.gpxe
http://quark.entity.com/gtest/gtest.gpxe
represents where to download the kernel from using PXEQemu usb data snooping
While working on gPXE I had to snoop USB data for various reasons.
Here's how to do it.
QEMU
If your testing gPXE using QEMU, then your in luck. You can uncomment the lines starting with #define DEBUG_* in the QEMU source code and recompile. Now when you run QEMU, you get a tons of very valuable information from the console.
This will make QEMU run a bit slow. But who cares when they're debugging! The best thing about this approach is that the data being printed by QEMU is in a user readable format.
USBMON
This method is a bit involved. First you have to mount the debugfs in /sys/kernel/debug. Then change to the mounted directory into a directory called usbmon. There you'll see many files similar to 0t,0u,1t,1u,2t,2u etc. The files prefixed with a ‘u' are supposed to provide output in a newer format. The number represents the kernel assigned USB bus number for a controller. The bus number your device is connected to can be obtained by running # lsusb.
Once you've found the bus you can (for example) ‘cat 3t' to see tons of information of this form.
The format of the output is documented in a in text file located in the Linux Kernel Documentation/. You can also get it here.
This method is commonly used by device driver writers.
The device they're writing a driver for is connected from a Linux host via a pass-through-ed to a QEMU virtual machine. Then they run some OS like Windows in the QEMU virtual machine and when the windows driver interacts with the device, it can be snooped.
Examining the interactions, people reverse engineered Linux drivers from the behavior of the Windows drivers!
This is consistent with the git repo commit comments.
Another way is to mount the usbmon fs and then use Wireshark to treat the USB buses like network interfaces and 'interpret' the USB traffic on the fly.
Sniffing USB Traffic - Different Approaches
usbmon captures
tshark -D
' to list all the interfaces. You should see the usbmonX
interfaces listed. You'll need to figure out which one is applicable to your device, but that shouldn't be too hard if you run 'cat /proc/bus/usb/devices
'.Bus=04
', then you need to capture using 'tshark -i usbmon4
'. And of course, if you want to save the packets to a .pcap
file, then you also need to specify '-w outfile
'.Useful tips:
# modprobe asix
# modinfo asix | grep v0B95
# lsusb -t
# qemu -cdrom gpxe.iso -net nic
> CTRL-B
>gPXE config
(Interesting progress in testing the code)
So.. in VMware Player, Centos 5, running qemu virtual machine booting from the gPXE.iso with the ASIX driver (apparently) the code [does] recognize the ASIX AX88772A based USB-2-NIC adapter I had attached to my desktop, pass-through VMware to the Centos virtual machine, pass-through to qemu virtual machine and assigned to net0
# lsusb -t
Bus# 1
`-Dev# 1 Vendor 0x0000 Product 0x0000
`-Dev# 2 Vendor 0x0b95 Product 0x772a
Red Hat 5 (Centos 5) appeared to have a problem loading gpxe.usb images so I used the gpxe.iso qemu cdrom option instead.
Also the qemu -device option wouldn't be available until a later version, so I used the -usbdevice option instead.
# qemu -cdrom gpxe.iso -net nic -net -user -usbdevice host:0b95:772a
really did not expect that to happen, it appears to initialize the USB controller and correctly identify the ASIX chipset and load that driver.
By re-routing the VMware connection to the host system, a Windows 7 desktop, I can confirm the MAC address for the ASIX USB-2-NIC adapter does indeed have that MAC Address
Next Day
centos already has usbmon built-into the kernel so # modprobe usbmon doesn't work, however simply mounting the debugfs does work, and you can cat 0t or 0u usb controller communications.
note to self: installing the vmware-tools and running the setup config makes handling gnome so much nicer, hello dynamic screen resolution
Wireshark did not get USB packet decode capability until version 1.2 the default yum repo for centos 5 only has wireshark 1.0, there don't appear to be repos that have it back ported or back compiled or back packaged.. but the source code is available. I saw a recommendation to us fedora 14 src packages for Wireshark 1.10 and that should compile.. maybe
# mkdir ws
# cd ws
# wget http://www.wireshark.org/download/src/all-versions/wireshark-1.2.0.tar.gz
# yum install gtk2-devel
# yum install libpcap-devel
# unpack the ws source
# ./configure
# make
# make install
Wireshark needs at least libpcap 1.0 to support usbmon, centos 5 only has libpcap 0.9
# mkdir lp
# cd lp
# wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
# tar -zxvf libpcap-1.1.1.tar.gz
# ./configure
# make
# make install
Recompile Wireshark to use the replacement libpcap libraries
#cd ws
# make clean
# ./configure
# make
# make install
Coencidently Matt Cutts has nice article on 'Compiling a USB Program' with lots of how to references
http://www.mattcutts.com/blog/compile-a-simple-usb-program-in-linux/
Useful qemu options
http://doc.opensuse.org/products/draft/SLES/SLES-kvm_sd_draft/cha.qemu.running.html
Refined qemu start command [doesn't create a virtual pci nic to distract things]
# qemu -cdrom gpxe.iso -net none -usbdevice host:0b95:772a
# mount -t debugfs non_debugs /sys/kernel/debug
# /usr/local/bin/wireshark
Step by Step
Finally capturing and analyzing USB packet traffic 'Live'
So now I can start tweaking the code to see why it's not pulling a dhcp address.
Wiki HomeBoot Issues Client Diskless Boot Failed
Client Diskless Boot Failed
2019/06/26 21:10
1. Failure of booting from network
1) The first booting item in the BIOS is not 'boot from network'.
2) The electricity in the BIOS battery is not enough.
3) The BIOS setup is in a mess, please reset up the BIOS.
4) Because of the humid climate, the connection between the RAM and main board is not good. Please wipe the gold fingers in the RAM.
5) The network cable is not well plugged.
6) Sometime the client do not boot, even after checking all possibility in server. This means issue is with network switch, you need to power cycle the switch (turn off/ on) once. After that clients will boot fine. If this happens frequently. We recommend replacing the switch with a better one.
7) Client will fail to boot if the IP address of client PC is conflicted with another PC or device (Wifi Extender, router, or mobile devices). If this happens please change the IP of the devices and reboot the client.
2. Stops at DHCP
The client stops at DHCP when booting and the address of the sever IP can't be obtained.
1) Problem of the network: testing method, use one computer to PING server and use the server to PING the computer.
2) Problem of the switch. Solution: check the main switch and the sub switch to see whether the power supply is normal.
3) Problem of network cable. Solution: Check whether there is a problem for the client network cable and the server network cable and make sure they have been connected to a LAN.
4) Problem of the firewall. Solution: Shutdown the firewall of the server.
5) The CCBoot service stops. Solution: Click the 'start' button in the main interface of CCBoot, start the CCBoot service.
6) The server port needed by DHCP is blocked. Solution: open port 67 on the server.
7) The client is not added to the user list of CCBoot and the server of CCBoot hasn't enabled the 'auto add client' option.
3. Stops at the TFTP
In the process of booting of the client, DHCP can obtain the IP address of the server, but it stops at location of 'TFTP' and the error of TFTP occurs.
1) CCBoot hasn't started the TFTP service.
2) The firewall of the server system does't open TFTP port, solution: to open the port 69 in the firewall.
3) Reset up TFTP. Solution: in the tool bar of the main interface of CCBoot, click 'Options' button. In the popup dialogue box of 'CCBoot Setting', choose the 'DHCP Setting' tab, and unselect the 'TFTP' check box. Click the 'Yes' button, and reselect the check box of the 'TFTP'.
4) On new motherboards, sometimes 'gpxe.pxe' and 'gpxex.pxe ' will take much time to start windows booting. In this case you can use 'ipxe.pxe'.
Figure 1-1
4. Stops at www.ccboot.com
1) PXE's loading file problem. The default PXE file doesn't support some special network card.
Solution: Change PXE file, take the examples of PC101, the concrete procedures are as follows:
a. In the main interface of the CCBoot, click 'Client Manager' and double click 'PC101' in the right detail box.
Figure 1‑2
b. The 'CCBoot Client' dialogue box pops up, changes the default 'gpxe.pxe' in the editing box into 'gpxex.pxe' and click 'save' button.
Figure 1‑3
Note: It would be better to use 'gpxe.pxe', but if you cannot diskless boot the client via using 'gpxe.pxe', you can try to change the PXE value to 'gpxe0.pxe'. If this doesn't work, please modify the value to 'gpxex.pxe'. If you can successfully use 'gpxe.pxe' in CCBoot 20120817, but failed to use it in the new build, please try 'gpxe1.pxe'. From CCBoot v3.0 Build 20130710, 'gpxe1.pxe' means 'gpxe.pxe' of 20120817. If Realtek 8111E NIC has blue screen problem, you can try to change the PXE value to 'ipxe.pxe'.
2) If your disk sorting is wrong, the client will only read 1k and stop, please find the solution as below.
a. In the left side of the CCBoot form, click the 'Disk Manager' node on the directory tree, and select the game disk group node, you'll find the image disk is on the bottom of this disk group (Figure 1-3).
Figure 1-4
b. Right click the image disk and click the 'Move Disk Up' button (Figure 1-4).
Figure 1-5
Note: Please select the 'Bootable' check box in the image disk properties.
5. No more network devices/iSCSI boot 192.168.0.1::3260:: error occurs
When booting the client, the error of 'iSCSI boot 192.168.0.1: 3260: No more net work devices' occurs.
The reasons of error and the solution are as follows:
1) Format writeback disk if you see 'No more network devices' and 'Not supported'.
2) The trial version of CCBoot only supports 5 users, if the number exceeds 5, it will stop at 'iSCSI boot 192.168.0.1: 3260'. Solution: Purchase the serial number and register.
3) The registered number has been exceeded. Solution: Add license number.
4) In the 32 operation system, the single process shall not exceed 1.6 G. When the CCBoot process reaches 1.6 G, the CCBoot server can no longer allocate memory and then error occurs. Solution: Change the server into the 64 bit operation system.
5) The router has opened DHCP and it has disturbed the normal operation of the client. Solution: shut down the inbuilt DHCP of the router.
6) In the LAN, other software has opened DHCP functions. Solution: temporarily shut this software and reboot it after client is in normal startling.
7) The disturbing of the DHCP for CCBoot. For example: in the same LAN, there are two CCBoot servers, two servers are prepared for the load balance (please check the 'CCBoot load balance' chapters for details). The server A has deleted the client PC 101, when the client PC101 reboots, it stops at the 'No more network devices'. Solution: open the installation folder of the server B, copy the 'db.xml' file to the installation folder of server A and replace the file of the same name.
8) In 'CCBoot Client' dialog box, the 'Disk Group' hadn't been assigned. Please select a disk group.
9) Maybe the BIOS battery has no power.
10) The image has problems.
11) The client of the CCBoot property doesn't set the 'Boot Server Address'.
12) Haven't set correct writeback path in the CCBoot client properties.
6. Stop at Windows Logo
For details, please refer to 'Stop at Windows Logo'.
7. Blue screen when the client boots
Cause and solution are as follows:
1) The physical RAM of client has problems. Solution: Change the client physical RAMS.
2) The network driver has problems. Solution: change other versions of network card driver.
3) Software conflict (for example, billing software). Solution: uninstall some software which can cause conflicts.
4) The problem of images package. Solution: Remade image package.
8. Automatic restart
Before the client boots to desktop and reboot automatically, the causes and solutions are as follows:
1) When the client writes cache setting of the client is too big, the client will start automatically. Solution: Adjust the size of client write cache.
2) Problem of network card driver. Solution: Change other versions of network card driver.
9. Stops at NTLDR is missing
The client boots with hardware profile image (Please refer to the 'CCBoot single image package+ multiple settings PnP' for details). Then the client will stop at the picture shown.
Figure 1‑6
There are the following reasons for the phenomenon above:
Setting error of hardware configuration
In the properties of the client, there's no correctly written hardware ID. Solution: input the correct hardware ID.
Problem of the CCBoot version
If using the CCBoot2.1 version for setting multiple configurations of hardware, there's certain possibility for the phenomenon above. Solution: updates to the CCBoot3.0 version.
10. Stops at the PXE-MOF Exiting PXE ROM
Problem of PXE loading file
The PXE loading files of CCBoot doesn't support the diskless boot of the client. Solution: Change the PXE loading files.
Solution: Change PXE file, take the examples of PC101, the concrete procedures are as follows:
1) In the main interface of CCBoot, click 'Client Manager' and double click 'PC101' in the right detailed box.
Figure 1‑7
2) The 'CCBoot Client' dialogue box will popup and change the default 'gpxe.pxe' in the edit box into 'gpxex.pxe' and click 'Save' button.
Figure 1‑8
Note: If this problem still cannot be solved by using the above method, please try to update the BIOS ROM to the latest version.
11. Diskless Boot Failed with Two NICs
Problem:
If you have two NICs on the client, one is Realtek and the other is the built-in wireless card. Sometimes, after uploading image, you can not diskless boot the client successfully.
Solutions:
1) As CCBoot can not diskless boot with wireless card. You should disable the wireless card on the client first; otherwise, CCBoot will treat the wireless card as the boot NIC. You can disable the wireless card in Device Manager.
2) Install 'CCBootClient' program.
3) Upload image.
4) Diskless boot the client.
Pxe But Gpxe Extensions Not Detected Invalid
Note:
If you want to use the disabled NIC in the future, after diskless booted the client successfully, you can enable super client for this PC, and then go to Device Manager to enable that NIC. Finally, disable super client. For details, please refer to 'Create Client Image with Dual NICs'.
12. Error Message of 'Database server security does not have a computer account for the trust relationship with this workstation'
If you encountered an error message of 'Database server security does not have a computer account for the trust relationship with this workstation' when diskless booting CCBoot v3.0, there may be two reasons for this problem.
Reason 1 It may because that you haven't added the computer name on CCBoot AD.
Please follow the following steps.
1) Open the CCBoot installation directory, copy 'CCBootAD.exe' files to the domain server.
2) Run the 'CCBootAD.exe' program on the domain server.
3) Click the 'Add' button in the popup 'CCBoot AD' dialog box.
Figure 1-9
4) Click the '...' button in the popup 'CCBootAD Machine' dialog box to select domain 'Computers', type PC101 into the 'Machine Name' edit box, and click the 'OK' button, then the operation is completed.
Figure 1-10
5) If you want other clients to join the domain as well, you can repeat the above operation steps.
6) Add a domain user of User001.
7) Add other domain users.
Reason 2 It may because that you haven't added 'joindomain'.
Please follow the following steps.
1) Click the 'Options' button on the toolbar of CCBoot main interface.
Figure 1-11
2) In the popup 'CCBoot Options' dialog box, click the 'General' tab, select the 'Run Batch Command at Client' check box, then click the '>>' button in the right side of the 'Run Batch Command at Client'.
Figure 1-12
3) Add an order of 'joindomain domain name' at the bottom of the popup 'public - Notepad' (E.g. 'joindomain test.com'), and enable clients to join the 'test.com' domain.
Figure 1-13
Note: You can also watch the video of 'How to Use CCBoot in Windows Domain' (about 06:55).
13. Connect Host Failed
Please check whether the client and server can ping each other successfully or not. Also, you can try to change the client IP address, and delete the old client on CCBoot server, and then auto scan the new changed IP. Besides, please check whether the Windows firewall has been turned off.
14. PXE Boot Windows 8 Failed
For details, please refer to http://www.ccboot.com/how-to-solve-pxe-boot-windows-8-failed.htm.
15. 'Failed to Start TFTP' and' Failed to Start DHCP'
If the server IP address was changed, it will report the error of 'Failed to Start TFTP' and 'Failed to Start DHCP'. You can solve this problem according to the following steps.
1) On CCBoot main interface, click the 'Options' button.
2) In the pop up 'CCBoot Options' dialog box, click the 'DHCP Settings' tab, and then click the 'DHCP Server IP' combo box, and select the right IP address.
Figure 1-14
16. After windows activation
If you still cannot diskless boot your client properly then the issue is in client hardware.
Sometime bad parts or components cause the client to fail to boot.
The main culprit for this is usually CPU or RAM and sometime NIC as well.
So check then by replacing them with working PCs components.