@RobTitian16 That’s what I’ve done, yes. I discovered, by luck, that not appending anything to memdisk works for certain ISOs. I use Parted Magic frequently, so I was happy to get it working. I’ve never seen this documented anywhere…glad you’re working!

@Tom-Elliott

That resolved the issue. Thank you so much for the time. Please resolve this ticket.

Thank you
Chakri

@SteveB689 search the wiki for .fogsettings it explains each item.

Awesome help george 1421!!! That was my issue all along was that I was not using the /var/www/html/iso, but I was pointing directly to just /iso. It all makes sense now. Thanks for all the help!!! WinPE is successfully booting for me!!! Great work FOG and thank you for the advanced menu!!!

@Tom-Elliott After dropping and updating to latest git, I was able to register my computers. I’m now running into an issue pulling my first image, will start another thread for that. This one is solved!

Thanks Wayne really useful to know.

Regards,
Tom

@Quazz I can FTP into my fog server. I don’t think that is the issue. However, I rebooted the server and am trying the upload again.

Thanks for helping on this Tom.

After installing the latest trunk to a new VM and importing my db, I failed to realize that I need to update the credentials.
Thanks for all your help on narrowing this down.

@yusrijamal said:

EXT4-fs (ram0): couldn’t mount as ext3 due to feature incompatibilities

That’s because we use ext4 in the newer inits but FOG 1.2.0 does not pass a kernel option to tell it so. This is just a warning and does not harm anything!

sd 5:0:0:0 alua: Attach failed (-22)

Read through this. Guess this can be ignored as well.

sd 5:0:0:0 [sdb] No caching mode page found

The message is harmless I reckon but I still wonder why it says sdb (second hard drive)?!?

Please do as advised. Try newer kernel with old init files. If that does not work you can still look into properly upgrading to trunk version to be able to image that new hardware.

Great to hear that the new client fixed this! Just for further references: My guess is the old version of the client did send the VPN adapter MAC address or something like this.

@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?