@mronh said in Log Viewer Blank:
taking the opportunity here to question, may it have some relation with this “unauthorized” in the storages and server? (image below)
It is a reported bug
https://forums.fogproject.org/topic/16731/unauthorized-storage-node?_=1684166729513
This is the typical behavior if you make the image with BIOS legacy and dump it in UEFI.
Check that you have made the virtual image in UEFI
@processor you can do bat with -> /ru “System”
schtasks /create /sc daily /tn “MYTASK-DAILY-20PM” /TR “shutdown /p /s” /ST 20:00 /ru “System” > C:\Users\AB\Desktop\done.txt
Dell usually sets the drives to RAID in the BIOS.
Fog doesn’t recognize RAID drives, you have to set it to AHCI.
The default installation of Sumatra is done in the user’s profile.
C:\Users\your_user\AppData\Local\SumatraPDF
Fog does the installation with the user System and Sumatra installs in
C:\Windows\system32\config\systemprofile\AppData\Local\SumatraPDF
To install Sumatra for all users you must use
-all-users (https://www.sumatrapdfreader.org/docs/Installer-cmd-line-arguments)
and it will be installed in
C:\Program Files\SumatraPDF
If you already have it installed in
C:\Windows\system32\config\systemprofile\AppData\Local\SumatraPDF
When installing it for all users it seems to detect it and won’t go to
C:\Program Files\SumatraPDF
When I encounter problems of this type, I use PsExec to study the behavior of the installation as the user System.
https://specopssoft.com/blog/how-to-become-the-local-system-account-with-psexec/
@desq-fogforum Do you do the reboot within the script or in the snapin template?
I had a similar problem.
Dell bios is an .exe file with the parameter “/r” (reboot) For example “biosdell.exe /r”
When restarting with “/r” fog it did not understand that the task was finished and it repeated it. I suppose that Windows was rebooted without the fog client being able to inform the server
I solved it by putting the reboot in the snapin template instead of putting the “/r” parameter
The reboot marked in the template is supposed to be done when the task is marked as completed
@desq-fogforum Do you do the reboot within the script or in the snapin template?
I had a similar problem.
Dell bios is an .exe file with the parameter “/r” (reboot) For example “biosdell.exe /r”
When restarting with “/r” fog it did not understand that the task was finished and it repeated it. I suppose that Windows was rebooted without the fog client being able to inform the server
I solved it by putting the reboot in the snapin template instead of putting the “/r” parameter
The reboot marked in the template is supposed to be done when the task is marked as completed
Dell has reused the 7010 name.
The one from 2014 that says “undionly” is the old one: https://www.dell.com/support/home/es-es/product-support/product/optiplex-7010/
You will have the new one: https://www.dell.com/support/home/es-es/product-support/product/optiplex-7010-small-ff/
The new one needs ipxe.efi
I think you need to update the ipxe that has updated drivers
https://docs.fogproject.org/en/stable/reference/compile_ipxe_binaries.html
@deblpuw said in Return code snapin unknow ( -1073740286):
It seems that the parameter is “/silent” not “/quiet”
https://docs.citrix.com/en-us/citrix-workspace-app-for-windows/install.html#common-parameters
@Kureebow Dell’s website says storage can be UFS, eMMC, or SSD.
What’s on your laptop?
https://www.dell.com/en-us/search/latitude 3140
Perhaps there is still no fog or partclone support for UFS or eMMC storage.
Probably, you need configure the time zone on the fog website.
“FOG Configuration” (above, wrench icon)
“FOG Settings” (left column)
“General Settings”->“TZ Info”
This is the typical behavior if you make the image with BIOS legacy and dump it in UEFI.
Check that you have made the virtual image in UEFI
On Linux, ‘mv’ is used to rename files. ‘fogsettings-firstInstall’ is not a folder, it is the new name of the file ‘.fogsettings’, in the FOG wiki they do it so you can keep a backup copy of what you had.
@mronh said in Log Viewer Blank:
taking the opportunity here to question, may it have some relation with this “unauthorized” in the storages and server? (image below)
It is a reported bug
https://forums.fogproject.org/topic/16731/unauthorized-storage-node?_=1684166729513
+1
I have the same problem on two separate servers. Both updated from fog 1.5.9 to 1.5.10
One with Ubuntu 20.04 server and the other with Ubuntu 20.04 desktop
@ITRecords
At least in previous versions, it was necessary to create a hidden file in /images and /images/dev called .mntcheck
$touch /images/.mntcheck
$touch /images/dev/.mntcheck
In my server it shows up (ls -la) as :
-rwxwrwxrwx fogproject root 0 jan 8 2019 .mntcheck