@greenfog The image is not a resizable image type. If it was taken from a computer with a HDD capacity larger than 128GB (which it likely was), then that’s why the image download is failing.

@Tom-Elliott
Works perfectly now! Thank you very much!

@apathetic_admin https://forums.fogproject.org/topic/6603/opt-fog-snapins-disappearing/18#

I’ve added @Wayne-Workman’s code and actually (I think) improved upon the snapins creations/edits altogether. Hopefully this is properly solved. Thanks for the patience.

@Wayne-Workman

I think so, if any new info or issues related comes up I’ll post.

@Wayne-Workman The thing I noticed with the installer script is that it will skip over the database updates if there are already settings. That installer needs to replace the settings in the database as well as update the exports file.

Without configuring the p255p1 and em1 the network ainºt working.(as i have no connection to server)

It works like this :

auto em1 iface em1 inet manual bond-master bond0 bond-primary em1 auto p255p1 iface p255p1 inet manual bond-master bond0 auto bond0 iface bond0 inet static bond-slaves em1 p255p1 bond-mode 2 bond-miimon 100 address 192.168.137.51 netmask 255.255.255.0 gateway 192.168.137.1``` and this is what i get : ```root@fog1:~# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: p255p1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether e8:39:35:63:fa:bb brd ff:ff:ff:ff:ff:ff 3: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000 link/ether e8:39:35:63:fa:bb brd ff:ff:ff:ff:ff:ff 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether e8:39:35:63:fa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.137.51/24 brd 192.168.137.255 scope global bond0 valid_lft forever preferred_lft forever inet6 fe80::ea39:35ff:fe63:fabb/64 scope link tentative dadfailed valid_lft forever preferred_lft forever```

@Wayne-Workman I’ve checked and asked my boss, who built our system from the ground up, and we are not behind a proxy.

@Wayne-Workman
The issue i was having with windows storage nodes is likely a permissions issue, but the first thing we tried was setting the permissions across the board to full control. Good luck figuring it out. It was so annoying, we swapped the storage node for a linux machine.

@Wayne-Workman Haha! Oddly enough, I’ve only ever been taught to navigate and edit .conf files with Vi. I was following a FOG tutorial and was thinking, “What’s this ‘sudo nano’ crap all about?”

@Sebastian-Roth Gotcha! Thanks for your help. Still no word on if there’s a rogue AP/dhcp service running somewhere. I’ll keep you posted.

P.S. I have a community oriented question for you guys. Is it okay to keep posting in the same thread with each issue that comes up as I go along? I figure someone looking for a TFTP or PXE error will stumble across this, but we’ve covered a few different topics. I guess the search engine will be good enough to find keywords, I’m mostly just curious!

@Tom-Elliott I sent you a msg as well, the error I posted is no longer present after cleaning mutlicast “stuff” from fog server and rebooting, but now I get to partclone screen and it hangs.

Multicast log from gui

[02-03-16 9:30:29 am] | Task (17) Multi-Cast Task is already running PID 2461 [02-03-16 9:30:39 am] | 0 tasks to be cleaned

Service Master log

[02-03-16 9:26:47 am] service_signal_handler (30080) exiting. [02-03-16 9:26:48 am] service_signal_handler (29843) received signal 2. [02-03-16 9:26:48 am] service_signal_handler (29843) killing child (29861). [02-03-16 9:26:48 am] service_signal_handler (29843) exiting. [02-03-16 9:27:58 am] FOGImageReplicator Start [02-03-16 9:27:58 am] FOGMulticastManager Start [02-03-16 9:27:58 am] FOGImageReplicator Start [02-03-16 9:27:58 am] FOGTaskScheduler Start [02-03-16 9:27:58 am] FOGPingHosts Start [02-03-16 9:27:58 am] FOGImageReplicator fork()ed child process (1356). [02-03-16 9:27:58 am] FOGMulticastManager fork()ed child process (1357). [02-03-16 9:27:58 am] FOGImageReplicator fork()ed child process (1355). [02-03-16 9:27:58 am] FOGImageReplicator child process (1356) is running. [02-03-16 9:27:58 am] FOGImageReplicator child process (1355) is running. [02-03-16 9:27:58 am] FOGTaskScheduler child process (1354) is running. [02-03-16 9:27:58 am] FOGPingHosts fork()ed child process (1358). [02-03-16 9:27:58 am] FOGTaskScheduler fork()ed child process (1354). [02-03-16 9:27:58 am] FOGPingHosts child process (1358) is running. [02-03-16 9:27:58 am] FOGMulticastManager child process (1357) is running.

I rebooted between 9:26 and 9:27 as you can see from log.

This is tasked to multicast from remote storage node I might add. Have not tested multicast from server subnet yet, and I’m running trunk per the 6177.

I’d also like to add that after trying to run a multicast the server shows “This is not the master storage node” under multicast log, until I completely clean mysql of multicastAssoc, MulticastgroupAssoc, and task type=8 followed by a reboot, then I get the logs as shown above working correctly.

Thank you very much. It works like a charm 🙂

Thank you all.
I will update in case resolved.
Take care!

@Wayne-Workman Yeah, that’s why I’m trying to work out my issues now - this is a fresh upgrade on a new server (installed FOG on new hardware, then moved my snapins and database over). Only place I have the new client installed is on a new image I’m working on, so this is the time to get this worked out. Next I have to try and figure out why the old FOG clients aren’t auto-upgrading like I would have thought they would.

Some how I feel a bit unsatisfied, but solving thread.

@max.maeuschen

Does your notebook currently have an operating system installed?

Did you replace the hard drive in this unit, or is the hard drive blank by chance?

@Barry-Tabrah I don’t understand the issue.

Bandwidth graph isn’t working? This should not be impacting functionality in any regard.

Just a guess, does the disk space show? What about active tasks, does it refresh every 5 seconds properly?

Can you upgrade? FOG 1.2.0 and earlier did not have any controls in place to tell the dashboard page what interface to use. However, as you stated, you pushed through to enforce the settings was for ens32, but where did you make that change?

@Tom-Elliott
I have to correct - sometimes it works and sometimes not. So it’s stilll not working. Will wait and test.

@Wayne-Workman

Also, in the file “dnsmasq.conf” at the end of the file uncomment the conf-dir.

It should look like this:

# Include another lot of configuration options. #conf-file=/etc/dnsmasq.more.conf conf-dir=/etc/dnsmasq.d

If you wanted to try the esxi route
I found this info on unRaid NFS
http://lime-technology.com/wiki/index.php/FAQ#How_do_I_configure_NFS_mounts.3F

Then in vcenter for esxi add a datastore with the network file system option
give esxi the unraid servers nfs address
tell it where to mount it on esxi
and give the datastore a name, like images

Then on your fog vm, shutdown, edit settings, and then add a new virtual disk from that data store.
Then mount that as /images in your /etc/fstab. You might have to format it before you can mount it with mkfs ext4 or something of that sort.

If that overview isn’t helpful and you want to try this method, I’ll test it out a little and document the process more thoroughly when I get a chance.

1.3.0 is really the trunk/“beta” version currently. It isn’t quite yet to release. Granted if every stable trunk was released as a final version, we would be at FOG 5782.2.0 by now.
@Tom-Elliott has been working on gpt partitions recently trying to get it perfect. Give the trunk a go

https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk