Dell bootloop chainloader problem
-
Do those machines have problems with the “localboot 0” option?
-
I am very new to all of this… the machines wouldn’t boot using the normal method Fog uses… that is why I started looking into this bootlooping/chainloader stuff. Does that answer the question?
-
Ah, sorry, I misunderstood. I thought it was only some of your workstations/servers that were failing to boot properly. Can you post your /tftpboot/pxelinux.cfg/default file? One other thing that comes to mind: what version of syslinux did you use to replace the files with? There were certain versions that had issues with chainloading.
-
I originally tried to use 5.x, but couldn’t figure out the needed files and resorted back to 4.05 since someone on a forum said that worked for them… I have since fallen back on 4.04 since that’s what some guides recommended… none seem to work for me.
Here’s my default file:
DEFAULT vesamenu.c32
MENU TITLE FOG Computer Cloning Solution
MENU BACKGROUND fog/bg.png
MENU MASTER PASSWD $1$0123456789
\n
menu color title1;36;44 #ffffffff #00000000 std
\n
LABEL fog.local
kernal chain.c32
append hd0
MENU DEFAULT
MENU LABEL Boot from hard disk
TEXT HELP
Boot from the local hard drive.
If you are unsure, select this option.
ENDTEXT
\n
LABEL fog.memtest
kernel fog/memtest/memtest
MENU LABEL Run Memtest86+
TEXT HELP
Run Memtest86+ on the client computer.
ENDTEXT
\n
LABEL fog.reg
kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.5.2 mode=autoreg web=10.10.5.88/fog/ loglevel=4
MENU LABEL Quick Host Registration and Inventory
TEXT HELP
Automatically register the client computer,
and perform a hardware inventory.
ENDTEXT
\n
LABEL fog.reginput
kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.5.2 mode=manreg web=10.10.5.88/fog/ loglevel=4
MENU LABEL Perform Full Host Registration and Inventory
TEXT HELP
Perform a full host registration on the client
computer, perform a hardware inventory, and
optionally image the host.
ENDTEXT
\n
LABEL fog.quickimage
MENU PASSWD $1$0123456789
kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.5.2 mode=quickimage keymap= web=10.10.5.88/fog/ loglevel=4
MENU LABEL Quick Image
TEXT HELP
This mode will allow you to image this host quickly with
it’s default assigned image.
ENDTEXT
\n
LABEL fog.sysinfo
kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.5.2 mode=sysinfo loglevel=4
MENU LABEL Client System Information
TEXT HELP
View basic client information such as MAC address
and FOG compatibility.
ENDTEXTLABEL fog.debug
MENU PASSWD $1$0123456789
kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.5.2 mode=onlydebug
MENU LABEL Debug Mode
TEXT HELP
Debug mode will load the boot image and load a prompt so
you can run any commands you wish.
ENDTEXT
\n
PROMPT 0
TIMEOUT 30\n -
OK, everything looks good there, so let’s check the BIOS.
In the BIOS, under Settings -> General -> Boot Sequence, is the Boot List Option set to Legacy? Also, under Settings -> System Configuration -> SATA Operation, is it set to AHCI? Not sure how those settings might affect chainloading, but they seem like they might play a role.
Another point to consider, these workstations/servers, are they using the onboard ports or are they configured in some sort of RAID?
-
I’m not sure about the boot list option - I don’t recall seeing anything called legacy. I’m sure they are AHCI and not RAID. The server is RAID, but the server also wasn’t even supposed to be on pxe boot.
-
At this point I’m not sure where the problem is. I have a couple hundred 790’s using the syslinux 4.04 files and the same fog.local option in the default file.
I would suggest backing up your /tftpboot directory and copying the original tftp directory from the installer in its place, and then walking through the steps in the wiki again using syslinux 4.04.
Sometimes the quickest fix is to just go back and do it again.
… And then I just had a thought; check the permissions on those files you replaced. I’m not sure how it would affect the boot process if it tried to call chain.c32 and found it couldn’t because of permissions, but that might be it.
-
I checked the permissions, even used chmod 777 to give everyone access to those files - still repeatedly counts down from 3 at the graphical menu. I copied the files from the installers tftp directory, but then the menu was the non-graphical version (?) and it still rebooted the system instead of booting off the hard drive.
So next, I got a totally different server, fresh install of everything, same results (reboots without syslinux patch, menu countdown never ends with syslinux patch)
I’m not sure what to do or try next… Any help is greatly appreciated.
-
OK, I just reread through your default file very closely…
Is the line:
kernal chain.c32
Or:
kernel chain.c32 -
Bryce, you just made my day. That was definitely the problem. YAY!!
Thanks for being my hero for the day!
-
I am astounded that I had this exact problem, and found this answer six months later.