@pederskz I marked it for you. Glad you have it going now.

Yes hostname is correct 🙂
I just have to test my snapin deployment

Ok so I have the same problem than my old server, some snapins failed to deploy due to “hash does not match”
This is a known issue for me, some snapins, I don’t know why simply doesn’t download correctly (my .exe is 1KB instead of 75203KB in server)

It seems something wrong in the settings, 3 snapins download at 1KB

BTW thanks Joe and Tom for you help, I’ll try to find out why my snapins doesn’t download correctly (all are 1ko in C:\Program Files (x86)\FOG\tmp with hash does not match in fog.log)

@richard.cervelle I would suggest you try it. Here’s an article on it, includes a video explaining how to set it up at a basic level and how it works: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

Issue is resolved or us

Looks like our WOL Broadcast Management settings were all wiped. Adding our Broadcast IP back and it worked.

It works,

Thank you so much

Do you think my snapin problem (post from 5hours ago) is link to this one ?

Hey

I found out where my error came from, here are the settings:

Follow the tutorial of @george1421
https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node/16

On the Fog Web server

0_1493113426231_Capture d’écran 2017-04-25 à 11.37.44.png

On Nas Synology, here is the NFS configuration on all the files /volume1/images /volume1/tftpboot /volume1/snapins so that all posts find sharing Thanks @hfredh

0_1493113614033_Capture d’écran 2017-04-25 à 10.39.05.png

Thanks to all
One can pass the subject in solved

I keep you informed if I can deploy with this method normally there should be no problem

@+

@Tom-Elliott said in Could not boot:

ing your storage node IP to

I had the same problem starting from 1.4.0-RC-2 . Added another storage node with the fog-server ip and some fantasy user/password -> works

@FeasiblePear Have your admin update to the 1.4.0RC release over 1.3.5 stable. 1.3.5 stable had a bug with resizing hard drives under certain conditions. 1.4.0RC1 addressed this issue. I think the devs are up to 1.4.0RC8 which address a few other bugs from 1.3.5 stable. Its well worth the update to the current RC release.

@tom.langenfeld I also agree it sounds like an IP address conflict with the FOG server.

Once you determine one way or the other on the IP address conflict I want you to do the following from the FOG server linux console.

(you may need to install the traceroute utility if its not installed by default).
Run a traceroute from the FOG server to a device on this remote vlan where you are getting the tftp timeout. If you have success on a traceroute back to the remote vlan then…

From a windows computer on that remote vlan, see if you can ping the fog server IP address.

If success then install the tftp client program on the windows computer from Program and Features. See if you can tftp get undionly.kpxe from the FOG server.

If success then you must confirm that you have dhcp options 66 and 67 set correctly for this client vlan.

@wanderson This will assist you: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@UWPVIOLATOR What I would do is run the maintenance commands, and then I would open up notepad and change all the maintenance commands into select statements. I’d then ask the team to start noting what they do, when they do it concerning fog. Then I’d just start running those select statements every 15 minutes to every half hour - and when the bad row pops up, I’d ask around and see what people did during that time. I’d also look into the history table for things there during the same time. I’d look in the apache error log for something during that time. Even if you find no errors in these logs, it’s worthwhile to see what IS in there during that time, those can be clues. Then - I would begin the tedious task of reproducing the problem and identifying the single thing that is causing it. Reproducing the problem is a lot of educated guesswork based on what you think is causing the problem. If at the time the issue happens for example, someone was registering and imaging a new system - You’d have to test registering by itself - then imaging - using the same image they did - and possibly even in debug mode to identify the single thing that is doing it. Just as example. What I’m expecting though is it’s being caused by something being done in the web GUI - you guys just need to figure out what that thing is - and narrow in on it by separating out variables & unknowns and testing individual things. Example - I don’t know if my application isn’t working or if my antivirus is blocking it. Well, uninstall the AV and try. You have to isolate. And to begin isolating, you have to have a general idea of what you’re isolating.

@Wayne-Workman thanks! solves the problem

Thanks EVERYONE! this should give me enough information on getting 700+ updated and moved over to the correct OU although I didn’t really wanna start mucking around with the DB but I’ll take a snapshot before doing so. Thanks!

@Tom-Elliott Thanks Tom, the update resolved the issue. I upgraded to 1.4.0-RC7.

@Warget that is beyond the scope of the fog forums. You could try posting on spiceworks.

@george1421 Got it, thank you again!

@seb38300 Correct it may ask you for authentication. The user ID and password will be ones that you setup in the fog gui under User Management.

@Frank said in Error "Undefined index: pass" in capture:

@Wayne-Workman I’ve followed the troubleshooting guide in case of “Update database…failed” and tftpd passwords are OK.
The error happens in fog.imgcomplete script, in “curl” line. If I do the curl at command prompt I get this:

curl -ks --data ‘mac=98:90:96:d8:29:4d&type=up&osid=9’ http://<ip_of_main_fog_server>/fog/service/Post_Stage2.php

Type: 8, File: /var/www/html/fog/lib/fog/fogbase.class.php, Line: 837, Message: Undefined index: pass. Host: <storage_node_ip>, Username:fog

SOLVED!! So simple as a firewall rule! Shame on me.
Fog main server was unable to contact client to port 21.
What had made me crazy was log messages, which seemed to have no sense.
Thanks anyway.

@Tom-Elliott said in Single disk, resizable - failed to set disk guid:

@dylan123 So the issue, if you’d like it fixed for now (I’ll relook at this code though).

Can you open the file, and add the /dev/sda components?

In other words make the file read as:

/dev/nvme0n1 dcfabb9e-4507-415e-b9a9-e437017df63b /dev/nvme0n1p1 1:0C86C94F86C939CA 1:9c90a090-937d-4c9b-9a25-0381f463b590 /dev/nvme0n1p2 2:6CCA-8BF5 2:7e69ccb9-b499-4bf5-8528-293b71e42988 3:2de320a9-99b6-4191-aeeb-1c15e96fae1d /dev/nvme0n1p4 4:CC34D93B34D9296A 4:b1911679-d848-4e8b-82fc-98616b55452e

Hey @Tom Elliott, tried the above code and that worked perfectly!

Will download the new init’s as suggested and see if that works also, thanks.

@george1421 Thank you for the quick reply! As a follow up, I managed to update to 1.4.0 RC6 and was then able to deploy an older image without trouble (single disk - resizeable). It completed, and resized successfully. Take care!