@Atton If resolve.conf is managed by the NetworkManager (typ ubuntu or debian variant) application then you need to make those settings inside the networkmanager program. The other thing that would overwrite that file is if your fog server has its address defined by dhcp.
I would go ahead and set the file manually and see if something along the way changes it. No guts no glory, I say…
If someone changed the linux password for fogproject or messed with the setting for that account within the web ui that error will be thrown.
Work through this document: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
@pnwbsi said in Image Path Change:
I am willing to help in anyway!
OK I’m going to work on a patched upload file to hopefully give us a bit more details and I’m going to add in a mount delay timeout just to be sure. I should have a little time later this AM to work on it. I’ll follow up with instructions later.
@Atton I just answered this in another thread but my searching skills are weak at the moment.
For your resolve.conf it will need to be adapted to looks similar to this.
search domain.com ad.domain.com
nameserver 192.168.1.16
nameserver 192.168.1.17
Put your most likely nameserver first in the list as well as the most likely domain first in the search list.
once resolve.conf is updated you should test to ping your hosts by their windows names (short names, not fqdn)
@bogle The FOG server talks to the target computer via the FOG Client/service. That service has a check in interval that is set in the fog settings. So the default may be 5 minutes (300 seconds), so if you issue a task to the target computer it could take up to 5 minutes before the target system reacts.
Also on the fog up/down indicator it doesn’t use a ping, but a connect to port 445 to confirm the system is up or not. If your windows firewall is blocking connections to port 445 then fog will assume its down.
@zagaeski These core dumps are troubling. It basically means the linux kernel is not able to run on this system.
Lets make sure your firmware is up to date on this system.
Once that is done, lets try to force the 32 bit environment to run on this system.
bzImage32 (case is important)init_32.xz
@brakcounty Sorry I didn’t see this until now. There is a hidden file in /opt/fog called .fogsettings (yes it starts with a dot). Edit that file. There should be a value like storagelocation or something like that. Correct that path and the installer should run with the new location in mind.
FWIW: The .fogsettings file contains your first run settings.
@Sebastian-Roth Are we running into the mount timeout issue we’ve tried to debug before? I also wonder if we could add a bit more debugging information in that unable to find image store message, similar to the when the path was set incorrectly.
Let me see if I can come up with a patched fog.upload
@pnwbsi if you are willing to help us test this, hopefully we can squash this issue once and for all.
What version of FOG?
What version of FOS Linux (kernel) are you using.
It appears to have done a core dump (exited badly).
Assuming that is the latest version of FOG, that line should not have caused a core dump: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S99fog#L23
@pnwbsi Unless someone changed the exports command, /images/dev is exported as read-write and /images is read-only. It should not be possible to upload an image to /images.
Would you also include a snapshot of the configuration page where the image path is defined?
@Arjenbulkens I’ve been trying to understand why this would fail if run by the fog snapin.
I reverse engineered the command and I came up with the same syntax as you.
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoAdminLogon" /t "REG_SZ" /d "0" /f
I checked and on my system SYSTEM has full edit rights to that key too. You can execute the command from a raised admin prompt OK, so why can’t SYSTEM. I’m logged into a linux computer at the moment so I can’t test, but I know I’ve seen the “Run as Administrator” and “Run as another user”. I wonder if we can “run as another user” and pick SYSTEM as the user account. You WILL need to be a local administrator on the box to get the run as a different user prompt.
@Arjenbulkens I also wonder if its the full name of the base key that is at fault?
HKLM, HKCU, HKCR, HKU, and HKCC is from the MS doc for reg add
ref: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/reg-add
@Arjenbulkens This should work. But to debug what happens if you only run the delete command? Right now its not clear which command is causing it to hang, I might guess the delete key.
I also wonder what the logic is to delete the key and add it back, why not just use the add key to change its value?
@oleg-knysh This is a very strange issue. The only recommendation/question I have at the moment is what version of the FOS Kernel are you using? The latest version is 4.19.64
I also wonder if you update to the latest version of FOG (1.5.7) to see if any of the fixes since 1.5.4 will address this issue. I don’t have a high confidence that it will fix this speed issue. I know it will solve some disk structure problems.
@gpd187 said in Cannot PXE boot target capture device.:
I boot to the network with will not load the undionly.kpxe
Realize that undionly.kpxe will only boot on bios (legacy) based machines. For uefi based machines you will need to send ipxe.efi
e both Virtualbox VM’s
For virtualbox make sure you are using a bridged connection to your network and not natted
And also created a symbolic link undionly.0
FOG doesn’t use undionly.0 files. That symlink is not needed.
So lets start out with what is your dhcp server for this network?
What do you have configured for dhcp options 66 and 67?
Pick a physical computer to test with:
What mode is the firmware in? (bios or uefi).
From a physical computer on the same subnet as the FOG server, can you ping the FOG server?
When you PXE boot the target computer and receive an error, snap a picture of the error on the screen and post the picture here. We need to see the context of the error message.
@Arjenbulkens OK what is the command you are using inside this batch file to delete the key?
The FOG Client runs as the user SYSTEM, so it should have full access to delete from HKLM. I’m still leaning towards an unanswered prompt doing this.
@Arjenbulkens said in Snapin Batch file stays in-progress:
The batchfile deletes a registry key
What is the base path for the key? (HKLM, HKCU,??)
@chunter2 Leaving it won’t hurt anything. One might think, if its working now its good enough.
@brakcounty Ok so it was installed using the tarball method. That way will work too. You will then just download the 1.5.7 tarball and extract it. That will create a directory called "fogproject-1.5.7” change into that directory and then the bin directory. Inside there key in ./installfog.sh The installer will run and ask to confirm a few settings and then it will upgrade the program code. You will/must have internet access for the installer to complete.
@chunter2 Rerunning the FOG installer “should” have fixed any sins from the past (with the exception of custom settings in the fog configurations like your kernel name)