@t_dashs Right you can do that by typing in the IP address of your fog server. But the root of the problem is that you have at least 1 dhcp server not handing out the complete information. Understand this is an network infrastructure problem not specifically a FOG issue.

If you have a computer loaded with wireshark on the same subnet as the pxe booting computer we might be able to find out which one is wrong. You will want to use a wireshark capture filter of port 67 or port 68 Start the wireshark capture then pxe boot the target computer til you get this error. Stop wireshark from scanning. In the data area you will see a discover package sent from the target computer and one or more OFFER packets. The problem lies in one of these offer packets. Either the next-server or dhcp option 66 is not set on the offending dhcp server.

@nick So the next thing I would do is to update the firmware on the mobo just to be sure that isn’t it.

Then try the snponly.efi boot loader. You will need to update your dhcp server for this. The snponly.efi boot loader uses the driver built into the uefi nic. Its akin to undionly.kpxe for bios. The ipxe.efi boot loader is more like a linux kernel in that it has all of the common and known drivers built in, most but not all.

If that fails then here is how to build the latest version of iPXE. Note the build number on your current version of iPXE. Its the hex characters in the brackets after the version number. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

If this doesn’t work then we will need to get wireshark on a witness computer (second computer on the same subnet as the pxe booting computer). This is a bit more involved so lets start the easier stuff first.

@george1421 said in MySQL issues after new installation:

The default was changed in FOG 1.5.8 or 1.5.9 I think. But that would be only for a new install. The fog installer does not change the table configuration during an upgrade.

I might be wrong here but I don’t think it is yet. @Tom-Elliott ?

@sebastian-roth Correct

@pilar said in I can NOT access the website:

/dev/sda4 352G 19G 315G 6% /bkupFOG

Ok what is this partition?

Will you show me the output of this command
ls -la /bkupFOG

What I’m thinking is that we move the contents of /images to this partition then mount /dev/sda4 over the top of /images. That will give you space and keep from /images from filling up your file system. Don’t do anything yet, lets make sure we understand your current landscape on the server.

@george1421

I just tried another capture after changing the FOG client on the image to point to our FOG server in Germany. This time there was a normal 1 minute pause during the resizing process then Partclone G-zip started and imaged without problems. All seems normal again…gremlins have been eradicated. You can mark this as solved.

@chuck2000 We have see this before when you do an in place upgrade of windows, it seems to leave a shattered hard drive for some reason. Well done getting it worked out.

@cul3r0 In this topic the issue is very likely due to a custom CA and certificates. When FOG generates self signed certs for you it’s usually working out of the box if you don’t mess with it.

As every case is different I may ask you to open a fresh new topic on your own. Link to this one as reference but then more important give us your details, like FOG version, custom modifications and so on.

@george1421 said in User Tracking search not working:

little gear on original post

I see no gear or settings on the original post, leading me to believe this is a moderator-only feature. Thank you for marking the solution!

@sebastian-roth
yes thank’you. i found where i can create group and i put version of kernel, it’s perfect.
George give to me howto compiling kernel to fog, but I would like to have your method please 😉
Cheers

Just heard back from our Cali, Columbia office. All is well, device imaged fine with no errors. Thanks again for the awesome support!

@sebastian-roth Well there is some news. So today some others computer who worked before make the same bug, some i relaunch the fog installer. On this computer thats work i havent found the time to test with the first computers so i let you know. But i don’t understand why it work this time and it doesn’t last time.

Thanks for you help

@mechalas Please run ls -al /var/www /var/www/html and post output here. Mind the spaces in the command mentioned.

@sebastian-roth Correct, expect this time I am not importing the DB from my old fog server, new server, new images, new everything. I will open a new topic specific to the HP Probook 430 MAC Address Passthrough issues.

Thanks Sebastian for your help, I appreciate every you do for the FOG Community.

Mike

@Pilar Your upload of the picture didn’t go all the way to the end. If I had to guess I would think that you receive this kind of error: https://forums.fogproject.org/topic/13628/ftp-issue-when-pulling-an-image

Just follow George’s tutorial on how to fix this.

By the way: Here in the forums we try to keep issues separated to help other people follow and better understand it. So please don’t jump from one issue to the next in this one topic. Open a fresh new topic for each and every issue you have and we’ll answer every single one of them.

@george1421 said to @eliaspereira in Error on Start from hard disk (HD):

I see you change the exit mode to Grub. That will work too, but I’m surprised that grub works when SANBOOT didn’t

I find this a bit strange too but well you never know. Hardware can be a real pain and is doing weird things across the board. So I guess there is some hardware out that not able to chainload the OS via EXIT or SANBOOT but is happy with the GRUB method…

@Gameman @george1421 The wording (“bug”) kept me from looking at this for a while now. Found a bit of time to look into this and I think it’s not a bug really. When editing an image definition there is no drop down for “Storage Group” but a whole new settings tab for this (right of “General”). Here you all should be able to assign images to different storage groups as you wish.

Though I have to admit that it might be a bit of a challenge to find this. Not sure why it was designed like this in 1.5.x.

@maddyred You might want to take a look at this topic: https://forums.fogproject.org/topic/15848/api-creating-host

@maddyred Finally found some time to look into this. Not sure where you got some of data field names from. You better take a look at the code. Here you find the reference to the fields used for images: https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/fog/image.class.php#L35

Just below that your also find the defintion of databaseFieldsRequired (for images) - you need at least those four to be able to create an image defintion: name, path, imageTypeID, osID

Here is an example with some more fields that worked on my tests:

... data = { "name": "fogsvos", "description": "API created image", "path": "/images/fogsvos", "imageTypeID": 1, # Single Disk - Resizable "imagePartitionTypeID": 1, # Everything "osID": 50, # Linux "format": "5", # Partclone Zstd "protected": 0, "compress": 9, "isEnabled": 1, "toReplicate": 1, } ...

@hernani First I would recommend that you update your version of FOG. you are on 1.5.9RC2. I would at least go to 1.5.9 or even better once at 1.5.9 switch to the dev-branch and move up to 1.5.9.111.

If you use the git method to install FOG then just switch to the /root/fogproject directory and do a git pull command then switch to the bin directory and rerun the installer ./installfog.sh script again.

After that if you want to upgrade to the dev-branch you can issue these commands.

cd /root/fogproject git checkout dev-branch git pull cd bin ./installfog.sh

That might not take care of this issue, but at lest if you are on the latest release the devs can help you.

Typically when we see this problem at the end of capture with an ftp error message its because someone changed the fogproject linux user account or password. The memory exhaustion issue might be addressed in the update. I know I’ve seen this error before quite a while ago.