@george1421 If this all proves out to work there are two last things you need to to.

Edit the file /opt/fog/.fogsettings There is a line in there called listed as storageLocation='/images'

You need to change it to:

storageLocation='/storage1'

Then run the installer program again (once your imaging is complete). That will just realign everything for you. When the update is done, reboot the fog server. When the fog server comes up reconfirm that showmount -e 127.0.0.1 still shows your /storage1 share as being shared.

Can you continue here please? https://forums.fogproject.org/topic/9517/mysql

@Jaymes-Driver solved - got help in another thread on same topic.
Seems there’s a major bug in current stable. Upgrading to latest branch fixed it.

https://forums.fogproject.org/topic/9499/fresh-install-of-fog-1-3-4-on-ubuntu-16-04-lts/23

@philmills Interesting. AFAIK the inits and kernels are downloaded from the fog project servers (but that is only a guess). I have this url in my notes: https://fogproject.org/kernels/bzImage32

@coop90 Glad you got it sorted, sorry it took so long to get to the bottom of it!

@Tom-Elliott it was quite a while ago i did my testing (and of course i didn’t actually document anything…) but i was working with about 3 or 5 images seeing how much they shared so i could estimate from there, and it wasn’t good. very little duplication detected in spite of the obvious duplication that was taking place.
someone who knows what they’re doing might have much different results

@SusejNatas Thanks for providing your solution, Welcome to the Forums, welcome to FOG, and Welcome to LINUX!

We are happy to have you here! We are sorry no one got to answer you before you solved your own issue, but please don’t let that deter you from making suggestions, modifications, or asking questions!

I have marked your post as solved. If you feel this is in error, please let me know. Feel free to provide further details on how you determined, and solved the issue, as it will help others with similar issues in the future.

@Jaymes-Driver
It’s already the best !!! 😉

@Quazz http://www.thewindowsclub.com/offline-scan-using-windows-defender
https://www.deskmodder.de/wiki/index.php?title=Offline_Scan_beim_Booten_mit_dem_Windows_Defender

@FredG This is typically a spanning tree issue. We have also seen green ethernet (802.3az) cause an issue similar to this. But typically it is spanning tree at fault.

@Tom-Elliott Thank’s a lot!

@amo862 said in EFI Chainloading Failure - Venue 11 x86:

However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?

Do what JJ Fulmer below said, that’s the best advice.

@x23piracy If it’s system wide, it shouldn’t matter, but that doesn’t mean much. System wide still is not “system wide” in the case of curl/wget/apt/yum unless you make sure the default configuration files with the same information.

@george1421 The changes have been made.

@Wayne-Workman Yes, it was confirmed.

I realized the problem, but was on a meeting call. I asked him to test the “fix” and he confirmed with me on chat.

thank’s Wayne !!

I’ll do it and comment results here later!!

@Wayne-Workman
I will build a test system using the newest versions of Debian and Fog today. I’ll post back soon with the results and maybe attempt to fix the older system later.

Thanks

@Tom-Elliott
Thank you, it work fine! Here my po file, it is perfectible but better french than google trad 😉
0_1486735555898_messagesFR3.po

@FredG That would also explain the “Waiting a long time to run post init scripts”. It mount’s the NFS store to perform the post init scripts running, if it can’t mount it it has a timeout value.

@x23piracy Do you have wiki access yet? You should be putting all these fancy pictures you make into there.