• After deploying the Imge Fog is booting into Fog menu

    Unsolved
    2
    0 Votes
    2 Posts
    313 Views
    Tom ElliottT

    @nikith-reddy Is your machine defined to boot to pxe first? This is normally expected.

    Is it never going to the OS? If so, you may need to check the boot options in the BIOS to see if it detects the hdd’s available OS’s.

    If it is going to the OS, then i’m not really seeing the issue. If you don’t want FOG PXE to boot at all, then you’ll have to adjust the BIOS to tell it to not boot to PXE/UEFI Network Stack.

  • PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...

    Unsolved
    6
    0 Votes
    6 Posts
    2k Views
    george1421G

    @RobertD said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

    We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

    Its great that you have a path to boot these system via the snp driver.

    You didn’t mention if you updated iPXE to the latest release to see if the ipxe.efi boot loader works once again.

    Let me (re)clarify in this thread the differences between ipxe.efi and the snpX.efi boot loaders.

    ipxe.efi (uefi) and ipxe.kpxe (bios) contain all of the known drivers built into the boot loader, this makes the iPXE boot loader much larger in file size (in 1990 terms of file size) because it has to carry all known drivers onboard the boot loader. For older systems > 6 years those were the preferred boot loaders for iPXE

    snp.efi, snponly.efi (uefi) and undionly.kpxe (bios) use the network adapters built in driver through the generic snp or undi interface. This boot loaders are much smaller than the ipxe.* versions since they only need to have one driver onboard (snp or undi). The undi driver (bios) has been around for 30 years and is the preferred and very stable network interface for bios computers and should always be the #1 choice. The uefi firmware has only been around for 12 years or so. The early version were very buggy so the snp driver did not work well. This is the reason why the fog developers recommended the ipxe.efi boot loader for uefi systems. In the last 6 years or so the snp and uefi firmware has matured to a level where the fog developers are recommending snp.efi or snponly.efi for all modern hardware. For bleeding edge hardware you have a better chance to get the snpX.efi bootloaders to work before the ipxe.efi bootloader, because the iPXE kernel developers will need to add the driver to the bootloader. Its just a timing issue.

    Now you might ask what is the difference between the snp.efi and snponly.efi drivers. snponly.efi will only initialize a network interface from where it was loaded from. For example lets say you pxe booting a compute with 4 nics, and you pxe bootin from nic2. The iPXE boot loader would only init nic2 using the snponly.efi bootloader. In contract snp.efi would try to init all nic intefaces starting with 1, 2, 3, and then 4. The issue becomes if nic1 takes the boot loader someplace else other than to the FOG server, since the fog server is on nic2.

  • FOG deployment problem (partition)

    Unsolved
    2
    0 Votes
    2 Posts
    266 Views
    george1421G

    @alexpolytech94 The shrinking of the disk when using single disk resizable is a bit of black magic. Sometimes because of the actual data size or location of the data on the disk its not possible to shrink the volume down enough to make it fit on a disk that is 1/2 the size of the source disk. I won’t go into too much detail, but if you have a partition that is fixed in size that can’t shrink, but a partition just before it on the disk that can shrink, fog will shrink the one that can be shrunk but leaves the one that can’t be shrunk as it were. If you were to deploy that image to a computer with half the size that non shrunk partition would be technically beyond the last sector on the 1/2 size disk.

    To put it another way, always build your mother image on the smallest disk possible, because it can expand to a larger target disk more often than shrink your image to fit on a smaller disk.

    When I was building golden images I would build them on a VM with a 50GB hard drive (smaller than anything I would deploy it to) and then let FOG expand the disk to match the target disk size. That always worked.

  • Blinking cursor at full host registration / compatibility mode

    Unsolved
    1
    0 Votes
    1 Posts
    201 Views
    No one has replied
  • Blinking Cursor at Full host registration & inventory / compatibility mode

    Unsolved
    1
    0 Votes
    1 Posts
    116 Views
    No one has replied
  • Acer 10th Gen - Deployment issues

    Unsolved
    2
    0 Votes
    2 Posts
    564 Views
    george1421G

    @zaboxmaster Well we are going to need your assistance to help debug this. I can give you the steps needed to collect the information to help debug this.

    Schedule a new deploy/capture task, but before you tick the schedule task button, tick the debug checkbox. Now schedule the task. PXE boot the target computer. After several screens of text you need to clear with the enter key, you will be dropped to the FOS Linux command prompt. This next 3 steps will help with remote debugging and for copying the results out to post here. Key in ip a s and collect the IP address of the target computer. Reset root’s password with passwd Give it a simple password such as hello This password will be reset at the next reboot. Now connect to the target computer using ssh, either ssh from linux or putty from a windows computer. Key in and post the results here of the following commands
    uname -a
    lsblk
    lspci -nn
    grep -i -e firm /var/log/syslog Keep the debugging session open for additional commands.
  • Formatting LDAP Server Connection

    Unsolved
    1
    1 Votes
    1 Posts
    423 Views
    No one has replied
  • Latitude 7340

    Unsolved
    1
    0 Votes
    1 Posts
    455 Views
    No one has replied
  • post-installation script

    Unsolved
    2
    0 Votes
    2 Posts
    250 Views
    george1421G

    @professorb24 I have a tutorial on how to do this with Dell computers, but the concept is almost the same for other vendors. The key is to have the driver files in inf format so pnputil.exe can install them. Lenovo use to have drivers in .exe format and not .inf format. That made things a bit harder when I was trying to setup lenovo computers.

    Looking at the script and it doesn’t appear to do anything. other than mount a wim image, but also be aware that the post install script runs withing a linux environment so it can’t directly interact with windows or the .wim file.

    Your post install script should copy the drivers over to the target computer after the image is placed on the target computer. All that FOG can do is leave files behind for windows to find them during OOBE/WinSetup.

  • Image capture stuck

    Unsolved
    5
    0 Votes
    5 Posts
    842 Views
    N

    Each time I try, I take care to erase all active tasks.

    I reinstalled smartInstaller on the master with the IP address of my FOG server rather than the FOG server name and now it works!

    Problem solved.

    Thanks for the reply 😉

  • Multiple TFTP Servers

    Unsolved
    5
    0 Votes
    5 Posts
    939 Views
    G

    @george1421 Using “tcpdump” we figured out that the DISCOVER packet was getting lost on its way to the DNSMASQ service. As you stated, we could reach HTTP/HTTPS between the remote location and here, so that wasn’t the problem.

    We got it working by installing a storage node, and installing DNSMASQ in a server that we located in the remote location’s switch. As my original post said, we got problems trying this solution, but after copying the “/tftpboot” folder with all the PXE binaries from our FOG server to the second server, it worked well because it succesfully reaches the boot.php file and the chainload error doesn’t appear.

    Your response has been incrediby useful, thank you very much for your support.

    Gorka.

  • 0 Votes
    5 Posts
    904 Views
    P

    @Tom-Elliott i’ve tried this fog.custominstall

    Create the following file named fog.custominstall in the following path on the FOG server /images/postdownloadscripts.
    Copy the content into that newly created file
    #!/bin/bash
    . /usr/share/fog/lib/funcs.sh
    [[ -z $postdownpath ]] && postdownpath=“/images/postdownloadscripts/”
    case $osid in
    5|6|7|9)
    clear
    [[ ! -d /ntfs ]] && mkdir -p /ntfs
    getHardDisk
    if [[ -z $hd ]]; then
    handleError “Could not find hdd to use”
    fi
    getPartitions $hd
    for part in $parts; do
    umount /ntfs >/dev/null 2>&1
    fsTypeSetting “$part”
    case $fstype in
    ntfs)
    dots “Testing partition $part”
    ntfs-3g -o force,rw $part /ntfs
    ntfsstatus=“$?”
    if [[ ! $ntfsstatus -eq 0 ]]; then
    echo “Skipped”
    continue
    fi
    if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
    echo “Not found”
    umount /ntfs >/dev/null 2>&1
    continue
    fi
    echo “Success”
    break
    ;;
    )
    echo " * Partition $part not NTFS filesystem"
    ;;
    esac
    done
    if [[ ! $ntfsstatus -eq 0 ]]; then
    echo “Failed”
    debugPause
    handleError "Failed to mount $part ($0)\n Args: $"
    fi
    echo “Done”
    debugPause
    . ${postdownpath}fog.copydrivers
    # . ${postdownpath}fog.updateunattend
    umount /ntfs
    ;;
    *)
    echo “Non-Windows Deployment”
    debugPause
    return
    ;;
    esac

    Save and exit your text editor.
    Make the script executable with chmod 755 /images/postdownloadscripts/fog.custominstall **this part i get chmod: cannot * chmod 755 ‘/images/postdownloadscripts/fog.custominstall’ :No such file or directory please help!!!
    fog.copydrivers

    Create the following file named fog.copydrivers in the following path on the FOG server /images/postdownloadscripts.
    Copy the content into that newly created file
    #!/bin/bash
    ceol=tput el;
    manu=dmidecode -s system-manufacturer;
    dots “Identifying hardware”
    case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
    machine=$(dmidecode -s system-version)
    ;;
    [Dd][Ee][Ll][Ll])
    machine=$(dmidecode -s system-product-name)
    ;;
    I[Nn][Tt][Ee][Ll])
    # For the Intel NUC and intel mobo pick up the system type from the
    # baseboard product name
    machine=$(dmidecode -s baseboard-product-name)
    ;;
    *)
    # Technically, we can remove the Dell entry above as it is the same as this [default]
    machine=$(dmidecode -s system-product-name)
    ;;
    esac

    if the machine isn’t identified then no need to continue with this script, just return to caller

    if [[ -z $machine ]]; then
    echo “Unable to identify the hardware for manufacturer ${manu}”;
    debugPause;
    return;
    fi
    echo “${machine} Identified”;

    Removes Spaces in machine name, works better with path definitions machine=“${machine%”${machine##*[![:space:]]}“}”; 14-Sep-23 Jeffrey Boulais posted that the above code did not work for his install. He supplied this code as an alternative. If you run in to a problem using my code comment out my code and see if his code works better for your installation. The only right way is the one that works. Thank you Jeff for your input. machine=“$(echo -e “${machine}” | tr -d ‘[:space:]’)” 03-Jan-24 marsface posted that he could not get either of the two above machine clean up commands to work correctly so he provided this one below which worked for him.

    machine=“${machine//[[:space:]]/}”

    dots “Verifying we’ve found the OS disk”
    if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
    echo “! OS root Not found !”;
    debugPause
    return;
    fi
    echo “Found”;

    dots “Verifying target Arch”
    system64=“/ntfs/Windows/SysWOW64/regedit.exe”
    [[ ! -f $system64 ]] && arch=“x86” || arch=“x64”
    echo “${arch} found”;

    debugPause

    set osn path names based on the osid set in the FOG WebGui

    case $osid in
    5) osn=“win7” ;;
    6) osn=“win8” ;;
    7) osn=“win8.1” ;;
    9) osn=“win10” ;;
    esac

    dots “Preparing Drivers”
    clientdriverpath=“/ntfs/Drivers”
    remotedriverpath=“/images/drivers/$machine/$osn/$arch”

    debugPause

    if [[ ! -d “${remotedriverpath}” ]]; then
    echo “failed”;
    echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
    debugPause;
    return;
    fi
    echo “Ready”;

    debugPause

    [[ ! -d $clientdriverpath ]] && mkdir -p “$clientdriverpath” >/dev/null 2>&1
    echo -n “In Progress”

    rsync -aqz “$remotedriverpath” “$clientdriverpath” >/dev/null 2>&1

    [[ ! $? -eq 0 ]] && handleError “Failed to download driver information for [$machine/$osn/$arch]”

    debugPause

  • Deployment Image Issues

    Unsolved
    1
    0 Votes
    1 Posts
    198 Views
    No one has replied
  • Associating a new Snapin, queues complete chain of previously associated snapins.

    Unsolved
    1
    0 Votes
    1 Posts
    280 Views
    No one has replied
  • inacessible boot device lenovo thinkbook laptop

    Unsolved
    2
    0 Votes
    2 Posts
    261 Views
    george1421G

    @professorb24 I can read your post a number of ways. Let me see if I understand the intent. Let me use my words to describe your issue as I understand it.

    You imaged a computer with the same image that works with an HP laptop onto a Lenovo. When you boot through the FOG iPXE menu on the HP, it exits correctly and the target computer boots as expected. But when I boot through the FOG iPXE menu with the Lenovo it fails to boot saying inaccessible boot device.

    If I understand the issue correctly, then if you changed the boot order on the lenovo so that it boots directly from the hard drive does it boot correctly? In my mind its not clear if it is an image issue (something wrong with the information on the disk) or is it an iPXE or refind issue.

  • Creating image - permission denied

    Unsolved
    8
    0 Votes
    8 Posts
    1k Views
    george1421G

    @plyons7890 The error message about an unclean file system is typically related to the source computer not being powered off correctly and files are still marked open.

    If the source computer is a ms windows computer I can understand this error. You must not use the standard “shutdown” command because it is not really a shutdown/power off command but more of an advanced sleep command, leaving files open.

    You can/should do the following

    Let sysprep power off the computer before cloning with FOG. Turn off fast startup in windows, this will switch shutdown into its traditional shutdown mode. Use the windows shutdown command shutdown -s -t 0 command to power off the computer before cloning.
  • unable to install fog client

    Unsolved
    1
    0 Votes
    1 Posts
    170 Views
    No one has replied
  • NBP is too big to fit in free base memory

    Unsolved
    4
    0 Votes
    4 Posts
    2k Views
    G

    @george1421 Okay, then to make it easier, I’ll just use UEFI boot to avoid any problems. Thanks!

  • Could not boot: HTTP 5xx Server Error

    Unsolved
    1
    0 Votes
    1 Posts
    310 Views
    No one has replied
  • PXEv4 couldn't find ip address

    Unsolved
    3
    0 Votes
    3 Posts
    401 Views
    Tom ElliottT

    @george1421 NBP is almost always the “label” of UEFI, but you’re describing PXEv4 MAC?

    Similarly, hte 0.0.0.0 seems to indicate that there’s no IP address on the machine in question. Maybe there’s no DHCP server.

    Without an image or more detail, we’re not sure how to help as @george1421 as suggested.

97

Online

12.2k

Users

17.4k

Topics

155.6k

Posts