[ipxe-devel] Question Regarding ipxe/gpxe

[Matthew Hoey]

Apologies, should have mentioned I tried the "exit" command in my script
already. This particular server moves on to NIC1 (actually the whole thing
I'm trying to avoid.)

I think the next best solution is to use a tiny linux OS that will boot to
grub.

I'll go slightly more in depth with the problem in case this all sounds a
little weird.

Our machines image by looking for a script on our TFTP server. After we've
finished laying down an image on the disk we clear the script file and
reboot.

Normally at this point we should go through the boot process and not find
the script so we boot to disk. However, there are some problematic servers
with our BIOS settings incorrect which has them boot off of NIC1 and these
particular servers don't handle the lack of DHCP very well. It'd be great if
we should just alter the script to force it to boot straight to the hard
drive. I was hoping the kernel and initrd commands would have the ability to
call it's own hard drive, but I know that sort of defeats the purpose of
network booting.

On Wed, Mar 30, 2011 at 3:14 PM, Michael Brown <mbrown at fensystems.co.uk>wrote:

> On Wednesday 30 Mar 2011 22:47:29 Matthew Hoey wrote:
> > I apologize if this is posted in a wiki. I've googled and searched
> through
> > your wiki for about an hour and came up short.
> >
> > I know this is going to seem a little silly, but is there a way to use
> ipxe
> > (or preferably gpxe since I have yet to upgrade to ipxe,) to boot from
> the
> > local hard drive? I currently chainload an intel pxe into gpxe.
>
> If you chainload into iPXE, then exiting from iPXE should cause your
> machine
> to boot from the next device in the BIOS boot order (which you can set to
> be
> the local disk).
>
> You may need to use undionly.kkpxe rather than undionly.kpxe to work around
> a
> bug that affects some BIOSes.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20110330/befb97b9/attachment.htm>