@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.

@george1421 thank you!!!

I don’t think the permissions are changing on a reboot (possible, but I have doubts). I can see the permissions may be changing (not staying the way you set) when you capture an image and only for the captured image.

Can you provide a screen shot of what the permissions are being changed to?

@Sebastian-Roth It is any option to clone the images in the storage server and not in the main server? If there is how it works? Thanks!!

@Nono Marking this solved as well now as I finally found the root cause of it and added a fix to the installer (ref).

@bsalogga said in upgraded to Ubuntu 18.04.1 LTS:

Using desktop. Since you mentioned server version, I gave it a try, but added gnome desktop. Same error.

Was this a fresh clean install? Please provide the full logs again so we can have a look. It’s not helpful to just say “same error”.

Haha I know that’s why I’m completely dazed. I appreciate the help though, we’ve gained some insight as to how to build our images moving forward because of this.

@jfarmer said in Adding needed repository failed.:

Gotcha, okay thank you I will just use ubuntu

That wasn’t what I was saying. I guess you will run into the same problem with ubuntu 18.10! Use 18.04 for now (ubuntu or kubuntu) and you should be fine!

@AndrewG78 Ok, fixed in working branch (ref). Will be in the next release. Thanks again for reporting.

@kboutelle Any news on this?

@Sebastian-Roth
Lets say I deploy an image to host1 and join it to the domain. I want to image host2 next, so I thought maybe delete or just rename the host1 to host2 and start the deployment?

Looks like that worked, so I am just renaming the host since I’m using the same mac address

@Raymond-Bell Can you please post a picture of the host’s AD settings?

The log message says a user is logged in. Is that true? Did you try with and without a user being logged in?