Posts made by george1421

FWIW: You can get older FOG Project created kernels from this URL: https://fogproject.org/kernels/

@scorbin First, that method will work it will provide the same results. From a fog server standpoint, only master nodes in storage groups can capture images. The “intent” of storage nodes are deploy only. But as you can see if you know what you are doing you can tweak the design a bit.

As for an article for how to by hand install FOG. There really isn’t one. What you have setup is what the lawyers call an “unsupported configuration”. That’s not saying it won’t work perfectly, it is just not what the developers had envisioned. There is quite a bit of magic that goes on in the script to support the 6-8 different distributions. You can cut out quite a bit if you are only dealing with one OS. If you wanted to automate the install a bit, there is a hidden file in /opt/fog called .fogsettings If someone was to tweak (prepopulate) that file and then adjust the installer script a little, you could make an unattended install.

@scorbin right it just needs to be there to create the server self signed certificates.

@scorbin What you will do is, once you get your storage node setup, then you will go into the storage group where your master fog server is and your new storage node. Then untick the master node check box for your vm fog server, and then tick the master node check box for your storage node vm.

In this configuration your vm will become the supervisory node with all image capture and deploys going through your storage node. As I said once you get the traditional roles setup, we can then work on flipping them.

@scorbin Fair enough on your use case. FOG can work in this configuration.

If you run the fog installer on your Debian server, expect that it will load vsftp, apache, fog application pages, php, nfs and tftp. Expect the fog server to step on all configuration files related to these services. If your existing file server doesn’t use anything but nfs, then just backing up your exports (and/or using the installer flag that Wayne mentioned) then knitting the config file afterwards should be OK. Fog does have a requirement to have the firewall off as well as selinx set to permissive.

Once all that is set you can use your fog server as the manager to your storage node. Actually you will want to flip the roles a bit. But first step is to get the debian server to act as a storage node.

@scorbin Just to be clear, you want a storage node right? Not a full FOG server?

If you want a storage node, you can by hand create a storage node. Or run the fog installer and then realign the bits. For a storage node, mysql is not installed.

What is installed is NFS, ftp, tftp (if you want pxe booting from storage node).

But before we go down this rabbit hole too much, what is the reason for wanting to use this file server as a storage node?

What operating system is your existing file server?

The pseudo code that Tom discussed is almost realized in this excerpt from a script to locate the windows partition.

#!/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

More specifically you should focus on this section where it tests to see if the Windows directory exists on the partition. Just finish it up with the remainder of the logic that Tom posted.

                    if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
                        echo "Not found"
                        umount /ntfs >/dev/null 2>&1
                        continue
                    fi

Here is a similar thread that discusses the same issue and the commands needed to disable it: https://forums.fogproject.org/post/102522

Review the posts by @THEMCV they are enlightening. This issue does come up quite often. Most specifically this post:

Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off

manage-bde -status

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

@wayne-workman said in Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task:

That’d be the responsible thing to do on Microsoft’s part.

[snark on] But why, there is no profit in that. Fixing linux does not push their crappy windows 10 agenda at all. [snark off]

@dahrell Sorry I’ve been looking at other issues.

I was able to get a generic USB ethernet adapter to work once FOS was booted. But that won’t help you since it will have another mac address. Using a down level kernel might work, you can assign that kernel to that specific bit of hardware via the host configuration page. I was just looking but I can’t seem to find old FOS kernels in the 4.10 era. I know they exist, I just can’t locate them at the moment. Plus there is no guaranty that they will include the driver for this bit-o-dock. The right solution is for the linux kernel developers to fix the code to support these things.

For you to use a third party network adapter to pxe boot, you may find no joy there either. The UEFI firmware has to have the drive built in to support pxe booting. I don’t suspect that M$ will include any drivers in the uefi firmware other than their own hardware.

Lastly you could always usb boot into FOS using the FOS USB stick. Its not an ideal situation, but it would bypass pxe booting by booting FOS off the usb stick (as I did in my testing). Then all you need to have is a FOS supported usb ethernet adapter to image.

@george1421 Well after some IT hokus-pokus (it magic). I was able to extract this info from the FOS logs.

Mar 20 11:04:27 fogclient user.info kernel: usbcore: registered new interface driver r8152
Mar 20 11:04:29 fogclient user.info kernel: r8152 2-4.2:1.0 eth0: v1.09.9
Mar 20 11:04:38 fogclient user.info kernel: r8152 2-4.2:1.0 eth0: carrier on
Mar 20 11:04:39 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:42 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:45 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:49 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:52 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:55 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:04:59 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:05:02 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71
Mar 20 11:05:05 fogclient user.warn kernel: r8152 2-4.2:1.0 eth0: Tx status -71

Which correlates with this document: https://www.spinics.net/lists/netdev/msg463854.html So from the document it appears that something has changed in kernel 4.12 and newer. There was no joy in that thread because it appears to not have been answered.

Another thread I found:

Broke for me too on Ubuntu 16.04.3 LTS with new kernel 4.13. Still works with 4.10.

and

It works for me using Kernel 4.10, breaks in 4.13 RC6 and RC7

Lastly it appears to be still an ongoing issue:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1742922

Looks like the r8152 driver is working with the device that has the usb id: 0bda:0307, which is an usb 3.0 to ethernet adapter with three usb 3.0 ports on it.

The affected device where the driver is not working, has the usb id 045Ep:07C6d, which is in a docking station (2 x display port, 2 x usb 2.0, 2 x usb 3.0).

The MS Surface dock in my system is a 045e:07c6 (not sure where the OP of the above thread got the extra characters from, but it appears to be the same unit).

@deric This image shows exactly what I speculated (guessed). You are missing the menu text since the description field is empty.

@deric said in Not seeing Centos ISO in menu:

item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
item os.Centos7-minimal-ISO
choose --default fog.local --timeout 3000 target && goto ${target}

The red line above is the issue. There is only one parameter field. There is the menu text that is missing. In your OP you say this is what you entered. (the screen shot of the actual menu item would be handy).

Menu Item: os.Centos7
Description: Centos 7 v1607 {or what ever version you are building}

But according to the iPXE menu content this is what I suspect you have.

Menu Item: os.Centos7-minimal-ISO
Description: <blank>

The nfs share, has nothing to do with the iPXE menu. So you can remove that from consideration at the moment. Now if the iPXE menu shows up but when you select the menu item something else happens… then that is another story.

I find it very strange, this menu entry does appear to be correct. Can you provide a screen shot of the actual menu item? Also if you could post the output of this command, replacing the IP address of the fog server in the correct spot: http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=10:00:00:00:00:00 You can do that from a browser, it will display the text behind the iPXE menu.

@dahrell OK here is what I did.

I have a surface book pro 2 with the external dock. I have a FOS USB stick so I can boot into FOS (linux OS that runs on the target computer) without needing to PXE boot. I used this route since you already established that pxe booting working into iPXE kernel, but the issue was with FOS.

I can duplicate the same issue as you have with my hardware. FOS sees the network adapter but can not init it. I plan on debugging this during my lunch hour after I can figure out how to make the fonts bigger on the screen. Right now I would say they are about 3-4 points in size. Now that I can duplicate the issue, lets see what I can find.

FWIW: I updated my FOS USB with the latest FOG kernel 4.15.2 and the inits for 1.5.0.

This one seems very challenging. The iPXE kernel has command of this network interface but FOS (customized linux kernel) does not.

It would be interesting to see when you booted into debug (capture or deploy) as you have. Setup wireshark with the following capture filter port 67 or port 68 then issue the udhcpc command. Is anything coming from FOS for dhcp? What happens of you issue a udhcpc -i eth0 Is anything sent from target computer?

If you manually configure an IP address to FOS can you ping devices on your network?

If you review /var/log and I think it syslog (or messages) and look for the network interface coming up, is there any error message?

In doing a quick google-fu search, I see this IS an issue that has been reported with udhcpc so I don’t think its localized to FOG. There has to be a clue here. I have a surface book for one of our ViPs sitting on the bench I can test today to see if I get the same results.

@pijltje said in All fog services turning off on hosts after reimage.:

In my case de services is running oke on the client.
The issue remain on the fog server, all the client settings are checked before imagine a computer and after imagine the computer (or again) all the client setting are unchecked. in the fog GUI “Client Settings”
If manually checked again after imaging, then the client will apply the client settings and reboot.
and everything is working oke.

@Developers This one is a bit strange, image deployment resets Host Management-><host>->Service Settings in FOG 1.5.0. Is this a new feature

@taspharel Just for clarity (since the OP is talking about a down level version). After imaging, in the setupcomplete.cmd file, you use the sc command to enable the fog client service, then you manually start the service. After a reboot the service is not restarting? Where exactly is it failing? I do remember reading a discussion about setting the service to delayed start instead of auto. I’m not sure that applies here. But the developers will need to understand exactly where its failing.

@fox134 Well lets hope you don’t have an ipxe.exe in there…

The client gets its booting information from (the) dhcp responsible for assigning an ip address to the target computer. So if you want the target computer to use a different boot file then you might update dhcp options 67.

Now with that said, from your OP you say that FOG is giving out the IP addresses on a dedicated imaging network. So if you want to change the boot file, you will need to edit the dhcp config file on your FOG server.

To see what you config file looks like, you can review this example: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

You will see for arch 7 and 9 it calls out ipxe.efi. You can replace that with maybe snponly.efi or any of the other efi files. Then you must restart your dns server. On ubuntu you would issue the command sudo systemctl restart isc-dhcp-server to restart the service.