@PITSKing said in New FOG install, now can't find old image files in FOG:

I’m assuming that means I need to create the new Image inside the FOG web ui?

Yes.

@vanopy Will you do this for us? On your golden (source system). Schedule a capture/deploy again, but before you schedule the task, check the debug checkbox. Then pxe boot the computer. After a few enter key presses you should be dropped to a linux (FOS) command prompt. At the FOS command prompt key in lsblk and post the results here. Do the same on this target computer that is giving this disk size issue. Post both results here so we can see the disk geometry.

@chadman00 While I don’t like to jump right into capturing network traffic, I think its going to be the easiest way to understand if you have the filters setup right with dhcp.

place a target computer on the same subnet as your fog server and dhcp server for the best picture of what is going on then follow this tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Take that pcap and look at it with wireshark. Looks at the OFFER response from your dhcp server. Make sure the boot file name is correct. If you are lost looking at the pcap upload it to a google drive and share it as public and post the link here and one of us will look at it to see if your dhcp server is responding correctly.

@Chris-Whiteley said in Issue with the "Deploy Image" option:

item Windows101809b - Windows 10 1809 (208)
item -Windows101809-Office2013 - Windows 10 1809 - Office 2013 (209)

I suspect these. Remove the dashes from the image names and see what happens.

More precisely its probably this image name :-Windows101809-Office2013

@MepH It sounds like you listened to bad advice when you setup your FOG server. You should never use the linux user fog for system administration. That account is owned by the FOG application and maintains control of it. Please use (create) another user account for system administration.

Sebastian is spot on with telling you how to fix this. I also have a tutorial on this issue because it happens quite often. There are several how-to-install FOG instructions that tell users to create the fog account and then install FOG using it. That is bad advice.

https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Are you really running Centos 6? If so what version of php are you using php -v from the fog server’s linux prompt? Both of these may contribute to the slowness using version 1.5.x of FOG. In 1.5.x FOG moved the usage of the php engine out of apache and into a dedicated php engine called php-fpm. This was for performance reasons.

Now lets talk about the VM and its VM Host. How many physical cores does the VM Host server have? I see you have 8 allocated to the FOG VM. IMO that maybe too many depending on what your VM Host looks like.

@JRyanCon Well you need to understand the postinstall script runs from/on the FOS engine (the customized linux that runs on the target computer). So when you reference /tmp or in your case ~/testfile, that file is created on FOS which executes only from memory. So when FOS exits the virtual hard drive is disposed of as well as your test file.

What you really want to do is create a test file on the target computer so you can be sure the script runs. If you look at this tutorial:
https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Specifically the fog.custominstall script. You will see that this script connects FOS to the target computer’s windows partition using the linux mount command. Within FOS the windows partition is mounted on a directory called /ntfs. So if you wanted to write a test file to the drive you would mount the drive partition and then touch /ntfs/testfile

You would place that touch command inside this section of the script.

        echo "Done"
        debugPause
        #. ${postdownpath}fog.copydrivers
        # >> insert the touch command here <<
        # . ${postdownpath}fog.updateunattend
        umount /ntfs
        ;;

@nsmer Ok since you have a dell and I noticed the disk controller is in Raid-On mode, will you look in the bios settings? Look for a setting that says disk controller. There are typically 2 or 3 modes (On Dell Latitude models) One is AHCI and the other is Raid-On. If you see this setting change the disk mode to ahci mode for testing. See if both clonezilla and FOG see the disk then. There is a known problem with the target computer being in uefi mode with Raid-On and linux.

@Sebastian I need to look into something I found over the weekend. I installed Linux Mint 19.1 on a test Dell computer that was in uefi mode and had raid-on mode configured. LM 19 installed correctly and ran. There was some strangeness with the network adapter so I reloaded LM in bios mode. But then it hit me, why was LM working in uefi mode…?? I need to find out if the linux kernel developers addressed the Intel Raid controller issue in Raid-On mode.

What version of FOG going to what version of FOG?

Is the function broken on the export or import side?

@Critchleyb I can’t say for sure. Probably yes since you are even on a RC release.

I was going to recommend a database way to exporting the table, but then I remembered about table dependencies.

So in stead I would recommend that you bring your old FOG server up to 1.5.5. Realize it will function differently than 1.5.0rc2. But the goal is to get the export to work correctly.

1. Export your Image definitions first
2. Migrate the images raw files (/images) to your new FOG server
3. Import your images.csv into your new fog server
4. Export your hosts definitions from the old fog server.
5. Import the host definitions into your new FOG server.

If you can’t upgrade your old fog server for some reason then can you show us what is doing to the csv file to make it unusable?

@ckasdf OK what I would recommend is for you to disable pxe booting on your router and install dnsmasq on your fog server. Your router is and always will be pointing to itself as the next server. Dnsmasq will only supply the pxe boot information to your target computers, your router will continue to manage your IP addresses in this configuration.

https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server
If you use my configuration file (ltsp.conf) exactly and replace every instance of <fog_server_IP> with your fog server’s IP address you will be up and running in about 10 minutes (the greater and less than signs must be removed too). The nice thing about dnsmasq running on your fog server is if you shutdown the fog server, dnsmasq is also disabled so then no pxe boot will happen. When fog is running and dnsmasq is running you will have pxe boot capabilities.

@ckasdf That is correct, remove dhcp options 66 and 67 since your router will not behave correctly. Then setup dnsmasq on your fog server. Once dnsmasq is running then you should be able to pxe boot right away. Actually dnsmasq will override dhcp option 66 and 67, but its best to remove them so you don’t forget about them later.

@aborn said in Updating database Failed Error returned: <!DOCTYPE HTML PUBLIC .... 503 Service unavailable ....:

I am not using SELinux .

FWIW on centos selinux is enabled by default. Be sure its set to permissive mode.

The updating database error is typically related to someone changing the linux user fog’s password so that its different than what the FOG webui has been setup for. Just as a double check run through this tutorial to ensure that the password hadn’t been tweaked. https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Also if you connect to the fog server over FTP using the user id of fog and the password found in the /opt/fog/.fogsettings file, then we can rule out the common problems.

I assume you can still access the fog webui when it throws that error?

First check selinux status, then ensure that the linux user fog’s password is set correctly, and then come back for the next steps.

Well I see you have 2 issues here. One we can fix and the other will take some effort on your part.

The easy one: The FOG images have 2 parts. Of course you already know about the raw data files. These files exist in /images on your fog server. Within the /images directory the files are in directories typically based on the image name. The other part is the metadata that describes the image files. That information is stored in the sql database. Its possible if you have a consistent naming convention for you to rebuild the metadata by hand. For example, I have an image name of Win101803ProU. I know the directory path of that image because FOG defaults the image path to be the same as the name. I also know its a windows 10 image, uefi. From there I can fill out the remainder of the data fields based on knowing its a full disk image (single disk resizable) and what compression level and data compressor to use (these last to are only important when capturing the image). So if you know the location and parameters for your image you can manually create the image definition in the FOG Web ui.

The harder one: The image files are not directly compatible between Clonezilla and FOG. FOG creates and stores fog specific disk geometry files when it captures image. It helps FOG when setting up the target disk before the image push. Clonezilla doesn’t create these files that fog needs. Clonezilla and FOG do use the same image capture tool (Partclone) but where they differ is the image compression methods. Meaning: The raw image files are compatible but not really usable.

While it sounds like a lot of work, IMO its quick to use clonezilla to deploy an image to a test client, then turn around and capture it right away with fog (without letting the target OS boot), than it would be to convert these blob image files between Clonezilla and FOG disk formats.

@Guillaume-IT said in [CentOS 7 - FOG 1.5.5] Boot PXE:

1 interface: management / web server
172.17.10.85
-1 interface: DHCP / client that resets a station.
192.168.0.1

OK no problem. What you did “wrong” is when you installed fog you might not have told FOG which interface you wanted as the imaging interface. We see your configuration in situations where there is a dedicated imaging network and then a management network/internet access route.

So how to fix…

If you run this command ip addr show from the fog server’s linux command prompt. Note which interface is associated with which IP address. Write these down because you will need to know the imaging network interface name in the next step.

Edit the hidden configuration file /opt/fog/.fogsettings. Update the interface in there to match the imaging network interface name.

Then go into the Web UI and goto Fog Configuration->Fog Settings then click on the expand all button. Search the web page for the incorrect interface name and then replace the value with the proper interface name. I know there is at least one instance on that page, there may be two, I don’t remember off the top of my head.

Now go back to the linux command prompt and rerun the FOG installer from the downloaded git repository. Just pick all of the defaults since it will load all of your settings you picked last time from the .fogsettings file.

Once the installation is complete confirm that the IP address listed in /tftpboot/default.ipxe is pointing to the correct interface IP address, if not fix it now.

That should clean up what happened. Its not a big deal, but you need to be aware of which interface name is your imaging network interface when you install FOG and not just pick the default. Just be aware that you can only image on the defined interface. You can’t image with FOG on both interfaces, that part isn’t going to work.

@Sebastian-Roth said in Struggling to get multi-casting to work.:

I guess dev is not the right name for a network device in Linux.

Oooooo good eyes and catch.

@lister Will you post the output of this command ip addr show?

@russel0901 Well lets dig a little deeper into what the pxe booting client is being told. Please follow the instructions here to create a network capture of the pxe booting process. This tcpdump command will only collect pxe booting traffic. Please run the commands and then upload the pcap to a file sharing site (google drive, one drive, etc.) and post the link here or IM myself or Sebastian the link so we can take a look at what the pxe booting client is being told.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@kafluke I’m pretty sure its not FOG that is the bottle neck here, but more your virtualization infrastructure you have in place. Remember a virtualization environment is shared, where a physical server is typically dedicated to the service.

Tell use about the virtualization host.
How many cores (not hyperthreads, but real cores)
How much memory
How is the disk subsystem designed (raid level + number of disks)
How does the host interface with the network infrastructure? (1GbE, 1GbEx2, 10GbE, ?)
How many other VMs run on this vm host?
How many vCPUs do you have dedicated to the FOG server?
How much ram do you have dedicated to the FOG server?

I can tell you that FOG running as a VM with 2 vCPU 3GB of ram on a 28 core server ,with a Raid 10 array, and (2) 10GbE interfaces to the network. I can push a unicast image out to current tech desktop at 13.4 GB/min (according to Partclone)

There is a couple of things that could be the problem/solution.

First, while its not a problem here, ensure that secure boot is disabled

In regards to raid.
In fog configuration -> fog settings click on the expand all button. Search for kernel args and add in mdraid=true. Save the settings.

What this does it tells FOS linux to enable the raid management drivers in the kernel. If you are using the built in, intel rapid store raid you will need this kernel arg enabled. The intel raid, is a hardware assisted software raid. To linux it will present both the physical drives as well as the logical array. Since you are not seeing the nvme disks, this is probably not your current issue but there is no harm to have this feature enabled.

What I want you to do next is manually register this 3420 and schedule a capture or a deploy (doesn’t matter) but before you schedule the task tick the debug check box then schedule the task. Next power up the target computer but hit F12 a couple of times as soon as you see the dell logo, we want the boot menu to appear so we can do the next test. When the boot menu appears select from the bios menu (not uefi) network boot (if no bios boot options go into the firmware settings and enable legacy roms then reboot). We want to pxe boot the target computer in bios (legacy) mode. There is a known issue with Dell computers with the disk controller set to Raid-On and uefi mode. By booting in bios (legacy) mode we will be able to bypass this known issue.

When booting in debug mode you should see several screens of text that can be cleared by pressing the enter key. After pressing enter a few times you will be dropped to a linux command prompt. At the linux command prompt I want you to key in
lsblk and post the results here. This will show us the disks (block devices) that linux sees in this computer. You can either key in what you see here or take a clear picture of the output of that command with a mobile phone and post it here.

Once we know what we see in bios mode we can guide you to the next steps.

FWIW I imaged a Dell Precision 3630 last week (with sata drives) with the disks in a raid configuration and I had to switch to bios mode for imaging but the windows image and final firmware settings are uefi. Meaning you can image a uefi computer just fine in bios (legacy) mode even if the final operating mode is uefi.