With any luck your system will start uploading as expected.

And if you see any error along the way please take a picture with your smartphone and upload here. As Wayne would put it: A picture is worth a thousand words!!

As well please run lsblk and show us the output before starting the capture with fog command. From what I read between the lines this might be a special case of yet unknown major ids - which we can add without much effort as soon as we know.

@Developers @Moderators
I messaged him in chat and ping’d him here in the thread.

I’m thinking that forking threads isn’t good because people may bookmark the original thread they posted in. He might have came back to the original thread via a bookmark and seen that all his new posts were just gone…

I think that locking threads is a better option once the issue is solved, or we have looser customs about people addressing their next issue in their original thread. With the forums searching functionality, it may not be such a bad idea to just let folks keep going in the original thread. Also, another option is after forking, leave a link behind for them to find where the fork went to. Maybe that should be a feature in nodeBB? Auto-link to the fork, and maybe even send an email to the individual who’s posts were forked? Maybe even auto-message them too with the link and a short message of what happened.

@Hanz said:

Am I the only one that has this setup in such a large environment?

No I am sure we have others with similar large setups! As this has been around for a months without much new information and we solved most of the latest multicast issues with other users I am going to move this to the problem section. Please don’t get me wrong. I am very interested in finding out where the problem is with this. But as we don’t have others reporting a general multicast issue from 7088 upwards I kind of doubt this being a bug in FOG - although I might as well be wrong. Feel free to move it back if you can give us more solid information. For example full multicast.log as well as ps ax | grep -e udp -e FOG when partclone is waiting.

@Tom-Elliott
Thanks Tom, whatever you changed seems to have fixed things right up!

Reboot after is now working without causing tasks to be re-created when next checkin occurs.

You guys are awesome - did I mention that before?

@boeleke It’ll cause problems whenever you want to change anything with an image.

@Wayne-Workman You were right. I followed the link and followed its instructions and it is now pushing the image. Really appreciate the assistance.

GGQ

@herrpommesfrite For most, 60 is fine. Especially with the improvements that FOG Client 0.10.x brought.

If you have less than 1,000 computers, 60 is probably fine. In excess of that I’d probably recommend 3 or 5 minutes. Esp. when you get to around 15,000.

@phil_guy It’s not a linux or fog question. When the computer turns on, you usually hit F2 to enter the BIOS. On some HPs, it’s the Esc key, for Lenovos it’s usually the Enter key. Then just compare each item line for line on both the golden machine and target machine.

@GoodGuyQ My guess is you’re entering the wrong user/password. You can add a new user in the webgui to test that out.

Here is my quick image item for reference

set username foglogin set password foglogin params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param qihost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

With foglogin being a valid username and password

@Sam-Wennerlund for what it’s worth, i’m running the latest trunk on Ubuntu 12.04.5 LTS. it works fine.

@Junkhacker This looks promising… and it’s open source.

Regshot is an open-source (LGPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compare it with a second one - done after doing system changes or installing a new software product.
https://sourceforge.net/projects/regshot/

This appears to be a networking related question vs a question about the application.

Previous poster is correct. Basically you would want to enable multicast on your layer 2 devices and perhaps on your layer 3. In general, you want to control where the multicast goes, so enabling is not the end of the story.

Removing the hook sorted it nicely. Thanks for that.

@boeleke Those are the fog server’s CA and private certificate for your specific server. They must remain in place for anything concerning the fog client to work. You should not bother them to create a snapin.

thanks guys for replay i was really busy to follow up the post
i will provide a photo soon as i restart the server next time

You may also find this helpful: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

@Cammy-Webster It’s fine. Part of being a moderator is being able to link to obscure threads 🙂

@JGeear There isn’t a call to shutdown the interface. The SIGTERM, Shutting down is the message that is saying it is shutting down.

Trinity rescue CD 3.4 : NOT WORKING : kernel panic

kernel http://IP-FOG/fog/service/ipxe/trinity3.4/kernel.trk || read void initrd http://IP-FOG/fog/service/ipxe/trinity3.4/initrd.trk || read void imgargs initrd.trk ramdisk_size=65536 root=/dev/nfs vga=788 trknfs=IP-FOG:/home/tftpboot/trinity3.4/ ip=dhcp splash=verbose pci=conf1 trkmenu timeout 100 || read void boot || read void

UDF-fs : No partition found(1)
No filesystem could mount root , tried ext3 ext2 ext4 cramfs squashfs vfat …
kernel panic - not syncing : VFS: Unable to mount root fs on unknown-block(8,1)