@Tom-Elliott

After upgrading to RC-25 as you suggested, the issue is resolved. I can now image computers. Thank you and the other forum members for the help.

@Quazz said in Email notification format has changed, missing word wrap:

@x23piracy Looks this only happens with your Windows 10 1607 Office ProPlus image. Can you confirm?

edit: this could also be down to the mail client

Hi, yes i just need time to deploy other images, don’t want to do this for fun being busy here with other work but i am sure i need deploy other images in the next days, i get back…

@SharonLampe well this one is pretty interesting cause I’m seeing double vision on this one.

A quick diagram would be this.

Packets 31 to 35 are the same client saying hello I’m here world I need configuring. This is remarkable since this should only happen in one packet. Its the client sending out 4 dhcp discover requests rapid fire. I can see from this discover packet that this is a Dell computer that is running in bios mode. (so undionly.kpxe needs to be sent for dhcp option 67 {boot-file} and this is just a wild guess that is is one of the older dells (pre o7010). Packets 35 to 50 are replies from your dhcp server. This again is remarkable since there should only be one reply from your dhcp server. Looking at the time codes I can see these are in 3 groups of 4 responses each (which seems to align with the 4 packets send in step 1. looking at the dhcp server reply I can see that dhcp server 10.0.0.8 is replying to your client. And the address its replying with your IP address is 10.0.20.92 with a next server of 10.0.0.8 (your dhcp server!! which should be your FOG server if you want pxe booting to work). The subnet mask is 255.255.0.0 so both the dhcp server and the target computer are in the same subnet (this is good). Your upstream router is 10.0.0.1 (not really relevant). In that same conversation ID you have a second dhcp server 10.0.0.9 responding to the target computer with your IP address is 10.0.21.9 (not typically a good thing). Its telling the target computer that its next server (dhcp option 66) is itself 10.0.0.9 (still not good for pxe booting, this next server must be the FOG server).

OK from here I’ve seen enough to know why its not working.

Lets identify what servers are 10.0.0.8 and 10.0.0.9 are. Once that is figured out, we need to ensure they have dhcp options 66 {next-server} (should be your FOG server’s IP address) and dhcp options 67 {boot-file} (should be undionly.kpxe for bios based computers) values set. Right now they are not sending the client the proper information to boot via pxe.

And while this is only a suspicion I question why the target computer is ending out multiple dhcp discover requests. This is either because of a network misconfiguration, or something is not right with that target computer. There should be just one disover, with a reply from the dhcp server, then the target computer providing a full list of parameters its needs, and then finally the target computer responding with (OK got it). That should be 4 packets total to 30 ish packets.

@csa I need you to show me please. Screenshot, logs etc…?

See this post for more instructions/documentation:
https://forums.fogproject.org/topic/9001/partimage-for-old-images

Where is the MSI located in your setup?

Worked with @theWizard yesterday via remote session.

Found that the snapins were being uploaded to another storage node. That storage node /opt/fog/snapins folder had incorrect permissions on it.

Fixed the permissions and confirmed the working on working-RC-24. I’m solving this thread.

@Quazz
thanks

Worked with @noelpd via chat.

Apache had an issue with ssl that prevented it from restarting, and git had an issue with ssl preventing it from doing a git pull.

I directed him to use svn instead, and that worked. But there was still the issue with Apache, and @noelpd says that uninstalling and reinstalling apache fixed the issue.

I think there is something else going on related to ssl that caused these two issues to begin with.

I agree with you that it works wonderfully well with postdownloadscripts,
Thanks to the scripts provided by the forum community. Thanks to them.

But we must look for a bit before we find the existence of this functionality.

Many people will turn to OPSI because it is better indicated in the documentation and it is native in the application.

http://www.opsi.org/en

I always love Fog because it’s very light.

Thanks to the Fog team

Anybody familiar with code, and/or feel like testing:

Please take a look here:

https://github.com/FOGProject/fogproject/commit/5ead9f7a9dfd822aae06bb99de41769b87988ddb

Criticize and/or test the code that I’ve added to see if it help address the issue please?

@x23piracy said in Problem on HP ProBook 650g2:
Then have you got problem with computer with Realtek RTL8168D/8111D NIC (if you have some)
Thanks for your answer

Just a heads up. I tested upload with working-RC-24 and 1.3.0-RC-13 and am not seeing an issue.

I can only think, possibly, the disk is setup in ‘raid’ through the bios and it’s presenter still display’s /dev/sda to the system. Another potential, I suppose, could be the disk is completely empty? I’m only guessing of course.

The change I put in for maintaining ntfsresize is still working properly from what I can see. So it’s failing, from what I can tell, appropriately. Again, I’ll need more info to more suitably help I think. I mean, this could potentially happen because it’s fragmented and can’t move data around (testing) to find the size that can shrink to.

This post is solved

@mohamedadel No. Fog is an imaging solution. Nearly every imaging solution works the same way. It starts by wiping the disk (or disks), lays the drive out based on the image’s original partition layout, and lays the image on the partitions as laid out.

You can select specific partitions to use, though I haven’t ever done it the support has been added. Though I suspect you’ll have better luck doing them based on using the current Rc’s.

You can also change the image type to single disk - resizable, and then re-capture your image.

@EspenU As I posted before, if you have issues with the 64 bit kernel for some reason, just use the 32 bit kernel for all imaging needs. You can use this kernel universally for both 32 bit and 64 bit systems. There is no technical advantage of the 64 bit over the 32 bit kernel. Just renaming the global 64 bit kernel and inits values to point to the 32 bits stuff should be sufficient for all of your imaging needs.

@Dalton-Childers So this was a problem with the image.

@george1421
Would love to have that script. I am not giving up on this one. Will be at this first thing in the morning. Gotta go home and feed the kids.

Let me know how I can get that script you mentioned. I did check the default.ipxe and it was good to go.

V/R

@Tom-Elliott, @Wayne-Workman

Thanks for your help guys, great stuff. I was able to increase my disk size the way I want it too.

0_1479159136765_upload-ea588445-3e1c-4913-842a-09aebff13f1a

0_1479159145646_upload-2fd09ea2-6d4f-4ca7-b1ab-64e515b86943