Dell bootloop chainloader problem

  • I found this thread which talks about the Dell bootlooping chainloader situation:

    Which led me to the wiki telling how to change a few lines in the default file, overwrite a few files, and it should work…

    However, now my fog menu counts down from 3, then flashes and starts over again, repeatedly. I tried changing hd0 to hd1, but the problem still persists. Almost as if the machine’s HD isn’t taking the name hd0. (h d zero)

    The machine is a Dell Optiplex 790.

    Any thoughts or suggestions I can try to get this working? Thanks in advance!

  • I am astounded that I had this exact problem, and found this answer six months later.

  • Bryce, you just made my day. That was definitely the problem. YAY!!

    Thanks for being my hero for the day!

  • OK, I just reread through your default file very closely…

    Is the line:
    kernal chain.c32
    kernel chain.c32

  • 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.

  • 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’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. 😉

  • 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 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
    menu color title1;36;44 #ffffffff #00000000 std
    LABEL fog.local
    kernal chain.c32
    append hd0
    MENU LABEL Boot from hard disk
    Boot from the local hard drive.
    If you are unsure, select this option.
    LABEL fog.memtest
    kernel fog/memtest/memtest
    MENU LABEL Run Memtest86+
    Run Memtest86+ on the client computer.
    LABEL fog.reg
    kernel fog/kernel/bzImage
    append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= mode=autoreg web= loglevel=4
    MENU LABEL Quick Host Registration and Inventory
    Automatically register the client computer,
    and perform a hardware inventory.
    LABEL fog.reginput
    kernel fog/kernel/bzImage
    append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= mode=manreg web= loglevel=4
    MENU LABEL Perform Full Host Registration and Inventory
    Perform a full host registration on the client
    computer, perform a hardware inventory, and
    optionally image the host.
    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= mode=quickimage keymap= web= loglevel=4
    MENU LABEL Quick Image
    This mode will allow you to image this host quickly with
    it’s default assigned image.
    LABEL fog.sysinfo
    kernel fog/kernel/bzImage
    append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= mode=sysinfo loglevel=4
    MENU LABEL Client System Information
    View basic client information such as MAC address
    and FOG compatibility.

    LABEL 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= mode=onlydebug
    MENU LABEL Debug Mode
    Debug mode will load the boot image and load a prompt so
    you can run any commands you wish.
    PROMPT 0
    TIMEOUT 30\n

  • 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 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?

  • Do those machines have problems with the “localboot 0” option?

  • Yes they can boot just fine when bypassing pxe.

  • Hmmm, the only time I’ve seen this happen was when a machine didn’t have a bootable OS on the first drive, which caused the system to restart the boot process and continue looping. I’m going to guess that these workstations and server are able to boot if you cancel PXE booting, right?

  • bump - it’s more than just my dell workstations - apparently one of our Dell servers rebooted this past weekend and it was set to PXE boot first, which caught it in an endless fog startmenu loop as well. Perhaps I have missed something somewhere… any ideas anyone? Why do I get stuck in a 3 second countdown to infinity?