Okay, I did something dumb, but learned something new…

In XUbuntu the password for the actual Linux user fog does not create/synchronize - This can be found under Storage Management, Default Member, Management Password - this should be the actual GUI login password for user fog in the Linux OS.

This password is randomly generated, and inserted in this field, and can be used to log in as user fog, although I’ve almost never need to do that. Instead of just changing the Linux login password to the randomly generated password found on the Web UI, Storage Management, Default Member, Management Password (which would have been smarter) I just changed this field to a common administrator password. I then made this common administrator password the actual login password for user fog on the Linux installation, and this issue is solved…

Just thought that I would post what happened,
D.L.

I probably should have described it better, but it sits at the “Starting to restore image screen” and the multicast task never actually begins, as described in this thread :
[url]http://fogproject.org/forum/threads/fog-1-1-0-multicast-sits-at-starting-to-restore-image-to-device-dev-sda1.10782/page-2#post-31993[/url]

Also (or as a result of this) in /opt/fog/log FOG version 1.1.2 does not create the multicast.udpcast.1.log (approximate file name) file, nor does it create any entries in the multicast.log file. Since I was confused by this I pulled up an old .32 installation - in .32 it has the same behavior, however it does make entries in the multicast.log to at least let you know what is going on:

[07-01-14 9:54:10 am] * Starting FOG Multicast Manager Service
[07-01-14 9:54:15 am] * [07-01-14 9:54:15 am] Checking for new tasks every 10 seconds.
[07-01-14 9:54:15 am] * [07-01-14 9:54:15 am] Starting service loop.
[07-01-14 9:54:15 am] | [07-01-14 9:54:15 am] Failed to connect to database server, will try again in next iteration.
[07-01-14 9:54:25 am] | [07-01-14 9:54:25 am] Failed to connect to database server, will try again in next iteration.
[07-01-14 9:54:35 am] | [07-01-14 9:54:35 am] Failed to connect to database server, will try again in next iteration.

And yeah, on one test installation I did create a password for the root user. I’ve checked in Config.class.php in /var/www/html/fog/lib/fog and it is correct and I’ve also verified it by running mysql -u root -p and entering the correct password. This test installation will not multicast, and gets stuck as described above. On another test installation I used all of the same settings, and I did not enter a SQL password on installation - this box will start multicast tasks…

Thanks Tom, you’re the man,
D.L.

Add to that a little,

It just says next-server as you were describing, and only specifies you to edit the Options 66 & 67 on a windows DHCP. I didn’t add the “this is what you need where” until 0.33b and forward.

Hello again

I just write here because I found another problem that didn’t allowed me to join computers to the Domain just in case anyone needs it.

In our University all the computers are on the same VLAN with many DHCP Servers and that made that sometimes, not always, the DHCP Client didn’t assign us the correct DNS to be able to join computers to our domain. Finally we decidided to filter via firewall that our clients only can get IP from our DHCP Server.

Thanks for giving me some light to solve our problem and for this nice product.

See you soon

[quote=“Meitar Ronen, post: 32024, member: 24536”]I’ve tried that…
No matter what I did I got the “Fatal Error” error…[/quote]

In the future, I recommend using VirtualBox and making a snapshot of your image before you sysprep. I know this doesn’t solve the problem at hand, and I don’t really have nay recommendations, but this should help with future endeavors.

If you you by chance need to sysprep again, you can revert the image to the previous snapshot and make adjustments without affecting the re-arm attempts. I hope this will help you to sort your problems later.

Did the resizable upload fix the issue?

If not are you opposed to pushing the image to a hard drive large enough AND WITHOUT BOOTING IT, editing the partition tables with a live gParted CD? This would allow use to manipulate the data into thinking it is smaller and possibly load it to another machine.

Here are those lines:
[CODE] if (ini_get(‘date.timezone’))
date_default_timezone_set(date_default_timezone_get());
else
date_default_timezone_set(‘UTC’);[/CODE]

Bios is set to UTC. Should I change something in the lines above?
[CODE]# hwclock --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1404282060 seconds after 1969
Last calibration done at 1404282060 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick…
…got clock tick
Time read from Hardware Clock: 2014/07/02 06:47:09
Hw clock time : 2014/07/02 06:47:09 = 1404283629 seconds since 1969
Wed 02 Jul 2014 09:47:09 AM EEST -0.688132 seconds
[/CODE]

PC time is 09:47 now.

I also have [CODE]date.timezone = “Europe/Athens”[/CODE]

Thank you!

Edit: With
[CODE] if (ini_get(‘date.timezone’))
date_default_timezone_set(date_default_timezone_get());
else
date_default_timezone_set(‘localtime’);[/CODE] times are correct (but why are times correct since my hardware clock is set to utc? ). Is this setting correct? Should I leave it like this?

[quote=“Tom Elliott, post: 31923, member: 7271”]svn 1983 should fix this for you.[/quote]
Indeed it does.

Just wanted to make sure that it was known.

Thanks.

[quote=“Jim Holcomb, post: 32006, member: 15162”]Buehler? Anyone? Guys, I have seen multiple posts on here about this issue. Do we have any idea what’s going on, or when a fix might be in order?[/quote]

There are two places you probably need to check.

When you install fog we set a random password for the linux side’s fog user.

This password is then the password that is supposed to be set for Storage Management and your relevant storage node. This can be changed on the linux side with a few commands:
[code]sudo passwd fog[/code]
Enter your password twice and remember it
Log into the FOG GUI and set this username and password in
Storage Management->All Storage Nodes-><YOUR STORAGENODE>->Management User and Management Password.

Then goto:
FOG Configuration (? Icon)->FOG Settings->TFTP Server->FOG_TFTP_FTP_USERNAME and FOG_TFTP_FTP_PASSWORD and set the same username/password pair.

Then test.

To make absolutely sure it’s not a permissions issue run:
[code]chown -R fog:root /tftpboot
chown -R fog:root /images
chmod -R 777 /images[/code]

Ok, that would be useful. I am just trying to get a few diagnostic and system tools up and running from network boot so we won’t need to be able read/write, but that could definitely come in handy on another project. Thanks for all your help.

Thanks so much for the info! So helpful! Do I follow the same steps to change the domain of an already registered host without imaging it again?

Thanks to everyone for their help and suggestions. I finally found the issue was dealing with the password setting in TFTP_FTP_PASSWORD and Storage management not matching. That was causing the issue with Image not showing properly. I did however, freshly install Fog 1.1.2 on Ubuntu 13.10 and so far so good. Thanks again for all the help everyone.

The files is not moved out of the dev folder and into its own folder. This was not a problem before I moved the /images folder into the /home folder. I have to do some more research tomorrow.

[quote=“Junkhacker, post: 31972, member: 21583”]update to 1.1.2[/quote]

AH okay, planning to do that later this afternoon.
Thanks for answering so many of my questions Junkhacker, its been a lot of help.

Many Thanks Tom

I had this problem when first setting up my server and I recall reading somewhere that when syspreping a machine, getting it ready for an image upload, it cannot be joined to the domain.
It has to be in a workgroup before running sysprep and uploading the image.
Since I started doing that, and making sure I entered my password correctly into FogCrypt, I haven’t had any problems with computers joining the domain.

Is this still true?

That’s a bit of a shame because it was neat to have it at your fingertips, ready to go on any machine, without having to install anything. But I also understand the downside of having to support it, code it into the web UI, etc.

Thanks for the help and for the information,
D.L.

I took the info here

[url]http://www.fogproject.org/wiki/index.php?title=WOL_Forwarding[/url] # WoL_Forwarding

It probably is.

I just realized one of my storage nodes were removed. Problem solved! I would delete the thread but I don’t see the option.