@huecuva That is an interesting update for sure. I believe graphics cards have a bios of some sort and sometimes there’s some option rom boot option related to the gpu in the computer’s bios setting. It would make some sense for the graphics drivers to also update the bios or boot option roms on gpus.
What GPU’s do you have? GPU’s of the gtx 10xx series and newer have a ‘studio’ driver option that’s supposed to be the sort of ‘stable’ branch option. If your cards can use that, maybe using that as a standard could help if it’s not something you’re already doing?

I´ve used memdisk from /tftpboot and it worked with fog 0.32:)

Finally got it to work!!!

I want to thanks all of those for your being patient with me and giving feed backs through out this particular cluster. After getting tired dealing with the “what if” finally it was time to restore the drive to factory state by destroying all sectors, tracks and cylinders. Then installing Windows 8 and letting Windows 8 to create sectors, tracks and cylinders. It worked!!!

ok no problem, thank you.

Well, I got some good news. I was able to get a successful multicast going tonight. I am not 100% sure of what fixed it. I did several things.

Not in particular order:

Updated FOG to trunk Disabled IGMP snooping from the switches Made a change to CentOS as seen here that has to do with routing (honestly don’t think this helped) Added 232.168.1.0 for FOG_MULTICAST_ADDRESS (it wouldn’t work without that)

I plan to do more tests to really make sure it is working tomorrow and the following days. I will keep this updated if anything substantial changes.

Thank you to everyone.

@Tom-Elliott
@george1421 after updating to the latest version the deployments to the NCR still fail. I am able to image PCs and laptops so I will just use a different solution for the NCRs and leave it at that. Thanks everyone for all of your help and assistance!

Thanks,

Anthony

@Quazz Thanks heaps for digging into this even more. I guess it will be very hard to actually track down when and how this was introduced.

This problem is rare enough on its own already (personally haven’t come across it at all)

I would have said so myself a day or two ago. But then I even ran into the same issues when debugging a different partition layout problem for another user in my VM test setup (VirtualBox).

@jmvela2x Thanks very much for sticking with us on this and doing the tests!

Somewhat like that, but organized in such a way that FOG can automatically inject the correct drivers into the firstboot process. If I were to use the Driverpacks, I’d need to build a database linking device IDs to folder structure, and that complicates the script significantly.

[url]http://fogproject.org/wiki/index.php/Troubleshoot_TFTP[/url]

@jkozee @Tom-Elliott Sorry for bringing up such an old topic again. Working on moving towards the new 5.10.x kernel I was looking at the patches we still apply to our kernel. Most are part of the upstream kernel but not the fix discussed in this topic.

Though the kernel code has changed a bit and I am wondering if we’d still see the slowness without our fix? Would anyone of you be able to replicate the issue with a 5.10.x kernel (with and without fix)?

Searching the web a little more I stumbled upon this patch that made it into the official kernel not long ago: https://patchwork.kernel.org/project/linux-input/patch/20200910143455.109293-12-boqun.feng@gmail.com/

Not sure but could play a role in this case. Anyway it would be great to see if the issue can still be replicated with the newer kernel - without fix.

@mlnancejr8808 Hmmm… interesting. But if that is what it takes then I think you are on your way. You now have a solid image that will support your fleet with a common image. Well done!!

For now I’m solving this. I realize the issue at hand is likely still there, but this (at this point) is not a problem of FOG or the FOG Client in a “bug” form. This seems much more likely to be a problem simply with disk space. Of course feel free to post info as we find more info out.

@dustindizzle11 Sorry for my late reply. There is a side way you could go with this now that you know how to modify the init.xz image. Grep yourself a copy of the current script and exchange the one you posted with this new one. See if you can make it work with this. Just an idea for a quick dirty fix.

@Kirill Great, I will add this to the fog-client in the next days!

For the FOG translations you wanna take a look at the files here: https://github.com/FOGProject/fogproject/tree/dev-branch/packages/web/management/languages

The master branch points to the current version (1.5.8 as of now) and for new things we work on dev-branch (as in the link above) or created feature branches. As we don’t have much changes in the language files currently I would suggest you work on what we have in dev-branch.

Best if you grab a copy of the english version and start translating on that. I know there are many lines marked as fuzzy because of changes in strings. I was hoping to clean this up at some point but never got to it so far. If you are keen you are more than welcome to clean this up first. Would be really great!

@junkhacker Not invalid password but ACCESS DENIED

@Quazz Thanks again for your work on this! I’ll add this soon but have one more question about it, see on github.

What are your thoughts on https://forums.fogproject.org/topic/12428/win7x64-golden-image-partitions-problems-again/29 as an alternative system, by the way?

Good you reminded me on this! I moved the issue from repo fogproject to fos#18 where it belongs now that we have those things separated a while ago. Please let’s try to collect information and ideas there.

@Jonathan-Cool Nice you got it working! We’ll add Quazz pull request anyway for the time being. Should be in there in the next couple of days. I’ll mark this solved now.

[quote=“John VanHoose, post: 39534, member: 4156”]I just went back to .32 it works with no extra troubleshooting.[/quote]

It’s tempting, John, but I’m not giving up just yet.

@Joseph-Hales I agree with the plan to solve the thread but not for the reasons you describe, rather for the fact this was likely somewhat related to the issues found earlier.

@Sebastian-Roth said:

Thanks for posting this. Please check your apache DocumentRoot setting: grep DocumentRoot /etc/apache2/*/*

Seams a bit like thinks got mixed up. See the timestamps of /var/www/html/fog… It’s Jul 16. From the error messages we saw in the apache error log this is the one being currently used and probably what you will see when grepping for DocumentRoot. But the newest date (Nov 4) is /var/www/fog. And I guess this directory is from a newer trunk install but is not being used.

If I remember right Ubuntu changed from /var/www to /var/www/html not that long ago. Tom changed the installer to reflect this and maybe it ran into some condition on your system to also change this at some point.

My advice:

Backup all the stuff in /var/www by moving it (mv /var/www /var/www.bak && mkdir /var/www && chown www-data:www-data /var/www) Update FOG to latest trunk (cd path/to/trunk && svn up) Comment the wget command in the installer script as done before Run the installer Check DocumentRoot setting (see above) and compare with what you see in /var/www

I really hope this will get us one step further. I am very sorry that it took us so long to find out about those different fog directories in /var/www…

This worked for me! I had very similar issues!

Thanks!!