2013-07-27, 16:27
2013-07-28, 04:14
from Etherboot.org:
Most often, you will want either .pxe, .kkpxe (for when you are using cached credentials, iirc), and .kkkpxe (usually the last two are in combination with pxelinux).
Typically I use .pxe here at home, and at work.
- .pxe is an image designed to be chain loaded, unloading both the underlying PXE and UNDI code sections
- .kpxe is a PXE image that keeps UNDI loaded and unloads PXE
- .kkpxe is a PXE image that keeps PXE+UNDI loaded and return to PXE (instead of int 18h). From here
Most often, you will want either .pxe, .kkpxe (for when you are using cached credentials, iirc), and .kkkpxe (usually the last two are in combination with pxelinux).
Typically I use .pxe here at home, and at work.
2013-07-28, 06:47
thanks man.
2013-07-29, 08:58
I just want to add to what Sedorox said.
You usually use a .pxe when you want to use native iPXE drivers, most likely loading ipxe.pxe using chainloading.
And .kpxe is most commonly used with undionly.kpxe, because it allows you to use the driver of the vendor PXE ROM (which is handy when iPXE doesn't support your card, or the iPXE driver is broken in some way).
I would have to argue that .pxe and .kpxe is the more commonly used forms, and .kkpxe is mostly used for buggy BIOSes and .kkkpxe is just for the ipxelinux.0 build (and nothing else).
I am also a user of ipxe.pxe at home, because all my hardware is supported.
You usually use a .pxe when you want to use native iPXE drivers, most likely loading ipxe.pxe using chainloading.
And .kpxe is most commonly used with undionly.kpxe, because it allows you to use the driver of the vendor PXE ROM (which is handy when iPXE doesn't support your card, or the iPXE driver is broken in some way).
I would have to argue that .pxe and .kpxe is the more commonly used forms, and .kkpxe is mostly used for buggy BIOSes and .kkkpxe is just for the ipxelinux.0 build (and nothing else).
I am also a user of ipxe.pxe at home, because all my hardware is supported.
2013-08-14, 22:45
Adding to what Robin said: It is possible, indirectly at least, to create an 'intermediate' script which determines if your hardware should chain ipxe.pxe or continue on with undionly.kpxe.
Example: 'checkipxe.ipxe'
It's not a perfect method, but if you have a reasonable hardware inventory you might find this workable.
Best,
M^3
Example: 'checkipxe.ipxe'
Code:
#!ipxe
#Check for known Platforms.
set 1_lp_c:int32 0
:1_prod_set isset ${product} || goto 1_end_c
:1_loop_0 set 1_product Latitude E6320 ; set 1_argument 1_stay-undi ; set 1_return_loop 1_loop_1 ; goto 1_function
:1_loop_1 set 1_product PowerEdge R720 ; set 1_argument 1_go-native ; set 1_return_loop 1_loop_end ; goto 1_function
:1_loop_end goto 1_stay-undi
:1_function iseq ${product} ${1_product} && goto ${1_argument} || goto 1_end_c
:1_stay-undi echo ; echo Attempting UNDI Boot Script... ; chain -ar ${17}/default.ipxe && goto 1_end_c || goto 1_end_c
:1_go-native echo ; echo Attempting Native Boot Kernel... ; chain ${17}/webipxe.pxe && goto 1_end_c ||
:1_end_c exit
It's not a perfect method, but if you have a reasonable hardware inventory you might find this workable.
Best,
M^3