Just wanted to update. I have been busy here at work so I have not been able to do anymore testing on the init files. So sorry for the delay.

@Towndrunk said in Multicast won't start: Is there any benefit to updating all the time if there is also the potential to have things not work? The benefit - getting a bug you report fixed. Getting bug fixes others report. Updating is totally up to you. Nobody is forcing your hand, and Release candidates are just that. Release candidates. If you want to sit on it, you can. If you want to update, you can. However - if you have issues and ask for help here, and the devs/mods/testers know your issue is fixed in a later RC, we will ask you to update and won’t offer much help with getting your older RC to work, when all you would need to do is update. Of course we’d help with the updating itself if you had problems. But it’s all still up to you.

@Wayne-Workman said in New Fog client and security: @LibraryMark said in New Fog client and security: It’s just that for my situation, in a public library with public hosts on a network totally separate from our staff net, I am not sure I have a need for bullet-proof security there. You’re public users are not a security risk? And I know you say you have HDD locking software (Centurion SmartShield or Faronics DeepFreeze probably), but this doesn’t really matter. If there’s a security hole and someone knows how to exploit it, they can exploit it every time they want. Once there’s a compromise, those computers are no longer safe for users to use, no matter how many times they are rebooted and ‘reset’. The legacy client is not secure. The legacy-enabling functionality server-side is also not secure. It is advised that once you have moved to the new fog client, to remove legacy passwords from the FOG server. We are using Reboot Restore Rx. Are you talking about the fog client still?

@george1421 I’m 99% sure it was the suggestion of something I found on the forums a long time ago, but simply forgot. Like I said, once everything calms down, I’m planning on rebuilding my FOG machine anyways, and blast away old images, especially since I can drop driver packs in now :)

[quote=“mpmackenna, post: 893, member: 373”] [LEFT][COLOR=#333333]I have the below error over and over again in my FOG log viewer. I checked to see if my /var/www/fog/commons/config.php file had the correct settings and it does. I also was able to log in to the mysql db on the fog box without trouble. The db is on the same local machine as the FOG installation. Can someone please tell me how I can further troubleshoot this error?[/COLOR][/LEFT] [LEFT][COLOR=#333333]I am running FOG 0.32 on Debian 5.[/COLOR][/LEFT] [LEFT][COLOR=#333333]Thanks,[/COLOR][/LEFT] [LEFT][COLOR=#333333]Mike[/COLOR][/LEFT] [LEFT][COLOR=#333333][01-30-12 1:12:13 pm] Failed to connect to database server, will try again in next iteration.[/COLOR][/LEFT] [LEFT][COLOR=#333333][01-30-12 1:12:23 pm] Failed to connect to database server, will try again in next iteration.[/COLOR][/LEFT] [/quote] My problems with task hanging and getting [COLOR=#333333]“Failed to connect to database server” messages, [/COLOR]were solved by changing “WOL_INTERFACE”, “eth0” from 0 to “eth1” in both config files /var/www/fog/commons/config.php and /opt/fog/service/etc/config.php

@Vickie-Osbornr said: Asus X200M Are we working with this one?

@dcorpening You would probably be best off upgrading to FOG Trunk. It would also be helpful if you could post a short video of the boot process so we can see it, or a series of pictures of the last thing the computer is saying before exiting to the local Windows.

Here is the file I used. 0_1486506949560_SetupComplete.cmd Place your SetupComplete.cmd in %windir%\Setup\Scripts (you will nedd to create the scripts folder.) Copy your unattend.xml to %windir%\system32\sysprep\ hit windows key and S, type service, click on services, find FOG and right click and select propereties, select disable click apply. hit the Windows key and R to open the run box, type in sysprep. double click the sysprep icon. Hope it works for you.

@unknownhost99 i just want to let everybody now that the server functions properly know thanks to everyone who replied, it was a great help and i love the service you supply keep going at it!

@Sebastian-Roth said in Connecting FOG to Virtual Machine: What host OS do you have VirtualBox installed on? Windows 10 @Quazz said in Connecting FOG to Virtual Machine: the PIIX3 one works fine though. I changed my chipset to PIIX3 and it works! Thank you guys for the long headache relief!

@ManofValor Yep clonezilla to a local usb hard drive. For the physical machines that is the easiest route.

@george1421 @Wayne-Workman I have tested using the Partclone Zstd image compression method on an image under Centos 7 and was able to get it working with one small thing. I had to download ZSTD as it wasn’t native to the base OS. yum install zstd -y I was then able to extract and mount the image using the commands touch /tmp/d1p2_extracted.img cat d1p2.img | zstd -dcf | partclone.restore -C -s - -O /tmp/d1p2_extracted.img mount -t ntfs-3g /tmp/d1p2_extracted.img /mnt/ I also added the -f flag to zstd to force it. I don’t think this is necessary, but as a testing scenario it worked.

@Sebastian-Roth I agree. But I also don’t have access to my building’s switches to fix multicast.

@Joe-Gill Great job. Boo @Microsoft. Booooo

@BardWood If you still have the original backup file from when you upgraded the server originally, this would be your best bet. It should be in /home/fogDBbackups It typically is time stamped. Once you reinstall 1.2.0, you’ll need to use the backup sql file to restore it as a lot changed in the DB between the two.

I can now confirm that the Lenovo Mini-Ethernet Extension Adapter (p/n: sc10a39882bb, fru: 04x6435) also works in both UEFI and Legacy network boot.

Thanks to @Tom-Elliott again for coming up with a fix so quickly! I am marking this solved then. But I still think having a testcase suite would be really good as we could make changes to the awk code, run the testcases and just be sure to not have it broken for other known cases. I think we could collect data from the community fairly easy as the information is already there (in d1.partitions that people have lying around on their FOG servers by the dozens)…

So, worked remotely and was able to help determine part of the problem. Installed apachetop and took a look, found a lot of things still looking at servicemodule-active.php. We moved away from this call as it had some weird issues on its own. Moved the file and the GUI become much less sluggish. Worked to get phpmyadmin working as well. This wasn’t a problem with php-fpm vs. libapache2-mod-php (though I did make sure phpmyadmin would access using the php-fpm system). Part of the problem that was happening was the rewrite rules that handles api system. Moved the rewrite rules into the directory stanza of the fog.conf. Made this update in the working-1.5.1 branch as well. I haven’t had time to test whether this move actually still allows the system to work, but it should. Will work on that this weekend (testing to see it works properly). Also, we are still working to help purge the db of old stuff that’s no longer needed.