@cjesso OK you have 2 issues here. One is a bug in 1.4.1 and the second we will focus on in a minute.
Posts made by george1421
-
RE: BOOTFILE?
-
RE: BOOTFILE?
@cjesso OK, I’m not so good with mind reading.
But since you have win10 installed, its probably a uefi system.
But based on what you just posted, it could be in bios mode. UEFI pxe bot should say something about a NBF file. Look in the “bios” and see if there is a software switch to change between bios (legacy) and uefi mode. Don’t change it only inspect the setting. Also if it IS in uefi mode, disable secure boot. FOG will not boot if secure boot is enabled.
As I posted before a screen shot of the error would really help.
-
RE: Imaging Jobs Freezing
If you use a second target computer do you get the same results?
We have see target computer with bad hard drives cause the imaging to fail.
Also if you get an error message on the target computer, please snap a clear picture of it with a mobile and post it here. The context of the error is almost as important as the error itself.
-
RE: BOOTFILE?
For dhcp option 66 should be the IP address of your fog server.
dhcp option 67 should be undionly.kpxe for bios (legacy) clients and ipxe.efi for uefi clients. For now pick one firmware format and load the right driver. Once you get comfortable with fog we can talk about other solutions to dynamically load the right iPXE kernel.And just for reference you SHALL NOT use pxelinux.0. We will know if you do.
-
RE: Upgrade from Trunk to 1.4.2 Failed
@Avaryan Now that you know your password attempt to log into your database from the linux command line
mysql -u root -p fog
then provide your database password. -
RE: How to get FOG to capture while host is logged in?
Its not possible to capture an image live like that. FOG uses a customized linux image that is deployed to the target computer over the network. You have to stop and properly close the image before it can be cloned. This is the same case for tools like clonezilla and to a lesser extent Symantec ghost. The target OS must be powered off.
-
RE: PXE Boot Problem - bzImage Connection Reset
@george1421 Next steps: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
But for you I want you to use this filter:
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 or port 80
capture the pcap file and upload it here. I want to find out exactly what the client is being told to do. I feel you have something in your business environment that is causing strange reactions from the client.
-
RE: PXE Boot Problem - bzImage Connection Reset
@george1421 Never mind we already did this down below in the thread.
-
RE: PXE Boot Problem - bzImage Connection Reset
@maciej12203 Sorry i read too many threads to remember where we are in each one.
I remember this now your FOG server is rejecting the http request.
two things come to mind
- Your http server is not running.
- You have your linux firewall still running.
- (I guess) someone forgot to switch selinux to permissive.
I would test from a windows browser see if you can connect to http://192.168.4.70/fog/service/ipxe/boot.php
I’m interested in if anything is returned. -
RE: Wrong current version after upgrade to 1.4.2
@Sequans said in Wrong current version after upgrade to 1.4.2:
You are not running the most current version of FOG!
Are you seeing this in the FOG configuration page?
-
RE: PXE Boot Problem - bzImage Connection Reset
@maciej12203 OK now we have something we can work with.
Since your have an existing dhcp server you do not want to run a FOG dhcp server because you will get conflicts.
If you can not modify the dhcp server configuration or request that the configuration can be changed we still have a way to make this work. On your fog server DO NOT enable the dhcp server, that will only cause you a head ache with the clients.
Since your FOG server and pxe booting clients are on the same subnet we will use dnsmasq to provide ProxyDHCP information for your location. The ProxyDHCP will supply the missing information that your main dhcp server can not provide. This ProxyDHCP server will supply the boot file and pxe booting server information to your clients.
Understand that running a ProxyDHCP server is a last choice option. The best solution is to get your dhcp server configured properly. I understand there are conditions where you can not do this, that is why FOG supports ProxyDHCP (dnsmasq) configurations.
-
RE: PXE Boot Problem - bzImage Connection Reset
@maciej12203 Lets take a step back here.
Does your network have an existing dhcp server?
If so are you allowed to make adjustments to this dhcp server?
Is your FOG server on a different subnet than your pxe booting client computers? -
RE: Windows 7 client reboot continuosly after task launched
@Avaryan said in Windows 7 client reboot continuosly after task launched:
Also, why FOG 1.3.5 if it’s a brand new installation?
There is also a bug in 1.3.5 that was addressed in 1.4.0RC1 that fixes single disk. Upgrading to the current release of FOG 1.4.2 is probably a good choice here. This may not address your issue. But once you are on the latest release we can discuss more specifics. If we need to get the developers involved they will require you to be on the latest release anyway.
What computer (mfg and model) are you trying to pxe boot that is stuck in this reboot loop?
-
RE: unable to deploy RAID 1 disk
@eistek Its hard to describe this, but the error means that the hardware can’t keep up with the CPU. Its like (not technically correct) the disk subsystem can’t keep up with the volume of data being written to the disks. Where you are getting buffer overruns in the disks. From researching this, the error happens more often when writing a lot of data to the local console and the console can’t keep up with the data stream.
-
RE: Copy images from dead 1.2.0 server to new 1.4.0 server
@Tom-Elliott said in Copy images from dead 1.2.0 server to new 1.4.0 server:
The “image size” service has been implemented for a while now
Well I wonder where I’ve been all this time Well done!!
-
RE: Copy images from dead 1.2.0 server to new 1.4.0 server
@ECRTechZ AFAIK There isn’t a solid way to tell. If the original file dates are before FOG 1.2.0 was released then its probably a PartImage format. If after 1.2.0 was released then maybe a partclone as the first test.
The developers may know by looking at the names of the files in each directory. But its probably going to be a long day testing to find just the right mix.
You may be able to move the database files to the new server and mount them with mysql. I’ve never done it this way, but it may be possible to get at the image data.
-
RE: Copy images from dead 1.2.0 server to new 1.4.0 server
@ECRTechZ Just be aware that the bit size and capture date is only populated at the time of image capture. If you migrate the files from another server this count and date will be nil. That is normal.
I think the developers were working on an agent to scan the image store and update the image size in the web gui. I’m not sure where that was in the development timeline. But for now if the byte count is zero for migrated images that is normal.
-
RE: Copy images from dead 1.2.0 server to new 1.4.0 server
@ECRTechZ How many images are you talking about?
Either way if you can’t access the database, exporting the image records will be not possible.
In regards to FOG and images, there are two parts. The raw disk images are stored in
/images/<image_name>
on the FOG server hard drive. The second bit is the image metadata stored in the database. You should be able to reconstruct the image name from the directory path on the old hard drive. If the customer was smart they would have embedded a bit about the image in the image name, i.e.Win7SP1OEM
. That would tell you what OS the image was in.The fields that are going to trip you up are Image Type and Image Manager
The image type defines how the image was captured. Raw, Single disk resizable, multiple disk resizable.
The image manager tell the FOS engine what image cloning tool to use. For images that came from 0.3x days then its PartImage. For the 1.2.0 it could be PartImage or more probably PartClone. You can disregard the zstd images because that is something new in 1.3.5 and later.
I see that you deployed FOG 1.4.0. The latest release is 1.4.2 and maybe worth the upgrade. If you had FOG 1.4.1 then I would say for sure upgrade. There was a bug in the new install version of 1.4.1 that caused a client check-in issue, that was resolved in 1.4.2.
FWIW, I think your client will be much better off with the setup you are proposing now than trying to resurrect FOG 1.2.0. The newer version of FOG are much faster and have more abilities than FOG 1.2.0 ever dreamed. Plus FOG 1.3.x and newer support Win10, GPT format, NVMe drives, UEFI firmware and much newer hardware than 1.2.0. Its a good move all the way around.