iPXE handoff issues
|
2016-06-01, 00:01
Post: #1
|
|||
|
|||
iPXE handoff issues
So to start, I love iPXE, but can't use it.
I started off using gPXE a few months ago to install windows 7 to iSCSI drives on a NAS. I used a regular windows 7 install disk to install the OS after attempting a sanboot that failed because the iSCSI drive was blank. Then the BIOS did as it should and reverted to the next in the Boot Order which was CD. Since I used keep-san = 1 then the iSCSI drive stayed mounted and showed up as a local hard drive to the windows 7 installer CD. I cannot reproduce this ability with iPXE. I can still boot to windows 7 with gPXE and install on blank iSCSI drives with gPXE. With iPXE I cannot boot from or install to iSCSI. There are a lot of features of iPXE that I really want to use, like the built in menu system and the advanced command line and scripting options like using the sanhook command which is new compared to gPXE. In my experience iPXE has had some issues handing off control of the NIC to other programs. Example: I can boot gPXE, run dhcp then chain iPXE fine BUT If I run iPXE, get dhcp then chain gPXE, gPXE cannot obtain dhcp Example2: I can boot Windows Deployment services fine by itself and install to local drives, but if I chain wdsnbp.com from iPXE (with all the right gateway hacks) I can ping the iSCSI target and I see the static route to it with the gateway the same as the target. But Windows PE gives the error: "Windows cannot be installed to this disk. This computer's hardware may not support booting to this disk..." Example3: If I sanhook my iSCSI target, then exit iPXE to drop to CD install, windows PE does not see any NIC interfaces at all. Example4: I can boot from an iSCSI disk by using sanboot on gPXE, but when I use the same command from iPXE the boot fails to "A disk read error occurred" It seems like iPXE is not releasing the NIC to the next thing in each of these situations. I know that after a sanhook certain tunnels need to stay open so you don't lose connection to the target, but how come this worked in the past with the last version of gPXE but not anymore? I really would like to use the new features in iPXE, but if I can't get the basics that are already working in gPXE to work in iPXE then there is no point to move further. I read that windows installation media needs to be modified to allow it to install to an iSCSI disk. Why? It works with gPXE just fine. Can someone help me? I am chainloading undionly.kpxe from builtin PXE rom for both gPXE and iPXE. I got these files from the rom-o-matic sites from the tops of the latest builds. I have tried these examples above across various network cards and computer types with consistent results. Surely the compatibility that gPXE had with regular things like windows install discs shouldn't be lost to introduce new features right? Surely things can't actually be HARDER in iPXE to accomplish than in gPXE right? If I can't get iPXE to work, I will have to stick with gPXE because that is working, but boy would I like to be able to use the new command line options from iPXE. |
|||
2016-06-03, 16:51
Post: #2
|
|||
|
|||
RE: iPXE handoff issues
(2016-06-01 00:01)jbirlingmair Wrote: I used a regular windows 7 install disk to install the OS after attempting a sanboot that failed because the iSCSI drive was blank. Then the BIOS did as it should and reverted to the next in the Boot Order which was CD. What script (or DHCP configuration) are you using to hook the SAN disk and exit without unhooking? Michael |
|||
2016-06-03, 19:46
Post: #3
|
|||
|
|||
RE: iPXE handoff issues
(2016-06-03 16:51)mcb30 Wrote: What script (or DHCP configuration) are you using to hook the SAN disk and exit without unhooking? Thanks for the reply Michael! I can hit Ctrl-B once gPXE is chainloaded from PXE and run: Code: dhcp net0 If there is an operating system installed at the iscsi address then it boots, otherwise it fails and preserves the connection to SAN disk and moves on to the next in the BIOS boot order which I have set to CD. When I chainload iPXE from PXE I run the following: Code: dhcp net0 When I attempt to boot to an already known working image on an iSCSI disk I use the following: Code: dhcp net0 |
|||
2016-06-03, 19:59
Post: #4
|
|||
|
|||
RE: iPXE handoff issues
Quote:When I attempt to boot to an already known working image on an iSCSI disk I use the following: Let's fix that one first, since it should be the simplest. What do you see if you build with DEBUG=int13:3? Michael |
|||
2016-06-03, 20:25
Post: #5
|
|||
|
|||
RE: iPXE handoff issues
(2016-06-03 19:59)mcb30 Wrote:Quote:When I attempt to boot to an already known working image on an iSCSI disk I use the following: Ok, so far I have been using undionly.kpxe that I was able to get from the rom-o-matic.eu site. Since then I have not been able to get to the site from my work computer. I can try getting back to it at home later. At work I was able to get to GitHub and download your mirror of the iPXE source code. I am currently in the process of getting an environment setup that I can build iPXE from here at work. I will get back to you once I can. Thanks for the suggestion. |
|||
2016-07-06, 16:06
Post: #6
|
|||
|
|||
RE: iPXE handoff issues
(2016-06-03 20:25)jbirlingmair Wrote:(2016-06-03 19:59)mcb30 Wrote:Quote:When I attempt to boot to an already known working image on an iSCSI disk I use the following: Ok, so now that I have finally built undionly.kpxe for myself. All of these issues have gone away. I think there was an issue with the version I was using before. Thanks for the suggestion. |
|||
2016-07-11, 23:03
(This post was last modified: 2016-07-11 23:07 by jbirlingmair.)
Post: #7
|
|||
|
|||
RE: iPXE handoff issues
OK, so I guess I spoke too soon.
I no longer get "A disk read error occurred." I can fully boot into the OS and use the iSCSI disk. What I am still having trouble with is the handoff from iPXE to the CD. When I chainload iPXE from PXE I run the following: Code: dhcp net0 I am still having that issue. Should I be using undionly.kkpxe? |
|||
2016-07-12, 05:48
Post: #8
|
|||
|
|||
RE: iPXE handoff issues
(2016-07-11 23:03)jbirlingmair Wrote: OK, so I guess I spoke too soon. OK, so we have fixed the first problem, and you are now able to use undionly.kpxe to boot from an iSCSI disk. We can now look at the second problem, which is how to perform an installation to an iSCSI disk. Using "sanhook" and "keep-san" and then exiting back to the BIOS is not a supported method, and never will be. It may happen to work on some platforms. It's pure luck when it does, and will not be considered a bug when it doesn't. There is no way for iPXE to control what the BIOS does after iPXE exits. The correct approach is to hook a SAN disk and then boot the installer over the network, without exiting from iPXE. There are several documented methods. For example: http://ipxe.org/howto/winpe shows you how to network boot WinPE and includes a section on installing to an iSCSI target. You can also use deployment tools such as WDS: see http://ipxe.org/howto/wds_iscsi. For Linux installations, see http://ipxe.org/howto/rh_san. The common flow path in all of these methods is to first hook a SAN disk (via "sanhook" or via the DHCP root-path parameter) and then to run an installer (via "chain" or the DHCP filename parameter). Hope that helps. Michael |
|||
2016-07-12, 17:19
(This post was last modified: 2016-07-12 17:28 by jbirlingmair.)
Post: #9
|
|||
|
|||
RE: iPXE handoff issues
(2016-07-12 05:48)mcb30 Wrote: Using "sanhook" and "keep-san" and then exiting back to the BIOS is not a supported method, and never will be. It may happen to work on some platforms. It's pure luck when it does, and will not be considered a bug when it doesn't. There is no way for iPXE to control what the BIOS does after iPXE exits. It makes total sense that once iPXE exits, that all bets are off and everything is out if it's control. Any idea why it works in gPXE? It seems like gPXE releases the network interface for use by the next item in the boot order. How it does this while maintaining connection to the iSCSI target, I have no idea. iPXE doesn't seem to release lock on the network interface to the next in the boot order. Just curious, is it possible to chain into a setup.exe on a CD? I have the WDS solution working, just need to fix a iSCSI drive MBR on one of our drives, and I know the repair tools on the WindowsPE disc I have will work. I will get started on netbooting WinPE. Better yet, if I can add in the diagnostic and repair tools into one of my WDS boot WIMs then I can just use that. |
|||
2016-07-12, 18:42
Post: #10
|
|||
|
|||
RE: iPXE handoff issues
(2016-07-12 17:19)jbirlingmair Wrote: It makes total sense that once iPXE exits, that all bets are off and everything is out if it's control. As I said, it's pure luck. A random single byte change in the binary can make the difference between this working and not working. As a matter of policy, I refuse to even attempt to "debug" this kind of failure, because it's explicitly not supported. Quote:Just curious, is it possible to chain into a setup.exe on a CD? Unlikely. Quote:I have the WDS solution working, just need to fix a iSCSI drive MBR on one of our drives, and I know the repair tools on the WindowsPE disc I have will work. Excellent. Good luck! Michael |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 3 Guest(s)