Best posts made by george1421

It almost appears like you still have a database issue. The boot.php file is actually a php script that interacts with the database to detect the client and what boot file and tasks are waiting. The product of boot.php is a small text file.

You could test by using a browser and key in the url http://10.149.20.67/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 and watch the output.

You should also review the apache and php-fpm error logs in /var/logs directory for clues to why boot.php is not returning.

@tesparza for arch 6, you need to have i386/ipxe.efi for the boot file.

@tesparza for the purpose of these testing please stop the centos firewall with systemctl stop firewalld then use tcpdump command. We need to see packets that would normally be dropped by the firewall.

@Jose-Cacho said in Multicast data address not change from one task to another one:

With the change made by my workmate @Fernando-Gietz, regarding to the use of a multicast data address, we have improved the througput when there are serveral multicast tasks running at the same time. So you can mark this as solved (I don’t find how to do it).

@Developers we might want to consider @Fernando-Gietz patches for the next release of FOG.

@Zerpie To be able to capture with FOG you need to ensure the disk is closed correctly. With Win8+ shutdown is not really “shutdown”

Please use either sysprep to power off the computer before capture or use shutdown -f -s -t 0 to power off the computer and close all open files. If you use the shutdown command properly then you don’t need to worry about the hibernation files. This is not a FOG issue, but a Windows issue you will have with any disk (sector based) imaging solution.

@Fernando-Gietz How is your fog server running now that you did these updates. I still have it in the back of my head that we need to look into mysql performance number.

You have a moderately large FOG environment there. I’m wondering if you can collect some stats for me.

wget http://mysqltuner.com/mysqltuner.pl
chmod +x mysqltuner.pl 
./mysqltuner.pl

For the login credentials enter root and no password.

I’m interested in seeing what the recommendations are. You will get better results the longer mysql runs. If mysql (your fog server) hasn’t been rebooted in the last week then you should have very solid recommendations in the results.

@harryc1127 The compression format used by FOG is open source.

By default FOG uses gzip format for image compression. The FOG developers have added a new compression format that is much faster decompressing than gzip called ZSTD.

But in the end you will have a much quicker experience if you deploy your base image with FOG and then recapture with clonezilla (without letting the final target OS boot). The raw data files are one thing, but there is also the issue with the metadata files that are stored with the image information.

If you captured the source computers as single disk resizable, FOG will shrink the partition size on the reference image to the size of the data on the disk. Then FOG captures the image. If you take these compressed and shrunken disk image files, you can convert them to be used by Clonezilla but when you deploy them the partition sizes will be just a tad bigger than the data on the disk. Clonezilla won’t know how to expand the partition relative to the size of the disks. That is because that information is stored in the FOG meta data.

Its much quicker and easier to deploy with FOG and then turn right around and recapture with clonezilla. Depending on the size of your golden image and the speed of the target computer you are probably talking 15 minutes tops to deploy and then recapture with clonezilla.
But you can do it how ever you feel fits your situation. I’m only suggesting how I would go about it.

@Zerpie I’m thinking that md127 being set to inactive is also a clue. I just grabbed an old Opltiplex 780 and I’ll spin up a test workstation with the intel raid configured to see if I can duplicate the results here.

@george1421 Well this is what I see when I configured the 780 with 2 250GB disk setup in raid 0 move (stripped)

and for lsblk

I can say that I have a global kernel parameter of mdraid=true always set. When I watched FOS boot, I saw message about mdadm container assembled and then the container started. I haven’t tried to deploy to this system just yet because I need to edit the host configuration to include /dev/md126, but I’m pretty sure it will image like this. The raid array appears to be in good health.

[Edit] Yes I can affirm that it imaged correctly Windows OOBE is currently running on that system.

There is a couple of points here.

1. I’ve seen issues with some 32 bit tablets (the models escape me at the moment), in that they have a 64 bit processor, but the processor has been hardware locked in 32 bit mode. iPXE will detect its a 64 bit process (because it really is) and send the wrong iPXE kernel to the target computer. I have not check, but you might be able to bypass this auto detection by specifically calling out bzImage32 in the host configuration properties.
2. FOG doesn’t currently include refind 32 bit at part of the package. Only refind 64 bit is included. This will cause a problem when exiting from the iPXE menu in that the wrong refind kernel will try to boot and fail.

I can’t say that either of these are the specific case here, but I have seen issues before with 32 bit tablets.

@Technolust Ah, I see something…

The target computer is saying that its an EFI system (BC [type 7]), but your dhcp server is telling it to load undionly.kpxe. You should see some type of error on the target computer with NBF in the title. Basically you are sending a bios boot kernel to a uefi based system. Also make sure you have secure boot disabled on the target computer.

Fix the boot file name, the rest looks perfect.

@Sebastian-Roth Is this db information stored in the .fogsettings file? My thinking is that maybe it was changed/reset in the system before 1.5.4 was installed and the fog installer reset things to the way they were set according to the .fogsettings file(??)

@FrancoDin I don’t have this configuration setup any more, but from the error message tells me the fog bits are working correctly (even if FOG was not designed to do what you are doing). You are at the point of netbooting linux mint.

Did you remember to add the kernel argument line after the initrd line?
imgargs vmlinuz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/mint/18.1/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash

(also make sure your paths are correct)

What I’m doing in this configuration its loading the linux mint kernel and inital virtual drive using the tftp protocol then by using the kernel arguments (imgargs) I’m telling the kernel to get the rest of the files via the nfs protocol (hint: nfs base directory is /images) in the path provided. From your error message I would say that linux mint has started but can’t get the rest of the files over nfs.

@zpoling Is this on a ubuntu fog server?

If so, please review this: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@zpoling I’ve looked at your vlan 2 pcap and there is some strangeness going on there too. I see an offer and then a nak from dhcp server in the same transaction thread. Basically that is the dhcp server saying hey I have this to offer, (I’m not seeing the client side), then the dhcp server says nak (never mind I can’t help you).

A functional dhcp/netboot process is simple

(client) Discover
(dhcp server) Offer
(client) Request
(dhcp server) ACK
(client) -> tftp server what size is file xxxxx
tftp server -> (client) its yyy size
(client)-> tftp server give me file xxxxx
tftp server->(client) here's your first block

@jgiovann Well done on getting this rolling!

The reason why 2.76 is two fold before 2.76 you would need to append .0 to all of your boot files. 2.76 and later you can just call the boot files by name. Secondly 2.76 is the first version to truly support uefi booting.
Lastly I agree that some of the documentation is out of date and should be updated. The FOG Project is built on IT volunteers and the last thing IT folks like to do is documentation.

@Ared Bingo that’s the issue.

You will need to startup that reference image and check the disks for errors. Then when you are ready to capture shutdown the computer with this command (don’t use shutdown from the start menu)
shutdown -s -f -t 0 this command will ensure that windows is shutdown properly for image capture.

@Raymond-Bell said in TFTP Server:

It was that ATA… Sorry for all the trouble guys

That is why we are here to help. I’m glad you have it worked out. Something simple, but it caused you so much problems. On the plus side you are now on 1.5.5 with all of the fixes, so you are in a better place than when you started the day.

This sure resembles the issue where someone changes the linux user fog’s password, or they are using this linux user fog for system administration.

I do have a tutorial on how to resync the linux user fog so you can get past this step: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Understand this is for the linux user fog that is FOG’s service account not the webui default admin by the same name.

A fog “image” consists of 2 parts.

1. The raw image files stored in /images
2. The metadata stored in the mysql database.

You can copy all of the raw image files simply by the copy command. The metadata can easily be exported from the webgui into a csv file. With the raw data and metadata you can rebuid the images on a new fog server or whatever. If you don’t have the metadata but the raw image files you could rebuild the metadata if you are careful on how you name your images and are a good guesser for the rest. Point being, backup the image metadata with the raw data files and you will be good.