Optiplex390 rebooting loop, can't do NIC as first boot option

[Chuckc1981]

There seems to be an issue after the fog menu where it does not boot the hard disk correctly.

At the moment I can’t set the NIC as the first boot device because it won’t get to windows. Setting the disk as the first boot works but I need to have the nic first for fog!

Any suggestions?

[afmrick]

I’m sorry if I am misunderstanding your post but, you set the boot device and order in the BIOS not from windows.

[Robert Erbes]

What kind of PC are you using ChuckC1981?

[Chuckc1981]

It’s a dell optiplex 390 small form factor. I’ve never had this issue before, in fact my SFF optiplex 380s are working just fine.

I’m thinking it might have something to do with outside processes not having access to the drive. When I boot up a ubuntu usb drive on this system I can’t even see the disk file system.

I can still image these PCs but I just can’t have the network card set as the first boot option (which will be a little problem since the remote branch where they will be located is an hour away and I’d like to have automated imaging out there :)).

If I do set the network card to boot first, the fog menu displays, but then it won’t boot the hard drive and just reboots the computer instead. Hope I’m explaining that well enough…lol.

Any ideas?

[Chuckc1981]

After reading another recent thread this sounds like an issue fixed by chainloading…

Agree?

Sorry if this is a duplicate post but I’m not sure they’re the same.

[Matthew Carter]

The nic doesnt have to be first. On a dell be at the machine ir have the user there and hit f12 and select nic as boot device. Ensure you also have the latest bios.

[Chuckc1981]

That’s what this thread is about though. I would like them to boot to the nic as the first option for remote administration purposes.

I found this from another post, not sure if it’s what I need yet though,
[url]http://www.fogproject.org/wiki/index.php?title=Boot_looping_and_Chainloading[/url]

[Chuckc1981]

A modification to /tftpboot/pxelinux/default looks like what I may need. However like previously stated I’m not sure fog is even seeing the hard drive.

LABEL fog.local
localboot 0
MENU DEFAULT
MENU LABEL Boot from hard disk
TEXT HELP
Boot from the local hard drive
If you are unsure, select this option.
ENDTEXT

I wonder if localboot 0 is not working with this systems drives configuration? Hmmmm…

[BryceZ]

Chuckc1981, you are correct, chainloading is the workaround. Some Dell models have a BIOS issue that doesn’t allow them to recognize localboot 0, which causes the boot loop.

[Chuckc1981]

It worked. Yay!

Took a little playing with to get the files copied correctly, linux file permissions aren’t my strong suit.

P.S. I used pxelinux.0, chain.c32, and vesamenu.c32 all from syslinux 4.05 in case anyone else runs into this.

I have no idea what syslinux even is but it fixed my problem, so it can have my first born.

[ChuckC]

Update on this,

If you modify your pxe boot menu passwords after doing this, it will overwrite /tftpboot/pxelinux.cfg/default which breaks the chainloading.

To fix it just replace

LABEL fog.local
[COLOR=#339966]localboot 0[/COLOR]
MENU DEFAULT
MENU LABEL Boot from hard disk
TEXT HELP
Boot from the local hard drive
If you are unsure, select this option.
ENDTEXT

with

LABEL fog.local
[COLOR=#339966]kernel chain.c32[/COLOR]
[COLOR=#339966]append hd0[/COLOR]
MENU DEFAULT
MENU LABEL Boot from hard disk
TEXT HELP
Boot from the local hard drive
If you are unsure, select this option.
ENDTEXT

In /tftpboot/pxelinux.cfg/default
To re-fix it.