@Wayne-Workman said:

That makes a lot of sense to me. Does the inits assume it’s re-sizable if those files are present?

While I am still not sure this was the issue I am pretty sure that things can go wrong if you simply change from resizable to non-resizable (plus use different size destination disks) without uploading again. But the inits do not assume resizable just because those files are there - they do the image type configured in the DB and just try to use the partition information available (d1.partitions in case of non-resizable) ignoring the other stuff.

As I said: It doesn’t have to cause trouble but it’s likely to.

@TomBagley Glad you figured it out. With what you described, I would not have guessed this.

@Quazz I had to change the hard drive as it wasn’t playing ball, but upon doing so even that one messed me around and failed to mount the partition. It updated the database and then removed the job from the list of active tasks. I removed the host from Fog and re-registered it, thus fixing the issue. I was able to upload the image successfully after that 🙂

Thanks for the help and suggestions!

Thanks to all of you, and so sorry, i did not notice the other post…

https://forums.fogproject.org/topic/7690/kernel-panic-on-quick-register/8

this one fixed it for me…

Yes, it was indeed the permission problem, all it working now as expected, thank you so very much

@oscar Seeing as your problem is a month old, my first suggestion is to update.

@Darrell-Lanson said in FOG 1.2 and PHP7:

Can’t wait to see 1.3

Install the trunk version lol

@Tom-Elliott Thanks a million! It works now.

So after all kinds of testing and complete confusion I finally figured out what was causing the issue with this. But not sure what happened to cause it. It was caused by my increasing the max size for snapins. I had a snapin the was approx 500mb so I changed the php settings in the old server to accept 3000m (3gb) and it seemed to work. But when I went to the new server and changed the settings to allow for it, it wouldn’t work. When I deleted that snapin completely from the server, everything started to work. Still not sure why when I would delete the snapin tasks from the host and deployed any other snapin it didn’t work. But everything seems to be running smoothly now that I don’t have any large snapins. I think I am going to go back to using scripts for large snapin tasks.

@maveriick Just ask?

I’m from the old school if it ain’t broke don’t touch it with that being said I cannot believe how long I have been using this close to 8 years now and I love it. Had 1 hard drive fail in that time but otherwise going strong.

@george1421 said in Uploading image breaks source machine, 7, Win10:

Just had an idea, what if the developers could put a command line switch in to install it but set the service to disabled.

Great idea, asking @joe-schmitt to read this.

The only devices I know of manufactured today that can’t network boot are Android and iOS devices. Pretty much everything else can.

@robza As I said in the other thread your issue is a very different one although the error message is pretty much the same.

Your partition layout is not one of these easy straight forward ones that we got pretty good at but a more advanced one. We fail(ed) to detect that sda2 needs to be fixed size in your case. Tom has added some new code to the inits to hopefully get some better detection. So can you please upgrade to the very latest version and do a fresh upload (maybe just create a new image definition so you don’t mess with your working one) and then try deploying again. The d1.fixed_size_partitions file should be correct this time. Please let us know if it is working for you with the latest FOG version or not.

Did you still need help?

@mccabem Upgrade to the latest version of the trunk. I’m using 7959 and it works fine.

I believe @Tom-Elliott fixed this issue in a 79xx version of the trunk.

@Wayne-Workman Hint received. Just figured since I have an identical issue that I’d keep it all within a single thread.

@Wayne-Workman That’s it. Thanks heaps for finding this! I thought I’d searched for \003 but obviously I didn’t - not properly at least.

You recommended to use undionly.kkpxe as the “quick fix”.

That’s not the whole truth I’m afraid! As it does not load a binary from the TFTP you need to use other methods like USB booting (rom-o-matic.eu, settings in the wiki but output format iso/usb). Or you could burn iPXE into the NIC ROM (haven’t done this myself yet so I cannot give any instructions). Why I did recommend undionly.kkpxe is because there is a known issue with a particular realtek NIC. As the OP didn’t let us know any machine or NIC details I am not sure if this is the same one. But I guess this is a very rare issue. So possibly it’e exactly the same NIC.

Please mark as solved…
It was a mismatch in user credentials for TFTP

@Wayne-Workman said in Failing to UPLOAD image to the FOG server:

@SteveB689 probably something along the lines of fixparts /dev/sda and then :w and :q but I could be remembering wrong. If your intention is to create documentation, just say run fixparts /dev/sda and follow on-screen instructions.

No probs… that’s what I typed ,…
this can be marked as SOLVED
🙂