@_mateo said:

Since I’ve taken so much of your time I’d like to contribute, if I can!

We always need people to answer basic questions here on the forums for newbies. We always need people to update the Wiki, add hardware reported to the hardware lists, to convert tutorials posted in the forums into polished Wiki articles. to add common problems to the wiki based on things posted in the forums. There are lots of ways to contribute.

The easiest way is to maybe once a day (mornings are best) just quickly browse through the recent threads and see if there are any you know the answers to. Probably 30% to 40% of things posted here are newbie questions.

@Wayne-Workman Yeah I ended up doing that, I guess as long as my p2ving is what made it angry then there’s nothing to worry about.

I did just setup something like this last friday. Its documented in the first link Wayne posted (it did take a bit of noodling to figure this one out). The key/trick is to use a bind-mount (like a super-duper symbolic link). You can’t use symbolic links because NFS can’t share them and/or NFS doesn’t have the concept of share aliases. The bind-mounts NFS can follow and share. If you use the bind mount then you don’t have to do anything FOG since fog still sees the /images folder, the OS redirects access to the mounted directory.

The only caveat I have to say about my setup is that I have not uploaded an image yet to this setup. I can affirm that the download works as advertised.

@glienhard Another option would be, when you see that error, to run:

git reset --hard

@Wayne-Workman
Yes, I tried both trunk and no trunk version.

The trunk version was more broken with my clients than the 1.2.0. Image upload would show the size of full disk (deploying to a disk with smaller total size would not work.). Normal deployment did not work at all either, it would only fail when starting.

@george1421 said:

There were a couple references to this “with a partition scheme suitable for EFI”. Which makes me wonder if there has to be something done special with the init fs to make it efi suitable??

Interesting. Haven’t thought about this before. Well we do have FOG (FOS) running on several different UEFI machines. So I am certain that it works with those inits Tom is building. AFAIK there is no partition scheme involved. initrd is just a compressed image file - no MBR, no partitions, no GPT …

OK with the linux comfort level much higher than the typical FOG admin has and your (eventual) intended scope I would say that FOG would work well for you (lin and win). The only concern I have right now is" Does the FOG OS (FOS) kernel support your server hardware. This support is required for imaging only. The issues I can see is support for the NIC(s) and any raid controllers used during the imaging process. The FOS image has support for the majority of the desktop hardware, servers tend to have specialized NIC and disk configurations. Once the OS is loaded then the client OS is your issue.

If you have locations/servers behind slow links (such as a site to site mpls/vpn) you may want to deploy storage nodes at those locations. Those storage nodes will contain the deployment image and the ipxe boot files for that location. The deployment is still managed from your master FOG server, but the deployment happens remotely. If you use the location plugin for FOG you can set up locations for each remote site, then assign storage nodes and client systems to those locations. This ensures a client will not try to image across your site to site vpn link.

So what to do next? I would spin up a test fog master server. The stable FOG release is about 2 years old. Newer hardware may not be supported with the stock kernels. I would update the kernels to the latest that are supported under 1.2.0 stable (I think they are 3.19.3) to ensure your hardware is supported. Ensure your proposed target hardware can pxe boot into the fog ipxe menu. Then run the compatibility test. This will tell you right away if FOG is a viable option.

If your target computers don’t boot well, I would then recommend you upgrade to the trunk release ( 1.3.0 beta). This image is still in beta state, and is a bit more like a 2.0 release than a minor upgrade. This environment has many more options than the 1.2.0 stable release. The developers are working hard to get the 1.3.0 solid. Right now they are working hard on EFI support which has delayed the stable release a bit.

So what is the actual error you see after this. From what I see on the picture everything seams fine. Don’t see an error here. We need the error to be able to help. Or a PCAP file! 😄

Also,

From the image page, you can go to the image you want, and go to membership. Select all the hosts you want in that image assignment and add those hosts. A host can only be assigned to one image at a time, so all will automatically be “mass changed” as you described it.

I think this might have something to do with it:
https://forums.fogproject.org/topic/6626/quick-image-accepts-blank-password-for-users-6207

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