@Kevin-Talbot Make sure you read the notice on the latest stable release for Ubuntu before you go ahead: Please make sure you say NO if asked about removing and re-installing PHP and Apache when upgrading to 1.5.7 on Ubuntu!!! https://forums.fogproject.org/topic/13488/fog-1-5-7-officially-released Beside that I’d suggest you wait before upgrading. 1.5.7 turned out to not be as rock solid and we are working on a more stable release 1.5.8 to come out in the next months.

@TaTa There should be a log file somewhere in /var/log/mysql/error.log or similar. Please take a look to see why it doesn’t seem to properly start.

@rankinc This partition number 5 is a recovery partition which FOG doesn’t move on the disk. So it’s unable to shrink your main Windows partition.

@george1421 said in issue with netcard of dock gen2 of lenovo l390: @JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver. I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver. @Interrupt Give this solution a try, download the kernel @george1421 made and set it on that host. It worked for me with the lenovo usb-c ethernet adapter, it stands to reason it will work for the dock too.

@Sebastian-Roth said in FOG 1.6, identified problems: @lebrun78 Have you checked the apache and PHP-FPM logs yet? See my signature. Here is the image import file 00-etudiant-rentree2019,,etudiant-rentree2019,,,,,1,,9 1903-ELEC,,1903-ELEC,,,,,2,,9 1903-INFO,,1903-INFO,,,,,2,,9 1903-VIRT,salles 204 et 206,1903-VIRT,,,,,2,,9 win10light-1903,,win10light-1903,,,,,1,,9 tail -20 /var/log/httpd/access_log 148.60.15.217 - - [14/Nov/2019:09:12:47 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:47 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:47 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:47 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:48 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:48 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:48 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:48 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:49 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:49 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:50 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:50 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:50 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:50 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:51 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:51 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:52 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:51 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" 148.60.15.217 - - [14/Nov/2019:09:12:52 +0100] "GET /fog/status/bandwidth.php?dev=eno1 HTTP/1.1" 200 28 "-" "-" 148.60.10.10 - - [14/Nov/2019:09:12:52 +0100] "POST /fog/management/index.php?node=home&sub=bandwidth HTTP/1.1" 200 53 "http://148.60.15.217/fog/management/index.php?node=image&sub=import" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0" tail -20 /var/log/httpd/error_log [Wed Nov 13 15:12:59.336472 2019] [suexec:notice] [pid 8977:tid 139894213593344] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Wed Nov 13 15:12:59.349238 2019] [lbmethod_heartbeat:notice] [pid 8977:tid 139894213593344] AH02282: No slotmem from mod_heartmonitor [Wed Nov 13 15:12:59.351083 2019] [mpm_event:notice] [pid 8977:tid 139894213593344] AH00489: Apache/2.4.37 (centos) OpenSSL/1.1.1 configured -- resuming normal operations [Wed Nov 13 15:12:59.351099 2019] [core:notice] [pid 8977:tid 139894213593344] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Wed Nov 13 17:10:00.053054 2019] [mpm_event:notice] [pid 8977:tid 139894213593344] AH00492: caught SIGWINCH, shutting down gracefully [Thu Nov 14 08:26:10.431342 2019] [suexec:notice] [pid 1209:tid 140320426273024] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fogus2.istic.univ-rennes1.fr. Set the 'ServerName' directive globally to suppress this message [Thu Nov 14 08:26:10.993453 2019] [lbmethod_heartbeat:notice] [pid 1209:tid 140320426273024] AH02282: No slotmem from mod_heartmonitor [Thu Nov 14 08:26:10.996363 2019] [mpm_event:notice] [pid 1209:tid 140320426273024] AH00489: Apache/2.4.37 (centos) OpenSSL/1.1.1 configured -- resuming normal operations [Thu Nov 14 08:26:10.996388 2019] [core:notice] [pid 1209:tid 140320426273024] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' tail -20 /var/log/php-fpm/error.log [13-Nov-2019 15:12:59] NOTICE: fpm is running, pid 8966 [13-Nov-2019 15:12:59] NOTICE: ready to handle connections [13-Nov-2019 15:12:59] NOTICE: systemd monitor interval set to 10000ms [13-Nov-2019 17:10:00] NOTICE: Terminating ... [13-Nov-2019 17:10:00] NOTICE: exiting, bye-bye! [14-Nov-2019 08:26:10] NOTICE: fpm is running, pid 1200 [14-Nov-2019 08:26:10] NOTICE: ready to handle connections [14-Nov-2019 08:26:10] NOTICE: systemd monitor interval set to 10000ms And no image imported :-(

@sgoodman said in rEFId (feature request): When I use any other version the “blue line” appears and then it hangs - has a message with respect to initializing/loading then hangs. Hmm all I can tell is by the file size its not the same version as I have with 1.5.7. If you are at the blue line, if you hit esc or arrow keys does it give you a console or something where we can pick up the version? I can’t really help you get the exact version since you are not using the version that came with a specific release. BUT I can give you a direction if you want to do a little leg work that we find the working version for you. With the FOG 1.5.0 release FOG shipped refind version 0.11.0 I see from the sourceforge site that 0.11.4 was recently released (note: fogproject doesn’t compile these binaries, but use them untouched from the FOSS author). I can tell you its probably not 0.11.4, so if you want to download one by one 0.11.0 to 0.11.3 and try them to see if you can find the one with the blue line. Also I would try 0.11.4 to see if the latest version works. All you need is the refind.efi file from the zip file and place it into the ipxe directory on the fog server. https://sourceforge.net/projects/refind/files/ If you find that the later releases work the best (with supporting users testing) its possible that we can get that version of refind into 1.5.8 release that is scheduled to be released winter 2019, but no promises.

@sgoodman While this is a good point and I like the idea of a cleanup it’s not as easy as removing those options I am afraid. There is quite some code logic in the background that I would argue needs a cleanup together with this as well. Not sure if we should consider removing it all in a rush now. Sure we can just remove the UI part of it quickly. But all the rest would then stay in the code for way longer I suppose.

@sgoodman I just finished some testing and I can’t replicate the fog-client crash yet. So far I guess it’s either related to particular updates (I had some .NET updates as well as system updates) or caused by some particular GPO WSUS settings (just a wild guess). Here is a picture of the update test with the fog-client running all the way through without a single crash - watching the log file (powershell get-contents -wait and the services view):

@sgoodman said: I have been updating FOG on a regular basis and never changed the encrypted string to clear text and it always worked. There was no change of that code since Feb 1, 2018. Was an encrypted string “semi-supported” for some time after the commit? Did a recent update nullify that? From what I understand about the code it seems to try both ways - un-encrypted and encrypted - line 40ff. This has not changed since Feb 1, 2018. Neither hast the fog-client code changed since Apr 10, 2018 (0.11.16 released together with 1.5.1). Is it possible you changed your AD logon credentials in the last weeks and somehow hit some kind of special case with character encoding that we were not aware of? Just guessing here. I use “technicians” to help me deploy (students) and they are not normally given this credential as it could create a security concern. We are working on this - see github issue. Tom added it to the working-1.6 branch already and I will adapt this to dev-branch today.

@DeRo93 said in HP Elitebook 840 G6 - UEFI PXE Boot not working.: Elitebook Same network segment for both PCs ? I had an issue with UEFI with non-standard netmasking and after weeks of messing around with it learned that the I needed to have the broadcast address of 255.255.255.255 instead of the what should have worked (only on the router - router was a Cisco). Basically I use to hardwire in the correct broadcast address on the appropriate Cisco interface, I took that out (let the Cisco set up the default) and it worked… Don’t ask me why, it was “legal” from a networking perspective.

@Keating178 The Invalid Storage Group error you were seeing should be fixed if you can upgrade to the latest within the dev-branch from GIT. Hopefully this will fix the issue you were seeing too.

@ricounet Ok, so you can delete that one entry from the DB: shell> mysql -u root -p Password: ... mysql> use fog; ... mysql> DELETE FROM hosts WHERE hostID = 410; ...

@samdoan said in All disk capture unable to deployed to two larger disks: Deploying the image to a destination system with multiple disks that are larger than the source system fails. From the error message you posted I am not sure it’s fails because of the disks being larger. Please check the files in your images directory on the FOG server /images/2DriveTest to see if you have files named .size in there. ls -al /images/2DriveTest EDIT: Taking a closer look at the scripts I see that we have a bug in those. The size information of the disks was added to the “multiple disk” mode because we were trying to help someone using two NVMe drives that would swap position on every boot (just a thing with NVMe drives). Let me see… I think as a quick fix you should be able to make it work by removing the size information files. mv /images/2DriveTest/*.size /tmp Then try deploying the image again.

@bigmuddyfoot said in Cant create User - Setting up fogproject user..................................Failed!: How do i do that? It depends on where the fog installer is, but it would be similar to this. tail -20 /root/fogproject/bin/error_logs/foginstall.log and assuming you are installing fog 1.5.7 tail -20 /root/fogproject/bin/error_logs/fog_error_1.5.7.log

@markbam said: I’m not exactly sure which machine the chmod command is being run. Is it FogServer sending the command over the network or the StorageNode issuing the command locally? The master node issues lftp command to sync the files over. So from what we see in the log I would think that it’s a FTP command issued by the master node but run on the storage node. But it’s kind of strange you can fix this by chown on the master node. Node side shows some as rwxr-xr-x but the rest are rwxrwxrwx. What if you make them all rwxrwxrwx on the storage node? The only way I’ve been able to get it work is to change the ownership group from fogproject to www-data on the server. As I said, this is kind of strange and I do not understand it yet. Possibly I have a wrong understanding of this issue. So my particular issue is figuring out why Fog’s FTP once uploaded snapins as fogproject:www-data but now uploads as fogproject:fogproject. I might be wrong but I would suspect that it never uploaded as fogproject:www-data. @Tom-Elliott what do you think? Or figuring out why the chmod wants the permissions associated with www-data instead of fogproject. While access rights are a combination of ownership (chown) and permissions (chmod) those are not really associated with each any further. But maybe I got you wrong on this one.

@dsoden said in Blank Install Page: firewall still not being detected after detection of SELinux and prompt to disable, which later causes problems non locally. I ran into the same issue the second time I setup a centos 8 server, but I know from the fog install prerequisites that selinux needs to be set to permissive and firewalld needs to be stopped before FOG is installed. So when it got to that point in the installer I noted it, but it continued without complaints. When I have time I was going to reverse engineer why the firewall’s state wasn’t being detected in centos 8, but decided to spend my weekend not hovering around my computer (til now).

@zaboxmaster /usr/share/fog/lib/funcs.sh

@Adriano-Rocha said in I have this problem can someone help me?: put the redimioneaval I’m sorry I don’t understand that word. So lets try again. When you created the image definition for that 500GB image, did you pick the option for “single disk resizable”? FOG will compress the image onto the fog server even if you selected “single disk non-resizable” to save space on the fog server. We need to understand how the image was captured.

@george1421 After fully patching the workstation it still run compatibility ok. I didn’t try imaging before but I completed imaging the VM after the update and it imaged but threw a strange error: It almost looks like a core dump but the system kept imaging. I have noticed several times that in the percent complete line it will post a message about balloon request will be partially <something>. And then several seconds later balloon floor reached. On both esxi and now on hyper-v. But I think that is a topic for a different thread and a different time. Edit: Irrelevant follow up. I noticed that 4.19.48 was listed on the screen shot so I confirmed the version of bzImage and it was indeed 4.19.48. I put back 4.19.64 (which was shipped with fog 1.5.7 and that CPU core dump did not come back on a system reimage. So its possible the older bzImage had issues that were resolved in 4.19.64.

@Gilberto-Ferraz said in Upload Image From HDD 500GB to SSD 120GB: will try to recover the system and install new centos. First make sure you get this all back to running on Ubuntu. Don’t try to move to CentOS in a rush. There are more things that can go wrong when moving to a new Linux OS.