Hi Sebastian,

Thank you for your answer.
Indeed the problem was some definition I set and forgot in the global settings.

Under “Non-Registered Host Image” I set : /images when I removed it, everything works fine.

Great product with a great community.
Thanks again!

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

Now My Question is … Manually Written the file ->“bzImage4183” in the Host Kernel Field… is it Correct Sir?
Thereafter, I updated by using Update Button in the Make Changes? Field… is it Correct Sir?

Yes this is correct. This field allows you to assign a specific kernel to a specific host. That is the design of FOG. No this is not correct. You have hard defined for that host it will only use bzImage4183. The main and updatable kernel is called bzImage. When the next version of FOG is released (1.5.5) it will only update bzImage. The host where you statically defined bzImage4183 will continue to us that kernel forever.

Also Sebastian’s fix also requires you to update the init.xz files to completely eliminate the delay during disk format creation. So both the kernel (bzImage) and the virtual hard drive (init.xz) need to be updated to correct this problem.

@dburk Sorry for digging out this old topic. While trying to figure out some replication hickup I found and fixed a couple of issues within the code. All that will be in the next release. Hopefully coming soon. Let me know if you are keen to test those changes beforehand.

Edit: Issues fixed in 1.5.5.

@Sebastian-Roth

Dear Sir (Sebastian-Roth),

Sir, One Word … You are Real Great Sir…

I am totally frustrated with Error…Till Now.

Now It has got solved. Now running successfully…

Devotedly and Willingly Thankful to You Sir. Real Great…

Sincerely Yours,

Basavaraj From India,

@Sebastian-Roth

Ok. I will change those values to 0 on Monday and let you know if it boots up. Appreciate he help!!!

@iwohl The hack I created (with the help of Tom who converted it into a plugin) for persistent group like function. In this case you will create a template “fake” host, who’s settings will get copied to any host added to the group. That should get you pretty close.

@JimmyJ0516 Definitely an issue of sending Wake On LAN packets across VLANs and all that. We talked on chat. Not sure yet if the switches used (Cisco Meraki MS-350) can do something like “UDP-helper”, directed broadcasts or call it whatever you like. At least I have not found and details yet.

@zpoling DHCP handshake looks good in the latest PCAP but as you said we won’t find out what was going on when it failed. More often than not those kinds of issues keep coming back until you really find and fix them. Make sure to capture the traffic when you see it happening next time.

Marking this as solved for now.

figured it out thanks to this thread.

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@Sebastian-Roth I’ve opened another thread about it. I ran a program that scans for DHCP traffic because I’m not too familiar with wireshark, but it does the same thing I imagine. After three hours, the only traffic showing up was our one and only DHCP server.

https://forums.fogproject.org/topic/12615/tftp-only-working-with-certain-vlans/2

@rlindenschmidt Have never seen this error before but doing a little research I think LDM in this case means Windows Logical Disk Managment - see here·. Can you please take a picture of Windows Disk Management console from that client and post here?

@JackWallington Please answer George’s questions first. As well let me add this one. Do you have a D-Link DGS-3620 switch between your HP desktop and the FOG server? If not you still might check to see if some kind of DOS attack prevention is enabled on a switch connecting those two - more information see here.

@FrancoDin said in 2 Error in iPXE (time out and sand device):

Just one final doubt, what does dnsmasq do to the dhcp?

We have dnsmasq only configured for proxy dhcp mode. In this configuration dnsmasq will only provide pxe boot information to override dhcp options 67 and 68. You MUST have a functional dhcp server on your network too. This configuration is used when people can change the settings in their dhcp server, we just override them with dnsmasq. If you turn off dnsmasq then the only thing that falls down is pxe booting. No other services are impacted.

If you are getting unexpected results from your dhcp server, then its your dhcp server not dnsmasq doing this to you.

If you want me to provide that dnsmasq is not messing up your dhcp process we can do that too. We’ll just capture a typical pxe booting process using tcpdump (or wireshark) to see exactly what is going down your network wire. I can show you how.

@Sebastian-Roth It had reset the user to ‘root’ and the password blank. I have run the ALTER USER commands previously so perhaps that did it.

Once I had manually entered the correct username “fogstorage” and the password, which I still had from the working node, I was up and running.

Thanks,

Matt.

MY BAD ! @Sebastian-Roth

It’s because i have to be precise on the session creation fileds.

I have to put exactly the number of clients ?

When i was create session ive put timeout time…

So it work but after the timeout…

Sorry thanks for ure help anyway

@Troye-Johnson But why did the download fail??

As well, can you please update your signature!

@Sebastian-Roth
It worked! Thank you

@Shad0wguy Can you please take a screenshot of the message you see in the kernel page where is says “A valid database connection …”?

Please take a look at /var/www/html/fog/lib/fog/config.class.php to see if the database credentials are set correctly. You can try connection to the database on your main server from your storage node using the mysql command line client:

mysql -h x.x.x.x -u fogstorage -D fog -p

Put in the master server’s IP instead of x.x.x.x!

We have someone else reporting a similar issue when upgrading the storage node from 1.5.3 to 1.5.4. Possibly there is a bug/problem that we are not aware of yet. On the other hand I have done storage node installs and tests lately without running into such an issue.

@Sebastian-Roth Yeah I was thinking the same thing. So now that tablet is booting reliably every time. I’ve moved to another one and it’s getting the errors again. This is totally a tablet-related issue and not a Fog related one.

@Dominique From what it reads in the other post the issue seems fixed in the working branch and I have done some minimal multicast test lately.

The FOG dev Team is not very strong at the moment as people have other important things on their private schedule and can’t put as much time into FOG. So I can’t promise you a date for the next release yet. But I think it’s not that far away.

If you use FOG in your company you might think about helping out in the FOG team to make things go a bit faster. One way to help is by answering questions in the forums. Or even get involved in coding and testing.