Ticket #4394 (closed defect: wontfix)

Opened 9 years ago

Last modified 9 years ago

Boot Order is not working with gPXE (NIC > CD-ROM > ...)

Reported by: juyeone Owned by:
Priority: major Component: other
Version: VirtualBox 3.0.0 Keywords: pxe gpxe boot order iscsi
Cc: Guest type: Windows
Host type: Linux

Description (last modified by frank) (diff)

I've just tried to test gPXE ( with iSCSI booting features on the VirtualBox.

My Boot Order is the below as you can see it on the log file.

  1. NIC
  2. CD-ROM

My test scenario is the below.

  1. After power on, Intel PXE fetch gPXE by chainloading feature of gPXE in dhcpd.
  2. Then, run it.
  3. gPXE could try to boot a remote disk through iSCSI. But, it would be failed cause of the disk blank.
  4. So, gPXE would hand the boot control over the next boot medium, CD-ROM.
  5. 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...


Screenshot-PXE iSCSI Boot [Running] - Sun VirtualBox-01.png Download (30.2 KB) - added by juyeone 9 years ago.
Screenshot-PXE iSCSI Boot [Running] - Sun VirtualBox-02.png Download (25.9 KB) - added by juyeone 9 years ago.
VBox.log Download (41.9 KB) - added by juyeone 9 years ago.

Change History

Changed 9 years ago by juyeone

comment:1 Changed 9 years ago by frank

  • Description modified (diff)

comment:2 Changed 9 years ago by frank

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.

comment:3 Changed 9 years ago by frank

  • Status changed from new to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use