Posts made by george1421

@geekyjm

ref: https://forums.fogproject.org/post/120405

@jape said in FOG unable to PXE boot beyond the VLAN/subnet that the server is on:

So perhaps that will complicate things

Yes it will. dhcp works off from broadcast messages, so it communicates by sending out broadcast messages on the same vlan/network. Having 2 dhcp servers on the same network segment will cause you grief.

Fog can integrate into an environment where there is an existing dhcp server no problem. FOG’s internal dhcp server would be typically used if you were to setup an isolated imaging network where there was no device except the pxe booting computer and the fog server.

So lets start out with this, what device is your preexisting dhcp server?

@jape Just to be clear you did not have a preexisting dhcp server on your site until fog was installed? Not even a router or other device that acted in place of a traditional dhcp server? its a bit strange (I feel) that you would have vlans/subnets without an existing dhcp server.

If this is true, no worries its pretty simple to get the remote subnets to work.

@geekyjm If I remember correctly the certificate is in /opt/fog/ssl ( I think ) but it is in /opt/fog directory or below. be sure to rename the original certificate on the new fog server before you copy over the old certificate. Once copied over reboot the fog server computer.

@geekyjm said in postdownload script:

Is there a new postdownload script I could download and try?

First let me say that post download scripts have nothing to do with Windows or connecting to AD. Your issues are probably not the root cause.

Lets assume you have the FOG client connect the target computer to AD (there are other ways to got about it, but most use the fog client) and you have just changed fog servers.

My bet is that the fog client can no longer talk to the new FOG server, and hence not get the instructions to connect to AD.

When the fog client is installed (like on the precaptured golden image), it tattoos itself to the fog server’s certificate. That certificate is unique to each install of FOG. My bet is that you didn’t copy over the certificate from the old fog server to the new fog server. So the clients are rejecting the new FOG server because the certificates don’t match.

@danibashkov Try single disk non-resizable. Lets see if you can get it past that error. I did find a reference from 2016 on the forum with the same error.

ref: https://forums.fogproject.org/topic/8602/cannot-upload-neverware-cloudready-chromeos-to-fog-e2fsck-failed-to-check-dev-sda20-shrinkpartition

@lacugo If you switch over to the FOG 1.5.9 dev branch (a.k.a FOG 1.5.9.115) it will install cleanly on Debian 11. But sadly not ubuntu 22.04 or centos 8 where php8 is the default install. AS of now FOG only supports PHP7.x until some code refactoring is done.

@rav ok here is the updated file: https://drive.google.com/file/d/1_pJWzun8R5v-PdMWk0j_l1dt8qEZzpjC/view?usp=sharing

What I did here is I see your fog server is at 192.168.5.234. In the config file I set the next server value to 192.168.5.234 The boot file is set dynamically by the config file. The dhcp range (what the isc dhcp server will hand out) is 192.168.5.10 to 192.168.5.200.

replace the existing config file with this one.

At the fog server’s command prompt (su to root to do this).

Issue these commands.
First to stop and then restart the isc-dhcp server (this will load in the new config file)
systemctl restart isc-dhcp-server

wait about 10 seconds

Now lets get the status of the dhcp server.
systemctl status isc-dhcp-server

Hopefully somewhere in the wall of text it will say running.

Now lets ensure that the dhcp server will startup at boot time.
systemctl enable isc-dhcp-server

@rav OK let me work on the file and get it back to you. The short answer is the network defined in the dhcp server is not the same as your fog server network interface.

@rav The config file you provided is for the dhcp client (app that runs on your computer that contacts the dhcp server). the file we are looking for is this: /etc/dhcp/dhcpd.conf

@rav said in Cannot get iPXE to connect to FOG Server:

Do I put “ip a s” at the end of the code?

Sorry I should have been more clear. On the fog server linux console run that command. It will list out the network adapters configured in your computer.

@rav How about you share your dhcp config with my using a file share site so I can look at the entire config. Also provide the output of this command ip a s and the subnet you need for this dhcp server. I think that will be the shortest path to done.

@jape said in FOG unable to PXE boot beyond the VLAN/subnet that the server is on:

The Fog server is a Ubuntu 18 system it is also the DHCPD server .I have not changed the option 66 or 67.

OK now we have a direction. So can you tell me why you are using the FOG server as a dhcp server? Do you have a campus dhcp server or is FOG on a dedicated imaging network.

The question is not as cheeky as it sounds. There are valid use cases for having FOG be the dhcp server, I just want to make sure you have one of those cases.

@wt_101 Well juggling three with running chainsaws doesn’t make it a bad idea, does it?

The 15 character limit is a windows NT thing. Since the majority of the folks that use fog for image deployment the developers have set it to 15 characters. If you have a use case where you need more than 15, I don’t see the harm in expanding it to more than 15 characters. That is the beauty of opensource. If it doesn’t work for you out of the box, if you have the skills you can change it.

You just need to be mindful if you have to interact with windows that the computer name might get truncated 15 characters when the computer name is set.

But also be aware that I don’t know of anyone who has tried to set computer names long that the MS defined standards either. Other things in FOG may break (thinking fog client if its hard coded at 15 characters).

@wt_101 This is really a question for the developers, but…

Looking into the code it looks like you can update the database schema to 50 and then change the web ui from 15 to 50 characters in here fog/lib/pages/hostmanagementpage.class.php search for maxlength="15"

I don’t see any other restrictions. There may be some qualifications when importing hosts via the web ui, but it looks like most of the code just takes hostname as it was entered.

As you are debugging this keep an eye on the php-fpm error log in /var/logs directory. If something unexpected happens in the UI, look there for the details on what happened.

@jape said in FOG unable to PXE boot beyond the VLAN/subnet that the server is on:

VMs we see the FOG client menu

I’m still battling terminology here. The FOG Client is an application that gets installed on a target computer. The FOG Client is responsible for contacting the fog server post deployment for scheduled tasks. That is different than the FOG iPXE menu which is what you get to via pxe booting.

So on both subnets what device is your dhcp server? You need to make sure the dhcp scopes for each vlan have dhcp options 66 and 67 set correctly. 66 should be the IP address of the fog server and dhcp option 67 should be undionly.kpxe for a bios computer and ipxe.efi or snp.efi for a uefi computer. FOG images correctly across subnets as long as the network packets are routable across your subnets.

@sourceminer said in Capture Image partclone fail.:

Suggestion: would it be a good idea to test these dirty flags prior to running the lengthy imaging process

I know there is a check for the dirty bit before imaging starts, but that might only be on the OS partition. Looking in the code I see a resetFlags function that actually runs the “ntfsfix -d” command. I’m not sure how its applied. I know if your drive contains the windows dirty bit the imager will stop before it starts deploying anything. So its not clear why it didn’t catch the issue on the 4th partition. But I do have to say its rare that the recovery partition would have been shut down uncleanly.

But in the end I’m glad you have it worked out.

@rrtern There are a few gaps in what you have said you have done so far.

Have you configured your dhcp server dhcp options 66 and 67 correctly?
Do you get to the FOG iPXE menu at all?

@sourceminer ref: https://medium.com/@mikeycpham/using-clonezilla-to-image-and-getting-the-error-ntfclone-ng-c-ntfs-volume-dev-sd-is-7a467b617c4d

Clonezilla also sees this error.

In your case you will want to pxe boot into fog instead of usb booting clonezilla.

edit:
ref: https://askubuntu.com/questions/112150/how-to-correctly-fix-a-dirty-ntfs-partition-without-using-chkdsk

ntfsfix -d /dev/sdb1

Clears the dirty flag.

@sourceminer Well… all of the probable issues seem to be a miss with this problem.

Ok lets do what partclone is telling us.

Schedule a debug capture if its still not in that state. Get to the FOS Linux command prompt on the target computer.

at the command prompt key in fsck -t ntfs /dev/sda4 Lets check the file system in linux. This is a command guess. If the fsck program completes without issue then issue fog to single step through the image capture.

I’m thinking there is something with that partition its not liking.