10:58 a.m.
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!
12:35 p.m.
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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
1:03 p.m.
On Sun, Nov 27, 2011 at 12:35 PM, Michael DeHaan
<michael.dehaan(a)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.
1:24 p.m.
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
1:43 p.m.
On Sun, Nov 27, 2011 at 1:24 PM, Michael DeHaan
<michael.dehaan(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
2:41 p.m.
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(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
3:47 p.m.
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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
5:14 p.m.
On Wed, Nov 30, 2011 at 3:47 PM, John Paget Bourke
<john.bourke(a)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?
5:30 p.m.
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(a)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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
5:47 a.m.
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(a)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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
7:10 a.m.
On Thu, Dec 1, 2011 at 5:47 AM, John Paget Bourke
<john.bourke(a)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.
7:21 a.m.
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(a)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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
7:53 p.m.
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(a)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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
8:19 p.m.
On Thu, Dec 1, 2011 at 7:53 PM, John Paget Bourke
<john.bourke(a)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.
12:41 p.m.
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(a)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(a)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(a)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.
4531
days inactive
4536
days old
cobbler@lists.fedorahosted.org
14 comments
4 participants
participants (4)
-
Jaganathan, Selvakumar -
James Cammarata -
John Paget Bourke -
Michael DeHaan