Opened 16 years ago
Closed 15 years ago
#4394 closed defect (wontfix)
Boot Order is not working with gPXE (NIC > CD-ROM > ...)
Reported by: | Won Ju Yeon | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 3.0.0 |
Keywords: | pxe gpxe boot order iscsi | Cc: | |
Guest type: | Windows | Host type: | Linux |
Description (last modified by )
I've just tried to test gPXE (http://www.etherboot.org) with iSCSI booting features on the VirtualBox.
My Boot Order is the below as you can see it on the log file.
- NIC
- CD-ROM
My test scenario is the below.
- After power on, Intel PXE fetch gPXE by chainloading feature of gPXE in dhcpd.
- Then, run it.
- gPXE could try to boot a remote disk through iSCSI. But, it would be failed cause of the disk blank.
- So, gPXE would hand the boot control over the next boot medium, CD-ROM.
- Finally it could be possible to install some OS through iSCSI.
On the above steps, the system is halt on step #3. (See Screenshot-PXE iSCSI Boot [Running] - Sun VirtualBox-01.png)
Therefore, I guess there are some problem on the iSCSI Target side or on the VirtualBox. So, I just skipped the gPXE process. But, the boot process was not normal. (See Screenshot-PXE iSCSI Boot [Running] - Sun VirtualBox-02.png)
I just saw this gPXE is working well on VMWare. (You can see it on YouTube...) I think there are some problem to work with gPXE on the VirtualBox.
God bless you...
Attachments (3)
Change History (6)
by , 16 years ago
Attachment: | Screenshot-PXE iSCSI Boot [Running] - Sun VirtualBox-01.png added |
---|
by , 16 years ago
Attachment: | Screenshot-PXE iSCSI Boot [Running] - Sun VirtualBox-02.png added |
---|
by , 16 years ago
comment:1 by , 16 years ago
Description: | modified (diff) |
---|
comment:2 by , 16 years ago
comment:3 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm not sure if this is really a bug of VirtualBox. If the PXE boot process fails, for instance the PXE client could not download the boot file, the next boot device is selected and this works. In your case, gPXE is loaded. So the PXE boot process is successful, at least until this step. But gPXE fails itself and most probably calls int 18h which leads to the problem you see. I believe the behavior would be the same on real hardware.