Nevermind. Found it (in my own post history no less…)

https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@george1421 it worked
finally it was a wrong placed host kernel that caused the trouble …
Thanks for the good help, we keep enjoying your system and appreciate your service!great!

@Les said in FOG Imaging/Capturing progress bar.:

@Sebastian-Roth

I think you might be on to something regarding the sectors, beacause i am running Win 10 on a 500GB HDD.

One of my drives on the desktop seems to be failing during the capturing process, as I hear my one of my drives snap, resulting in a error.(Can post the error if you are keen)

@Les just to be clear…is the 6TB Win10 desktop you are trying to capture the same one from your last comment, with a 500GB HD and additional hard drives? I am asking this because I noticed in an earlier comment you posted a screenshot uploading a Single Disk image seen here:
alt text

If your desktop has multiple drives you want to capture, you need your image format to be like this:
0_1543803913394_3260b69f-2f3c-452c-8ce9-da381b71177e-image.png

Perhaps that is why you are getting the error? I would post it for good measure though, just so @Sebastian-Roth or one of the many helpul forum mods can verify what the problem is.

OK - so Partedmagic is now $11 for the latest version - which also comes ready to PXE - no scripts etc required to get ready
Add files to TFTP share - add menu item - done.

menu item =

kernel http://${fog-ip}/pmagic/bzImage64
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/files.cgz
initrd http://${fog-ip}/pmagic/fu.img
initrd http://${fog-ip}/pmagic/m64.img
imgargs bzImage64 boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=0 loglevel=0 keymap=us splash quiet - || read void
boot || read void

Worked first time 🙂

@syschuck I just stumbled upon this post again as I have been thinking about removing Mageia from the installer scripts altogether. But seems like you are still using it. As I have not heard back from you since my last answer I lost track of this and forgot to add php-curl.

I just added php-curl and removed liblzma-devel for Mageia installs. Will be in the next release.

@Kagashe Editing the script solved it, thanks Sebastian.

@Tom-Elliott

Okay, I’ll update and post the result here.

@iekozz I am not too sure where we are at with this multi culti topic here. I’ve just read the whole lot again. We started by fixing your image name possibly along with some other image settings, then got the non bootable media error (FOG is not able to transfer the UEFI firmware boot entries from one machine to another yet!) and talked about timezone and FTP issues.

May I kindly ask you to open a new topic and explain the current issue you are seeing at the moment. We’ll focus on fixing that and move on from there (probably in just another topic). The less we mix up topics the more other people can profit from the things we find out and write to fix their own issues.

So I am marking this solved now as we have solved the initial issue (and more). Please open a new topic and explain where you are at.

@Sebastian-Roth I have updated everything to the latest development version without issue tonight. The web gui definitely seems faster. I will watch for any oddities tomorrow while the system is in use. Thank You Guys again for all you do!

@ElNatcho We are working on this issue. Just in case you are still around. I pushed some major changes to the dev-branch a few hours ago. Should fix the flow web UI issues altogether. Please give it a try if you can and let us know.

@Sebastian-Roth Let me test it with a machine and get a specific model. I will verify the UEFI firmware is up to date as well.

@Sebastian-Roth

Your idea sounds like a good compromise. Something like delete old file on new upload checkbox that is checked by default maybe?

okay, that makes sense. I forgot that the images folder only syncs folders tied to an image in the table.

I tried your update and that fixed the file getting set to 0kb. I test when I can, as FOG has a lot of potential in my eyes and I know most if not all of you are doing this in your spare time, which means a lot. I’m hoping someday I’ll have time to learn PHP and contribute more to the project, but that’s a battle for another day.

Posted in feature request and tagged you and this post for reference.

@blindcat420 said in Cant pxe boot to fog.:

I went ahead and reran the fog installer.
That seems to have fixed it.

Sometimes it’s the simplest things… I need to remember to suggest rerunning the installer when there is strange things happening.

Got him fixed up after a long session through teamviewer. Password reset, DHCP setup, FOG server IP change, switch configuration and all the rest…

Thanks its “WORKING” so coooooool.

Thanks George and Sebastian thnx thnx thnx…

@Sebastian-Roth Yes, its working perfectly now, Thanks!

@Sebastian-Roth Hi Sir I will do so thnx

@george1421

I’ve read a lot to solve the problem, and I think that’s the quid of question:
Snapins Run as SYSTEM or root
All Snapins including SnapinPacks run as the SYSTEM or root user’s security context. If a snapin or SnapinPack runs successfully by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a shared directory that is granted read access for all Domain Users. Well, an individual host’s local SYSTEM or root account is not a member of Domain Users. Therefore, unless alternative credentials are supplied to access the share, any script executed that tries to read this share will not work. There are a few solutions to this. Granting the share read access for anonymous users is the most simple. Specifying credentials within scripts or as arguments are viable options.

How can i specifying credentials with scripts or arguments in snapin console? Could you put an example?

Thks a lot.

@Jamaal Good to hear you figured this out. Would have been quite hard for us I reckon.

Hello mate,
Had the FOG issue: Warning: mysql_connect() [function.mysql-connect]: Access denied for user ‘root’@‘localhost’ (using password: NO) in /var/www/fog/management/index.php

This is caused by the FOG PHP session looking to connect to ‘localhost’, the correct password is not being passed causing the failure. Not having time to research the exact fix I found the following is a quick solution…

Before trying to open the FOG management webpage
Install PHPMYADMIN (this makes database management easy)
Open //localhost/phpmyadmin
Create a new user and give them ALL permissions for ALL HOSTS (basically they should be the same as ROOT
Check the user is there and the permissions are set correctly.
Go into the PERMISSIONS tab and remove the password for ROOT under localhost & 127.0.0.1
Open the FOG webmanagement page
Set up the users in FOG
Go back to PHPMyAdmin and make sure FOG has been added as a database. You will need to log on as the ‘new user’ above
Reset the root password to something secure (as per pre install???)
Open the FOG database
Go to Permissions and BLANK the root password for localhost & 127.0.0.1
That should solve the issue.
Best regards
Arso