Some questions about Create your own Configuration
40 views
Skip to first unread message
PaulFXH
Sep 7, 2009, 4:33:13 PM9/7/09
to netboot.me discussion
Thanks to your suggestion about overcoming gPXE's non-recognition of
my Ethernet card, I'm using Netboot.me on a EeePC 901.
I've been trying out the Create Configuration option but have not yet
succeeded in creating anything that works so perhaps you can help me
understand a little more:
1. I have 1 GB of RAM on the EeePC. How limiting is this? I was able
to get Debian (a full-sized OS) working off of Boot.Kernel.Org
although it performed very slowly which may have been because of lack
of memory.
2. Download rates for the configuration I've created continue to be in
the 8-18 kB/s range which makes experimentation difficult. However, I
created one for Puppy Linux (109 MB) which started downloading fine
but then errored out after 62 MB and complained about inability to
fetch the files it had either just downloaded (boot file) or was in
the process of doing (Puppy iso). The final error was a Grub error 22.
The errors sound like I lost network connection. Is this a
possibility?
3. I've also tried to create a configuration for Haiku (available as a
zipped raw image). However, this will not boot without being first
unzipped and then made bootable with the BFS "makebootable" utility.
Is there any way to apply scripting to the download in order to
prepare it for booting or is this too ambitious at this stage?
my Ethernet card, I'm using Netboot.me on a EeePC 901.
I've been trying out the Create Configuration option but have not yet
succeeded in creating anything that works so perhaps you can help me
understand a little more:
1. I have 1 GB of RAM on the EeePC. How limiting is this? I was able
to get Debian (a full-sized OS) working off of Boot.Kernel.Org
although it performed very slowly which may have been because of lack
of memory.
2. Download rates for the configuration I've created continue to be in
the 8-18 kB/s range which makes experimentation difficult. However, I
created one for Puppy Linux (109 MB) which started downloading fine
but then errored out after 62 MB and complained about inability to
fetch the files it had either just downloaded (boot file) or was in
the process of doing (Puppy iso). The final error was a Grub error 22.
The errors sound like I lost network connection. Is this a
possibility?
3. I've also tried to create a configuration for Haiku (available as a
zipped raw image). However, this will not boot without being first
unzipped and then made bootable with the BFS "makebootable" utility.
Is there any way to apply scripting to the download in order to
prepare it for booting or is this too ambitious at this stage?
Nick Johnson
Sep 7, 2009, 4:42:40 PM9/7/09
to netbootm...@googlegroups.com
Hi Paul,
This should be fine for most purposes.
Yes, that sounds likely. gPXE does seem to do this from time to time on larger images.
Unfortunately, no - gPXE doesn't support things like the zip format. You need to unzip it and store the parts (the kernel and initial ramdisk, or the iso) on an HTTP-accessible server.
-Nick
On Mon, Sep 7, 2009 at 9:33 PM, PaulFXH <paulfx...@gmail.com> wrote:
Thanks to your suggestion about overcoming gPXE's non-recognition of
my Ethernet card, I'm using Netboot.me on a EeePC 901.
I've been trying out the Create Configuration option but have not yet
succeeded in creating anything that works so perhaps you can help me
understand a little more:
1. I have 1 GB of RAM on the EeePC. How limiting is this? I was able
to get Debian (a full-sized OS) working off of Boot.Kernel.Org
although it performed very slowly which may have been because of lack
of memory.
This should be fine for most purposes.
2. Download rates for the configuration I've created continue to be in
the 8-18 kB/s range which makes experimentation difficult. However, I
created one for Puppy Linux (109 MB) which started downloading fine
but then errored out after 62 MB and complained about inability to
fetch the files it had either just downloaded (boot file) or was in
the process of doing (Puppy iso). The final error was a Grub error 22.
The errors sound like I lost network connection. Is this a
possibility?
Yes, that sounds likely. gPXE does seem to do this from time to time on larger images.
3. I've also tried to create a configuration for Haiku (available as a
zipped raw image). However, this will not boot without being first
unzipped and then made bootable with the BFS "makebootable" utility.
Is there any way to apply scripting to the download in order to
prepare it for booting or is this too ambitious at this stage?
Unfortunately, no - gPXE doesn't support things like the zip format. You need to unzip it and store the parts (the kernel and initial ramdisk, or the iso) on an HTTP-accessible server.
-Nick
PaulFXH
Sep 7, 2009, 5:08:00 PM9/7/09
to netboot.me discussion
Thanks for the reply.
The very low (8-18 kB/s) initial download rates I see with everything
I've tried in Netboot.me, including created configurations, is without
doubt the biggest drawback of this potentially marvelous facility.
Is this just the way it is or is there anything I can do to improve
it?
The very low (8-18 kB/s) initial download rates I see with everything
I've tried in Netboot.me, including created configurations, is without
doubt the biggest drawback of this potentially marvelous facility.
Is this just the way it is or is there anything I can do to improve
it?
Nick Johnson
Sep 7, 2009, 5:22:00 PM9/7/09
to netbootm...@googlegroups.com
On Mon, Sep 7, 2009 at 10:08 PM, PaulFXH <paulfx...@gmail.com> wrote:
Thanks for the reply.
The very low (8-18 kB/s) initial download rates I see with everything
I've tried in Netboot.me, including created configurations, is without
doubt the biggest drawback of this potentially marvelous facility.
Is this just the way it is or is there anything I can do to improve
it?
Can you confirm that this happens even for images loaded from static.netboot.me, such as Parted Magic? With those hosted on CloudFront, they ought to be as fast as it's possible to be. It seems like either your network driver or your connection has something that's seriously limiting the speed at which it downloads. The only real solution here - short of improving gPXE's network support - is to ensure the images are as small as possible so the initial download phase is as quick as possible.
-Nick
Thomas Miletich
Sep 7, 2009, 5:39:52 PM9/7/09
to netbootm...@googlegroups.com
On Mon, Sep 7, 2009 at 11:08 PM, PaulFXH<paulfx...@gmail.com> wrote:
>
> Thanks for the reply.
> The very low (8-18 kB/s) initial download rates I see with everything
> I've tried in Netboot.me, including created configurations, is without
> doubt the biggest drawback of this potentially marvelous facility.
> Is this just the way it is or is there anything I can do to improve
> it?
>
>
> Thanks for the reply.
> The very low (8-18 kB/s) initial download rates I see with everything
> I've tried in Netboot.me, including created configurations, is without
> doubt the biggest drawback of this potentially marvelous facility.
> Is this just the way it is or is there anything I can do to improve
> it?
>
I think the problem here is the gPXE TCP window size. The windows size
is 4096 byte by default. This means that 4096 byte will be transmitted
by the server before it will wait for an ACK of that data. The server
won't send anything before it receives the ACK. The higher the
latency, the higher the speed impact will be. This is why this is not
an issue in a LAN.
One could increase the window size in gpxe/src/include/gpxe/tcp.h.
Here a second problems comes up: gPXE will drop any packets that were
received out-of-order. If an out-of-order packet arrives the whole TCP
window needs to be retransmitted. This is not a big problem with a
window size of 4kb, however it is a problem if the window size was
increased to, say 64kb. A single corrupted packet(of max. 1500 byte),
or a packet that arrives out of order, will trigger the retransmission
of all data in that window(in the worst case the whole 64kb). The
retransmitted 64kb would have to be lucky enough to arrive in the
right order and without packet corruption, or the same thing will
happen again. In some setups this could prevent booting over the net
completely if <TCP-window-size> bytes don't arrive in-order after a
few tries.(which could be possible in unstable connections).
The proper fix would be to make gPXE capable of storing and using
out-of-order packets and implement an algorithm to adjust the TCP
window size automatically.
The available memory in gPXE is very limited and code size should be
kept small for .rom images, which are probably one of the reasons why
this hasn't been done yet.
I really hope that someone capable of doing this will take on this
task, but I don't know when or if this will happen. Patches to the
etherboot-developers mailing list are always welcome :)
Workarounds could be decreasing the latency. This is only possible to
a limited extent, as latency over the internet is always rather high.
Another workaround that could work is to keep the file(s) downloaded
by gPXE as small as possible. A more advanced TCP/IP stack, like the
one of linux could download the rest. I believe this is already done
by one of the HDD partitioning tools in the netboot.me menu, where a
small initrd is loaded and the rest is downloaded by the gPXE booted
linux kernel. Possibly this could be done for other boot options too,
a very small initrd could load the real, bigger initrd.
Thomas
Nick Johnson
Sep 7, 2009, 5:46:00 PM9/7/09
to netbootm...@googlegroups.com
On Mon, Sep 7, 2009 at 10:39 PM, Thomas Miletich <thomas....@gmail.com> wrote:
I think the problem here is the gPXE TCP window size. The windows size
On Mon, Sep 7, 2009 at 11:08 PM, PaulFXH<paulfx...@gmail.com> wrote:
>
> Thanks for the reply.
> The very low (8-18 kB/s) initial download rates I see with everything
> I've tried in Netboot.me, including created configurations, is without
> doubt the biggest drawback of this potentially marvelous facility.
> Is this just the way it is or is there anything I can do to improve
> it?
>
is 4096 byte by default. This means that 4096 byte will be transmitted
by the server before it will wait for an ACK of that data. The server
won't send anything before it receives the ACK. The higher the
latency, the higher the speed impact will be. This is why this is not
an issue in a LAN.
I'm well aware of that - but I was hoping that the substantially improved latency due to using CloudFront (a CDN) would offset this. Apparrently that's not enough in some cases, however.
One could increase the window size in gpxe/src/include/gpxe/tcp.h.
Here a second problems comes up: gPXE will drop any packets that were
received out-of-order. If an out-of-order packet arrives the whole TCP
window needs to be retransmitted. This is not a big problem with a
window size of 4kb, however it is a problem if the window size was
increased to, say 64kb. A single corrupted packet(of max. 1500 byte),
or a packet that arrives out of order, will trigger the retransmission
of all data in that window(in the worst case the whole 64kb). The
retransmitted 64kb would have to be lucky enough to arrive in the
right order and without packet corruption, or the same thing will
happen again. In some setups this could prevent booting over the net
completely if <TCP-window-size> bytes don't arrive in-order after a
few tries.(which could be possible in unstable connections).
I'd considered increasing the TCP window size - I wasn't aware that gPXE discards the window if it gets an out-of-order packet, though. Is it possible that this is part of what's causing the exceptionally low speed Paul is seeing - or the occasional failures?
The proper fix would be to make gPXE capable of storing and using
out-of-order packets and implement an algorithm to adjust the TCP
window size automatically.
Not trivial work, however. :/
The available memory in gPXE is very limited and code size should be
kept small for .rom images, which are probably one of the reasons why
this hasn't been done yet.
I really hope that someone capable of doing this will take on this
task, but I don't know when or if this will happen. Patches to the
etherboot-developers mailing list are always welcome :)
Workarounds could be decreasing the latency. This is only possible to
a limited extent, as latency over the internet is always rather high.
Another workaround that could work is to keep the file(s) downloaded
by gPXE as small as possible. A more advanced TCP/IP stack, like the
one of linux could download the rest. I believe this is already done
by one of the HDD partitioning tools in the netboot.me menu, where a
small initrd is loaded and the rest is downloaded by the gPXE booted
linux kernel. Possibly this could be done for other boot options too,
a very small initrd could load the real, bigger initrd.
Yup - it's done by GParted. Unfortunately, the initrd+kernel is still on the order of 10MB - and changing images to support this is a fairly manual process.
-Nick
Thomas
PaulFXH
Sep 7, 2009, 10:50:27 PM9/7/09
to netboot.me discussion
@Nick Johnson
Yes, I can confirm that the slow d/l speeds occur when I d/l through
static.netboot.me. Indeed, as you mentioned Parted Magic, I booted to
this and got 14 kB/s for the bzimage d/l and 12 kB/s for the
initramfs.
In Ubuntu on the same machine, I was able to download the initramfs
from static.netnoot.me at 85 kB/s using wget.
Just to remind you that the network driver in use here is not really
"my" driver but the "network driver left resident by the original PXE
bootloader" as you described it when suggesting the workaround to
overcome the non-recognition of the 901's Ethernet card by gPXE.
@Thomas Miletich
In your post, you suggest that "One could increase the window size in
gpxe/src/include/gpxe/tcp.h".
I'm very willing to try this but can't find how to do it. The commands
available from the gPXE prompt don't seem to offer any options for
changing directory nor for editing tcp.h (assuming this IS a file).
Any clues how I might proceed here?
On Sep 7, 6:46 pm, Nick Johnson <arach...@notdot.net> wrote:
> On Mon, Sep 7, 2009 at 10:39 PM, Thomas Miletich
> <thomas.milet...@gmail.com>wrote:
Yes, I can confirm that the slow d/l speeds occur when I d/l through
static.netboot.me. Indeed, as you mentioned Parted Magic, I booted to
this and got 14 kB/s for the bzimage d/l and 12 kB/s for the
initramfs.
In Ubuntu on the same machine, I was able to download the initramfs
from static.netnoot.me at 85 kB/s using wget.
Just to remind you that the network driver in use here is not really
"my" driver but the "network driver left resident by the original PXE
bootloader" as you described it when suggesting the workaround to
overcome the non-recognition of the 901's Ethernet card by gPXE.
@Thomas Miletich
In your post, you suggest that "One could increase the window size in
gpxe/src/include/gpxe/tcp.h".
I'm very willing to try this but can't find how to do it. The commands
available from the gPXE prompt don't seem to offer any options for
changing directory nor for editing tcp.h (assuming this IS a file).
Any clues how I might proceed here?
On Sep 7, 6:46 pm, Nick Johnson <arach...@notdot.net> wrote:
> On Mon, Sep 7, 2009 at 10:39 PM, Thomas Miletich
Thomas Miletich
Sep 8, 2009, 5:24:56 AM9/8/09
to netbootm...@googlegroups.com
On Tue, Sep 8, 2009 at 4:50 AM, PaulFXH<paulfx...@gmail.com> wrote:
>
> @Thomas Miletich
> In your post, you suggest that "One could increase the window size in
> gpxe/src/include/gpxe/tcp.h".
> I'm very willing to try this but can't find how to do it. The commands
> available from the gPXE prompt don't seem to offer any options for
> changing directory nor for editing tcp.h (assuming this IS a file).
> Any clues how I might proceed here?
>
>
> @Thomas Miletich
> In your post, you suggest that "One could increase the window size in
> gpxe/src/include/gpxe/tcp.h".
> I'm very willing to try this but can't find how to do it. The commands
> available from the gPXE prompt don't seem to offer any options for
> changing directory nor for editing tcp.h (assuming this IS a file).
> Any clues how I might proceed here?
>
This requires a source code change. If you have the gPXE source code,
open gpxe/src/include/gpxe/tcp.h. Find the line that says
#define TCP_MAX_WINDOW_SIZE 4096
It should be around line 290.
You can play around with the value, as long as you keep it below 65536.
I suggest using the gPXE source code from
http://github.com/Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0
as all the patches used for the netboot.me build should be included there.
You can build a netboot.me undionly.kpxe if you cd into the gpxe/src
directory and do:
make bin/undionly.kpxe EMBEDDED_SCRIPT=scripts/netbootme.gpxe
You have to rebuild gPXE after every change you do to the code, and
you have to copy the file 'bin/undionly.kpxe' to your tftp server
after every rebuild.
@Nick: please correct me if I'm wrong with the build instructions,
I've never build the netboot.me version of gPXE.
good luck!
Thomas
Nick Johnson
Sep 8, 2009, 5:50:52 AM9/8/09
to netbootm...@googlegroups.com
Quite correct. I'm now operating on a 'release branch' system, so everything you specified is correct. :)
-Nick
good luck!
Thomas
PaulFXH
Sep 8, 2009, 9:44:15 AM9/8/09
to netboot.me discussion
Thanks for the replies.
I went ahead and tried what Thomas suggested (as far as I could
understand) and did the following:
1. Downloaded Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88.tar.gz from here (http://
github.com/Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0)
2. Untarred with
tar -zxvf Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88.tar.gz
3. cd'ed to Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88
4. cd'ed to src/include/gpxe
5. Edited tcp.h to change the line suggested by Thomas to
#define TCP_MAX_WINDOW_SIZE 16384
6. cd'ed back to src (../..)
7. make
8. As far as I could see this went OK without error.
9. Now, I made a new bootable USB key with
cat bin/gpxe.usb > /dev/sdX
Now, I restarted the computer with the USB key inserted and it booted
fine but it brought me to a Netboot.me menu but (in the three times
that I tried this), the screen was frozen and I couldn't do anything
other than hit the power button to restart.
I did not do the "copy the file 'bin/undionly.kpxe' to your tftp
server" suggested by Thomas as, AFAIK, I don't operate a tftp server.
Would appreciate comments as this is not an area I'm very familiar
with.
On Sep 8, 6:50 am, Nick Johnson <arach...@notdot.net> wrote:
> On Tue, Sep 8, 2009 at 10:24 AM, Thomas Miletich
> <thomas.milet...@gmail.com>wrote:
I went ahead and tried what Thomas suggested (as far as I could
understand) and did the following:
1. Downloaded Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88.tar.gz from here (http://
github.com/Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0)
2. Untarred with
tar -zxvf Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88.tar.gz
3. cd'ed to Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88
4. cd'ed to src/include/gpxe
5. Edited tcp.h to change the line suggested by Thomas to
#define TCP_MAX_WINDOW_SIZE 16384
6. cd'ed back to src (../..)
7. make
8. As far as I could see this went OK without error.
9. Now, I made a new bootable USB key with
cat bin/gpxe.usb > /dev/sdX
Now, I restarted the computer with the USB key inserted and it booted
fine but it brought me to a Netboot.me menu but (in the three times
that I tried this), the screen was frozen and I couldn't do anything
other than hit the power button to restart.
I did not do the "copy the file 'bin/undionly.kpxe' to your tftp
server" suggested by Thomas as, AFAIK, I don't operate a tftp server.
Would appreciate comments as this is not an area I'm very familiar
with.
On Sep 8, 6:50 am, Nick Johnson <arach...@notdot.net> wrote:
> On Tue, Sep 8, 2009 at 10:24 AM, Thomas Miletich
Nick Johnson
Sep 9, 2009, 6:34:13 AM9/9/09
to netbootm...@googlegroups.com
Hi Paul,
On Tue, Sep 8, 2009 at 2:44 PM, PaulFXH <paulfx...@gmail.com> wrote:
Thanks for the replies.
I went ahead and tried what Thomas suggested (as far as I could
understand) and did the following:
1. Downloaded Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88.tar.gz from here (http://
github.com/Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0)
2. Untarred with
tar -zxvf Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88.tar.gz
3. cd'ed to Arachnid-netboot.me-gpxe-
d62256757b2c6fe01a626382a3bd2b6055769b88
4. cd'ed to src/include/gpxe
5. Edited tcp.h to change the line suggested by Thomas to
#define TCP_MAX_WINDOW_SIZE 16384
6. cd'ed back to src (../..)
7. make
Have you tried "make bin/gpxe.usb"? I'm not positive what targets just plain "make" will generate, so you could be using an out-of-date binary.
8. As far as I could see this went OK without error.
9. Now, I made a new bootable USB key with
cat bin/gpxe.usb > /dev/sdX
Now, I restarted the computer with the USB key inserted and it booted
fine but it brought me to a Netboot.me menu but (in the three times
that I tried this), the screen was frozen and I couldn't do anything
other than hit the power button to restart.
I did not do the "copy the file 'bin/undionly.kpxe' to your tftp
server" suggested by Thomas as, AFAIK, I don't operate a tftp server.
Would appreciate comments as this is not an area I'm very familiar
with.
Can you try building a version _without_ the change? That way we can tell if your build environment is capable of building a working binary at all.
-Nick
PaulFXH
Sep 9, 2009, 10:41:31 AM9/9/09
to netboot.me discussion
Hi Nick
Thank you for the comments.
I tried "make bin/gpxe.usb" but only within the directory from which I
had already built gpxe.usb using make. It immediately gave me a
message saying that gpxe.usb had already been updated.
(perhaps I should try this build command on a fresh source download).
Also, I tried to build gpxe.usb without the Max Window Size change in
the /src/include/gpxe/tcp.h file. However, the resulting gpxe.usb gave
exactly the same problem as the one I got when I did make this change.
So, maybe I do have a compile problem.
However, I have ALL of the packages mentioned here (http://github.com/
Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0 ) as required for
building:
- (a gcc tool chain (gcc 3.x or gcc 4.x)
- binutils
- perl
- syslinux
- mtools
Additionally, I have many times built stuff from Ubuntu on this
machine without any problems.
I'll provide here what's displayed on the screen when booting from the
usb-key that I made from netbootme.usb and that from gpxe.usb made as
described above. This may help diagnose the problem:
With the netbootme.usb USB key I see (after exiting from Intel PXE ROM
and seeing the first two lines of gPXE 0.9.7):
net0: 00:23:54:04:a2:6f on UNDI-PC104:00.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:0]
DHCP (net0 00:23:54:04:a2:6f).....ok
net0: 192.168.0.143/255.255.255.0 gw 192.168.0.1
No more network devices
Downloading http://www.netboot.me/menu.gpxe?pxe=gpxe-custom&ver=0.1:
Downloading menu.c32:
After this I'm given the option to wait for the Graphical menu to
appear or to hit any key to gain access to the Select Menu Type menu.
However, the equivalent output from the usb-key built from gpxe.usb
shows only the following after which it moves to the Select Menu Type
menu which remains frozen and unusable:
DHCP (net0 00:23:54:04:a2:6f).....ok
Downloading http://www.netboot.me/menu.gpxe: Downloading menu.c32:
44/55 kB
I hope this helps you indicate what I might be missing as I'm lost.
Thank you for the comments.
I tried "make bin/gpxe.usb" but only within the directory from which I
had already built gpxe.usb using make. It immediately gave me a
message saying that gpxe.usb had already been updated.
(perhaps I should try this build command on a fresh source download).
Also, I tried to build gpxe.usb without the Max Window Size change in
the /src/include/gpxe/tcp.h file. However, the resulting gpxe.usb gave
exactly the same problem as the one I got when I did make this change.
So, maybe I do have a compile problem.
However, I have ALL of the packages mentioned here (http://github.com/
Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0 ) as required for
building:
- (a gcc tool chain (gcc 3.x or gcc 4.x)
- binutils
- perl
- syslinux
- mtools
Additionally, I have many times built stuff from Ubuntu on this
machine without any problems.
I'll provide here what's displayed on the screen when booting from the
usb-key that I made from netbootme.usb and that from gpxe.usb made as
described above. This may help diagnose the problem:
With the netbootme.usb USB key I see (after exiting from Intel PXE ROM
and seeing the first two lines of gPXE 0.9.7):
net0: 00:23:54:04:a2:6f on UNDI-PC104:00.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:0]
DHCP (net0 00:23:54:04:a2:6f).....ok
net0: 192.168.0.143/255.255.255.0 gw 192.168.0.1
No more network devices
Downloading http://www.netboot.me/menu.gpxe?pxe=gpxe-custom&ver=0.1:
Downloading menu.c32:
After this I'm given the option to wait for the Graphical menu to
appear or to hit any key to gain access to the Select Menu Type menu.
However, the equivalent output from the usb-key built from gpxe.usb
shows only the following after which it moves to the Select Menu Type
menu which remains frozen and unusable:
DHCP (net0 00:23:54:04:a2:6f).....ok
Downloading http://www.netboot.me/menu.gpxe: Downloading menu.c32:
44/55 kB
I hope this helps you indicate what I might be missing as I'm lost.
dilib
Nov 3, 2009, 7:04:27 AM11/3/09
to netboot.me discussion
> I suggest using the gPXE source code fromhttp://github.com/Arachnid/netboot.me-gpxe/tree/netbootme-0.2.0
> as all the patches used for the netboot.me build should be included there.
> You can build a netboot.me undionly.kpxe if you cd into the gpxe/src
> directory and do:
>
> make bin/undionly.kpxe EMBEDDED_SCRIPT=scripts/netbootme.gpxe
I fetched the source from git and I can successfully compile the
> You can build a netboot.me undionly.kpxe if you cd into the gpxe/src
> directory and do:
>
> make bin/undionly.kpxe EMBEDDED_SCRIPT=scripts/netbootme.gpxe
images.
BUT: The scripts dir is missing. Where can I get the netbootme.gpxe
script for embedding?
Nick Johnson
Nov 3, 2009, 11:05:30 AM11/3/09
to netbootm...@googlegroups.com
Hi dilib,
If you got the source from my Git branch, the script is in contrib/src/netbootme.gpxe.
-Nick Johnson
dilib
Nov 4, 2009, 5:20:17 AM11/4/09
to netboot.me discussion
> If you got the source from my Git branch, the script is in
> contrib/src/netbootme.gpxe.
I went to the git webpage and just hit download. But that gets you the
zip of the master branch and not the 0.2.0 branch. Ahhhrg. My fault.
Regards
dilib
Reply all
Reply to author
Forward
0 new messages