Two patches, pushed to my github account:
https://github.com/jimi1283/cobbler/commits/esxi-improvements
The ESXI5 patch requires the gpxe patch, since the only sane way to add the support for it to cobbler was via the gpxe process documented in the VMware build guide. This allows all of the files to be served via httpd, otherwise you have to copy the entire ISO contents to a TFTP directory (which required some ugly hacking in cobbler).
The one caveat about the gpxe process is that you must manually copy the undionly.kpxe file to your tftp directory. Newer distros package the etherboot files, otherwise you'll have to download the files from http://etherboot.org/wiki/download and build the file yourself (it's a fairly painless process). Another TODO is to make the same setup changes for DNSMASQ, right now this only supports ISC DHCPD.
There is a new setting called enable_gpxe, which is used currently only when new items are created. There is also a new field for systems and profiles by the same name, which sets it on a per-object basis. This isn't being used for profiles yet, nor will it work on systems without an interface and MAC specified, but when enabled on a system with a MAC it will create an entry in dhcpd.conf that is configured to chain load the undionly.kpxe file. I plan on adding support for generic profiles and systems without a MAC, but it might be a some-what convoluted process and I'm trying to work out the best way to do it (currently it'd involve chain loading gpxe, and then detecting that you don't want to use gpxe and chain loading back into the old pxelinux.0 file).
I plan on merging these into master in the near future unless people have major issues during testing. Enjoy!
As I never managed to get a good explanation myself in past years when people were asking for it, can you explain what GPXE does differently, and how much of the normal PXE chain it replaces, and when you *can't* use it? Is TFTPd completely out of the equation? The etherboot page talks about legacy boot ROMs, etc, but doesn't really make the case for itself. Not arguing against, but I'd just like to have it explained what it actually does. In any event, we need to be able to answer that when folks ask, and it seems the manpage or Wiki, at least, needs to explain usage.
+ ks_mirror_name = string.join(distro.kernel.split('/')[-2:-1],'') 862
FYI -- This seems to imply the distro must be mirrored by Cobbler. It seems like the code needs to anticipate this this possibility?
--Michael
On Sun, Nov 27, 2011 at 11:58 AM, James Cammarata jimi@sngx.net wrote:
Two patches, pushed to my github account:
https://github.com/jimi1283/cobbler/commits/esxi-improvements
The ESXI5 patch requires the gpxe patch, since the only sane way to add the support for it to cobbler was via the gpxe process documented in the VMware build guide. This allows all of the files to be served via httpd, otherwise you have to copy the entire ISO contents to a TFTP directory (which required some ugly hacking in cobbler).
The one caveat about the gpxe process is that you must manually copy the undionly.kpxe file to your tftp directory. Newer distros package the etherboot files, otherwise you'll have to download the files from http://etherboot.org/wiki/download and build the file yourself (it's a fairly painless process). Another TODO is to make the same setup changes for DNSMASQ, right now this only supports ISC DHCPD.
There is a new setting called enable_gpxe, which is used currently only when new items are created. There is also a new field for systems and profiles by the same name, which sets it on a per-object basis. This isn't being used for profiles yet, nor will it work on systems without an interface and MAC specified, but when enabled on a system with a MAC it will create an entry in dhcpd.conf that is configured to chain load the undionly.kpxe file. I plan on adding support for generic profiles and systems without a MAC, but it might be a some-what convoluted process and I'm trying to work out the best way to do it (currently it'd involve chain loading gpxe, and then detecting that you don't want to use gpxe and chain loading back into the old pxelinux.0 file).
I plan on merging these into master in the near future unless people have major issues during testing. Enjoy! _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Sun, Nov 27, 2011 at 12:35 PM, Michael DeHaan michael.dehaan@gmail.com wrote:
As I never managed to get a good explanation myself in past years when people were asking for it, can you explain what GPXE does differently, and how much of the normal PXE chain it replaces, and when you *can't* use it? Is TFTPd completely out of the equation? The etherboot page talks about legacy boot ROMs, etc, but doesn't really make the case for itself. Not arguing against, but I'd just like to have it explained what it actually does. In any event, we need to be able to answer that when folks ask, and it seems the manpage or Wiki, at least, needs to explain usage.
The primary advantage is the ability to do everything through httpd. This gives you the ability to bypass the layer 2 restriction of DHCP without having to resort to tricks like Cisco's ip-helper. This isn't the only advantage - gpxe lets you boot remotely over a LOT of different medium (AoE, iscsi, etc.). The newer versions of kvm/libvirt have built-in gpxe support for their virtual NIC drivers, so chain loading for a KVM guest isn't even required.
- ks_mirror_name = string.join(distro.kernel.split('/')[-2:-1],'')
862
FYI -- This seems to imply the distro must be mirrored by Cobbler. It seems like the code needs to anticipate this this possibility?
Yes and no - there's no reason the http server in question has to be cobbler. Covering that case would be a todo, but I didn't give it priority since I believe the number of people who use the --available-as option are relatively small. I'm pretty sure that option doesn't work with esxi4 either (since at least 6 files need to be copied to the tftp directory), so I figured the people who'd use this feature right now for esxi5 wouldn't care about that limitation anyway.
The primary advantage is the ability to do everything through httpd. This gives you the ability to bypass the layer 2 restriction of DHCP without having to resort to tricks like Cisco's ip-helper. This isn't the only advantage - gpxe lets you boot remotely over a LOT of different medium (AoE, iscsi, etc.). The newer versions of kvm/libvirt have built-in gpxe support for their virtual NIC drivers, so chain loading for a KVM guest isn't even required.
Thanks... that makes sense.
Seems like we *would* always be using httpd, though, in our case?. So I guess, to userland, the advantage is "it's faster and probably can boot more nodes at once". This follows.
I guess what I'm curious about is *IF* it will work on all legacy hardware, do we still need the old path around as a default? i.e. maybe normal PXE becomes the weird fallback option? Or does that not make sense?
Maybe there's not a good reason though, and we suspect gpxe will not work everywhere? Not sure what is offered in terms of boot menus, etc. Keeping those available would be important if we tried to do that.
(I'm also a bit curious why VMware ESX won't boot from pxelinux.0, but that's just for my info and unrelated)
- ks_mirror_name = string.join(distro.kernel.split('/')[-2:-1],'')
862
FYI -- This seems to imply the distro must be mirrored by Cobbler. It seems like the code needs to anticipate this this possibility?
Yes and no - there's no reason the http server in question has to be cobbler. Covering that case would be a todo, but I didn't give it priority since I believe the number of people who use the --available-as option are relatively small. I'm pretty sure that option doesn't work with esxi4 either (since at least 6 files need to be copied to the tftp directory), so I figured the people who'd use this feature right now for esxi5 wouldn't care about that limitation
IIRC, --available-as isan option to import.
I was thinking about the manual "cobbler distro add" case, where you might not even have a "tree" parameter at all, and the files might live on NFS somewhere.
I'd probably attempt to make sure the path *looked* like a cobbler path, and if not, maybe raise an error or something.
Maybe this is just the way I percieved it, but I basically view import as a shortcut path around distro add/profile add/etc, not the path you always have to go down.
Anyway, some way to yell at you if you're doing it wrong seemed to be my point.
if distro.kernel.find("ks_mirror") != -1: raise Exception("...")
or something like that
--Michael
On Sun, Nov 27, 2011 at 1:24 PM, Michael DeHaan michael.dehaan@gmail.com wrote:
The primary advantage is the ability to do everything through httpd. This gives you the ability to bypass the layer 2 restriction of DHCP without having to resort to tricks like Cisco's ip-helper. This isn't the only advantage - gpxe lets you boot remotely over a LOT of different medium (AoE, iscsi, etc.). The newer versions of kvm/libvirt have built-in gpxe support for their virtual NIC drivers, so chain loading for a KVM guest isn't even required.
Thanks... that makes sense.
Seems like we *would* always be using httpd, though, in our case?. So I guess, to userland, the advantage is "it's faster and probably can boot more nodes at once".
Not necessarily. Is there any reason we couldn't extend cobbler to manage iscsi exports or other methods?
This follows.
I guess what I'm curious about is *IF* it will work on all legacy hardware, do we still need the old path around as a default? i.e. maybe normal PXE becomes the weird fallback option? Or does that not make sense?
Maybe there's not a good reason though, and we suspect gpxe will not work everywhere? Not sure what is offered in terms of boot menus, etc. Keeping those available would be important if we tried to do that.
The issue here is the supported version of syslinux. Newer versions of pxelinux support httpd natively, however RHEL/CentOS 5 (and 4 of course) may not have access to those versions. This is a stop-gap for the next 3-5 years in which we will support those distros. At some point, we could revert back to a pure pxelinux implementation (or not, if we do end up supporting stuff like iscsi and AoE).
(I'm also a bit curious why VMware ESX won't boot from pxelinux.0, but that's just for my info and unrelated)
It does - the limitation as I noted in the original email is that you have to copy all of the ISO contents to the tftp directory. The ESXi5 install supports httpd through gpxe only. In order to get that to work with cobbler sync and the --boot-files option, some ugly hacks had to be made allowing for globs so that all files would be copied. That could become a management issue too, since for older distros /tftpboot is in the root file system and may not have a ton of space available.
- ks_mirror_name = string.join(distro.kernel.split('/')[-2:-1],'')
862
FYI -- This seems to imply the distro must be mirrored by Cobbler. It seems like the code needs to anticipate this this possibility?
Yes and no - there's no reason the http server in question has to be cobbler. Covering that case would be a todo, but I didn't give it priority since I believe the number of people who use the --available-as option are relatively small. I'm pretty sure that option doesn't work with esxi4 either (since at least 6 files need to be copied to the tftp directory), so I figured the people who'd use this feature right now for esxi5 wouldn't care about that limitation
IIRC, --available-as isan option to import.
I was thinking about the manual "cobbler distro add" case, where you might not even have a "tree" parameter at all, and the files might live on NFS somewhere.
I'd probably attempt to make sure the path *looked* like a cobbler path, and if not, maybe raise an error or something.
Maybe this is just the way I percieved it, but I basically view import as a shortcut path around distro add/profile add/etc, not the path you always have to go down.
Anyway, some way to yell at you if you're doing it wrong seemed to be my point.
if distro.kernel.find("ks_mirror") != -1: raise Exception("...")
or something like that
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Not necessarily. Is there any reason we couldn't extend cobbler to
manage iscsi exports or other methods?
Well, it could do *anything* the question is, what would be the (cobbler) method, hypotehtical or otherwise, to configure it to work that way -- and why would you really need to? It seems like serving everything httpd for starters *off* of the Cobbler server makes good sense.
The issue here is the supported version of syslinux. Newer versions of pxelinux support httpd natively, however RHEL/CentOS 5 (and 4 of course) may not have access to those versions. This is a stop-gap for the next 3-5 years in which we will support those distros. At some point, we could revert back to a pure pxelinux implementation (or not, if we do end up supporting stuff like iscsi and AoE).
I'd be ok with requiring folks setting up a cobbler to just go get a new one and hosting it like we did with "cobbler get-loaders", even as ugly as that was.
Older syslinuxes were a frequent cause of the hangs at the PXE boot menu anyway.
(I'm also a bit curious why VMware ESX won't boot from pxelinux.0, but that's just for my info and unrelated)
It does - the limitation as I noted in the original email is that you have to copy all of the ISO contents to the tftp directory. The ESXi5 install supports httpd through gpxe only. In order to get that to work with cobbler sync and the --boot-files option, some ugly hacks had to be made allowing for globs so that all files would be copied. That could become a management issue too, since for older distros /tftpboot is in the root file system and may not have a ton of space available.
So it doesn't really have a notion of an install tree like kickstart does? Yikes.
You could always hardlink /tftpboot somewhere else if you had to.
Would be nice to document all this here in terms of deploying the ESX boxes themselves:
https://github.com/cobbler/cobbler/wiki/VMware -- which mostly pertains to launching guests and I'm sure is somewhat out of date not marking the difference between workstation/fusion and server.
- ks_mirror_name = string.join(distro.kernel.split('/')[-2:-1],'')
862
FYI -- This seems to imply the distro must be mirrored by Cobbler. It seems like the code needs to anticipate this this possibility?
Yes and no - there's no reason the http server in question has to be cobbler. Covering that case would be a todo, but I didn't give it priority since I believe the number of people who use the --available-as option are relatively small. I'm pretty sure that option doesn't work with esxi4 either (since at least 6 files need to be copied to the tftp directory), so I figured the people who'd use this feature right now for esxi5 wouldn't care about that limitation
Maybe raise a warning then. Sounds like we need a seperate GPXE page on the Wiki or something. As long as it's documented what works and doesn't that should be fine.
IIRC, --available-as isan option to import.
I was thinking about the manual "cobbler distro add" case, where you might not even have a "tree" parameter at all, and the files might live on NFS somewhere.
I'd probably attempt to make sure the path *looked* like a cobbler path, and if not, maybe raise an error or something.
Maybe this is just the way I percieved it, but I basically view import as a shortcut path around distro add/profile add/etc, not the path you always have to go down.
Anyway, some way to yell at you if you're doing it wrong seemed to be my point.
if distro.kernel.find("ks_mirror") != -1: raise Exception("...")
or something like that
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Folks,
I have four servers with 16Gb RAM for which I had a manual PXE install environment in parallel with cobbler to handle the VMs. They used PXE to install
I have been trying these patches. After a bunch of configuration ESXi starts to install. Then I get an error
"fatal error: 10 (out of resources)"
Does gPXE limit memory in any way ? My only change was to switch from PXE to gPXE.
Thanks
John
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James Cammarata Sent: 27 November 2011 16:58 To: cobbler development list; cobbler mailing list Subject: [PATCH] support for gPXE and esxi5
Two patches, pushed to my github account:
https://github.com/jimi1283/cobbler/commits/esxi-improvements
The ESXI5 patch requires the gpxe patch, since the only sane way to add the support for it to cobbler was via the gpxe process documented in the VMware build guide. This allows all of the files to be served via httpd, otherwise you have to copy the entire ISO contents to a TFTP directory (which required some ugly hacking in cobbler).
The one caveat about the gpxe process is that you must manually copy the undionly.kpxe file to your tftp directory. Newer distros package the etherboot files, otherwise you'll have to download the files from http://etherboot.org/wiki/download and build the file yourself (it's a fairly painless process). Another TODO is to make the same setup changes for DNSMASQ, right now this only supports ISC DHCPD.
There is a new setting called enable_gpxe, which is used currently only when new items are created. There is also a new field for systems and profiles by the same name, which sets it on a per-object basis. This isn't being used for profiles yet, nor will it work on systems without an interface and MAC specified, but when enabled on a system with a MAC it will create an entry in dhcpd.conf that is configured to chain load the undionly.kpxe file. I plan on adding support for generic profiles and systems without a MAC, but it might be a some-what convoluted process and I'm trying to work out the best way to do it (currently it'd involve chain loading gpxe, and then detecting that you don't want to use gpxe and chain loading back into the old pxelinux.0 file).
I plan on merging these into master in the near future unless people have major issues during testing. Enjoy! _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Wed, Nov 30, 2011 at 3:47 PM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Folks,
I have four servers with 16Gb RAM for which I had a manual PXE install environment in parallel with cobbler to handle the VMs. They used PXE to install
I have been trying these patches. After a bunch of configuration ESXi starts to install. Then I get an error
"fatal error: 10 (out of resources)"
Does gPXE limit memory in any way ? My only change was to switch from PXE to gPXE.
Thanks
John
Weird, there is a single google result for that error message:
http://communities.vmware.com/thread/329291
I've gpxe'd on a VM with only 1GB, so I'm not sure what you're running into. Maybe a network card issue? Does it fail when loading the s.v00 file like in that forum post?
James,
It dies on tools.t00 which is a large file
192.168.1.121 - - [30/Nov/2011:15:11:02 -0600] "GET /cobbler/ks_mirror/ESXi50/scsi-qla.v01 HTTP/1.0" 200 78863 "-" "gPXE/1.0.1+" 192.168.1.121 - - [30/Nov/2011:15:11:02 -0600] "GET /cobbler/ks_mirror/ESXi50/uhci-usb.v00 HTTP/1.0" 200 19662 "-" "gPXE/1.0.1+" 192.168.1.121 - - [30/Nov/2011:21:11:02 +0000] "GET /cobbler/ks_mirror/ESXi50/tools.t00 HTTP/1.0" 200 154189383 "-" "gPXE/1.0.1+"
This is indeed a head scratcher. I have posted on the VMWARE ESXI 5 forum.
Thanks
John
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James Cammarata Sent: 30 November 2011 23:15 To: cobbler mailing list Cc: cobbler development list Subject: Re: [PATCH] support for gPXE and esxi5
On Wed, Nov 30, 2011 at 3:47 PM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Folks,
I have four servers with 16Gb RAM for which I had a manual PXE install environment in parallel with cobbler to handle the VMs. They used PXE to install
I have been trying these patches. After a bunch of configuration ESXi starts to install. Then I get an error
"fatal error: 10 (out of resources)"
Does gPXE limit memory in any way ? My only change was to switch from PXE to gPXE.
Thanks
John
Weird, there is a single google result for that error message:
http://communities.vmware.com/thread/329291
I've gpxe'd on a VM with only 1GB, so I'm not sure what you're running into. Maybe a network card issue? Does it fail when loading the s.v00 file like in that forum post? _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Hi,
If I manually install ESXi on my hardware and then create an ESXi VM inside (ESXi on ESXi), then try build from Cobbler with gPXE, it works !!!
So gPXE/ESXi 5 - OK So gPXE/ESXi 5 - Not OK So gPXE/ESXi 5/ESXi 5 - OK
So it must be some kind of hardware issue, some strange interaction between gPXE and ESXi on that hardware ?
Maybe I need to put this to the gPXE people ?
John
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James Cammarata Sent: 30 November 2011 23:15 To: cobbler mailing list Cc: cobbler development list Subject: Re: [PATCH] support for gPXE and esxi5
On Wed, Nov 30, 2011 at 3:47 PM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Folks,
I have four servers with 16Gb RAM for which I had a manual PXE install environment in parallel with cobbler to handle the VMs. They used PXE to install
I have been trying these patches. After a bunch of configuration ESXi starts to install. Then I get an error
"fatal error: 10 (out of resources)"
Does gPXE limit memory in any way ? My only change was to switch from PXE to gPXE.
Thanks
John
Weird, there is a single google result for that error message:
http://communities.vmware.com/thread/329291
I've gpxe'd on a VM with only 1GB, so I'm not sure what you're running into. Maybe a network card issue? Does it fail when loading the s.v00 file like in that forum post? _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Thu, Dec 1, 2011 at 5:47 AM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Hi,
If I manually install ESXi on my hardware and then create an ESXi VM inside (ESXi on ESXi), then try build from Cobbler with gPXE, it works !!!
So gPXE/ESXi 5 - OK So gPXE/ESXi 5 - Not OK So gPXE/ESXi 5/ESXi 5 - OK
So it must be some kind of hardware issue, some strange interaction between gPXE and ESXi on that hardware ?
Maybe I need to put this to the gPXE people ?
Is it an Intel NIC? I vaguely remember seeing a post somewhere about Intel cards allocating a huge amount of buffers, causing issues when booting on a kvm guest, however I can't seem to find it now.
Also, I'm not 100% clear on which situations are working for you and which ones aren't - #1 and #2 seem to be the same.
Sorry, My mistake,
PXE/ESXi 5 - OK gPXE/ESXi 5 - Not OK gPXE/ESXi 5/ESXi 5 - OK
It is an Intel card, Desktop Pro 1G.
I will start looking at some variations and try them out. There may be some different gPXE builds I can do. Maybe there is some UNDI variation.
Also an interesting comment from this blog
http://blog.markusbordihn.de/2009/04/gpxe-and-localboot.html
"Because pxelinux will unload from the memory before it load the chain.c32 it works without any problems and also the localboot has the full avalible memory"
I am wondering if gPXE somehow operates within it's own memory restricted environment.
Thanks
John
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James Cammarata Sent: 01 December 2011 13:10 To: cobbler mailing list Subject: Re: [PATCH] support for gPXE and esxi5
On Thu, Dec 1, 2011 at 5:47 AM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Hi,
If I manually install ESXi on my hardware and then create an ESXi VM inside (ESXi on ESXi), then try build from Cobbler with gPXE, it works !!!
So gPXE/ESXi 5 - OK So gPXE/ESXi 5 - Not OK So gPXE/ESXi 5/ESXi 5 - OK
So it must be some kind of hardware issue, some strange interaction between gPXE and ESXi on that hardware ?
Maybe I need to put this to the gPXE people ?
Is it an Intel NIC? I vaguely remember seeing a post somewhere about Intel cards allocating a huge amount of buffers, causing issues when booting on a kvm guest, however I can't seem to find it now.
Also, I'm not 100% clear on which situations are working for you and which ones aren't - #1 and #2 seem to be the same. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Hi,
Found it !
The following pxe images DO NOT cause the ESXi install to hang
-rw-r--r-- 1 root root 60928 Dec 2 01:38 menu.c32 -rw-r--r-- 1 root root 26828 Dec 2 01:39 pxelinux.0
The following pxe images cause the ESXi install to hang with fatal error: 10 (out of resources) at tools.t00
-rw-r--r-- 2 root root 39188 Apr 28 2009 menu.c32 -rw-r--r-- 2 root root 14716 Apr 28 2009 pxelinux.0
No idea as yet which versions each of these are. The first ones are most likely the most recent
[root@Config tftpboot]# rpm -qa | grep syslinux syslinux-4.02-4.el6.x86_64
The second one may be the one that comes with RHEL. Did I install cobbler before updating syslinux ?
Next question is why gPXE has the same problem.
I am using
-rw-r--r-- 1 root root 61361 Nov 30 09:33 undionly.kpxe
Maybe I need to try some different versions ?
Thanks
John
-----Original Message----- From: John Paget Bourke [mailto:john.bourke@mobileinternet.com] Sent: 01 December 2011 13:21 To: 'cobbler mailing list' Subject: RE: [PATCH] support for gPXE and esxi5
Sorry, My mistake,
PXE/ESXi 5 - OK gPXE/ESXi 5 - Not OK gPXE/ESXi 5/ESXi 5 - OK
It is an Intel card, Desktop Pro 1G.
I will start looking at some variations and try them out. There may be some different gPXE builds I can do. Maybe there is some UNDI variation.
Also an interesting comment from this blog
http://blog.markusbordihn.de/2009/04/gpxe-and-localboot.html
"Because pxelinux will unload from the memory before it load the chain.c32 it works without any problems and also the localboot has the full avalible memory"
I am wondering if gPXE somehow operates within it's own memory restricted environment.
Thanks
John
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James Cammarata Sent: 01 December 2011 13:10 To: cobbler mailing list Subject: Re: [PATCH] support for gPXE and esxi5
On Thu, Dec 1, 2011 at 5:47 AM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Hi,
If I manually install ESXi on my hardware and then create an ESXi VM inside (ESXi on ESXi), then try build from Cobbler with gPXE, it works !!!
So gPXE/ESXi 5 - OK So gPXE/ESXi 5 - Not OK So gPXE/ESXi 5/ESXi 5 - OK
So it must be some kind of hardware issue, some strange interaction between gPXE and ESXi on that hardware ?
Maybe I need to put this to the gPXE people ?
Is it an Intel NIC? I vaguely remember seeing a post somewhere about Intel cards allocating a huge amount of buffers, causing issues when booting on a kvm guest, however I can't seem to find it now.
Also, I'm not 100% clear on which situations are working for you and which ones aren't - #1 and #2 seem to be the same. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Thu, Dec 1, 2011 at 7:53 PM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Hi,
Found it !
The following pxe images DO NOT cause the ESXi install to hang
-rw-r--r-- 1 root root 60928 Dec 2 01:38 menu.c32 -rw-r--r-- 1 root root 26828 Dec 2 01:39 pxelinux.0
The following pxe images cause the ESXi install to hang with fatal error: 10 (out of resources) at tools.t00
-rw-r--r-- 2 root root 39188 Apr 28 2009 menu.c32 -rw-r--r-- 2 root root 14716 Apr 28 2009 pxelinux.0
No idea as yet which versions each of these are. The first ones are most likely the most recent
[root@Config tftpboot]# rpm -qa | grep syslinux syslinux-4.02-4.el6.x86_64
The second one may be the one that comes with RHEL. Did I install cobbler before updating syslinux ?
Next question is why gPXE has the same problem.
I am using
-rw-r--r-- 1 root root 61361 Nov 30 09:33 undionly.kpxe
Maybe I need to try some different versions ?
I'd make sure you have the most recent, pull from their github and test with that if you're installing a distro RPM that provides them. They source the NIC drivers from the kernel tree, so most likely there was a patched bug that fixed the issue you're having at some point in the past.
Hi,
Thank you very much on ESXi 5 support using gPXE. Is there a way to tweak the cobbler to support building custom ISO for non-pxe environment using "cobbler --buildiso" for ESXi 5 hosts?
Thanks, Selva -----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James Cammarata Sent: Thursday, December 01, 2011 9:20 PM To: cobbler mailing list Subject: Re: [PATCH] support for gPXE and esxi5
On Thu, Dec 1, 2011 at 7:53 PM, John Paget Bourke john.bourke@mobileinternet.com wrote:
Hi,
Found it !
The following pxe images DO NOT cause the ESXi install to hang
-rw-r--r-- 1 root root 60928 Dec 2 01:38 menu.c32 -rw-r--r-- 1 root root 26828 Dec 2 01:39 pxelinux.0
The following pxe images cause the ESXi install to hang with fatal error: 10 (out of resources) at tools.t00
-rw-r--r-- 2 root root 39188 Apr 28 2009 menu.c32 -rw-r--r-- 2 root root 14716 Apr 28 2009 pxelinux.0
No idea as yet which versions each of these are. The first ones are most likely the most recent
[root@Config tftpboot]# rpm -qa | grep syslinux syslinux-4.02-4.el6.x86_64
The second one may be the one that comes with RHEL. Did I install cobbler before updating syslinux ?
Next question is why gPXE has the same problem.
I am using
-rw-r--r-- 1 root root 61361 Nov 30 09:33 undionly.kpxe
Maybe I need to try some different versions ?
I'd make sure you have the most recent, pull from their github and test with that if you're installing a distro RPM that provides them. They source the NIC drivers from the kernel tree, so most likely there was a patched bug that fixed the issue you're having at some point in the past. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
cobbler@lists.fedorahosted.org