@anon01013 Yes I agree, tell us what your dhcp servers are 10.0.0.8 and .9 . What is the manufacturer and version? Do you have access to change the configuration on these devices? Also please identify what is device 10.0.0.34.

Lets start with there, then we can chart the next steps.

BTW: your packet capture really tells us the story of what is going on with your network. Without the pcap it would be impossible to help you with FOG on your network.

@robo Good to know you have fixed this another way. Though I am still wondering if this is a reproducible issue and we might want to fix that in the code. On the other hand 1.2.0 is really old and I am not sure how many people still use it.

@plegrand Ops, I forgot to post here. This should be fixed in dev-branch now…

@Wayne-Workman Thanks heaps for mentioning this here! We should really update that wiki page to help people fix this. Newer versions of MySQL/MariaDB behave very different and we have changed the old way of using an empty DB password.

@Sebastian-Roth Machine was working fine after re-image and then started having performance issues mainly with Office and did Office repair. We are probably going to pull machine back and do another RAM test along with Lenovo diagnostics. Maybe just even replace RAM.

We do want to upgrade but we have been pretty swamped withe people working from home, so hopefully we can do this when things settle down 🙂

For anyone running into this. We’ve just pushed some changes to dev-branch and working-1.6 to make updating from Debian 9 to 10 easier. You should not be able to do this following the steps outlined here:

sudo -i apt-get update && apt-get upgrade apt-get dist-upgrade reboot sed -i 's/stretch/buster/g' /etc/apt/sources.list apt-get update && apt-get upgrade apt-get dist-upgrade reboot apt-get --purge autoremove cat /etc/debian_release cd fogproject git checkout dev-branch git pull cd bin ./installfog.sh

@marted Just want to keep this topic up as it might be very helpful for others. Not sure if you have time and access to systems right now though.

It is working now so with Bios set to Auto (legacy First) and the exit mode set to GRUB_FIRST_HDD it boots!!! I tried it with UEFI and it didn’t work which is why I went to auto.

Thanks for the help I appreciate it!

@dirtysoc Good news, this is a known issue with VirtualBox. Switch to ipxe.pxe boot file and the issue will be gone.

@Sebastian-Roth Hey Sebastian (and all other FOG devs and users out there) hope you and yours are staying safe and sound with whats going on in the world.

I’d forgotten about this post myself I confess - I’ve been busy trying go setup our entire workforce across several sites to work from home.

I know our service desk team would find this feature of great benefit as keeping reliable track of who was given a loaner laptop and when can be difficult without the right tool to do it. Excel sheets or even the ticketing system don’t manage this very well.

But given whats going on just now for everyone its very much on the distant, nice to have when the worlds in a better place list.

Stay safe everyone.

Kiweegie.

@dmoseley Any news on this?

@celikbilek Sorry for the very late reply. Must have gone unnoticed in a busy week.

I am fairly sure this error is caused by the VM having too little RAM. Make sure it has at least 1 GB and should run fine that way.

@juels said in Zyxel USG40 DHCP Pool:

Actually I don’t need dual NICs since the server is located in my department, so I can just access it when I need it.
I actually just want a FOG server and a 24port switch connected so I can connect my workstations for deployment, but what about dhcp then?

Well you do and you don’t. To install FOG the fog server needs to have internet access. BUT FOG gets cranky when you change its IP address after FOG is installed. So its best to have 2 network interfaces. One for management and internet access to install/upgrade FOG and one for imaging (if you want an isolated imaging network, not specifically required). If you have an isolated imaging network then you will need to configure the FOG server to be the dhcp server for the imaging network. Just understand the system’s imaged on the imaging network won’t have access to the rest of your network including the AD server if the target servers will connect to AD.

If you are concerned about network traffic AND as part of the imaging process your computers need to reach out of the isolated network you are better off not to use an isolated imaging network. You can modify your design a bit to plug the fog server and computers to be imaged on that 24 port switch, then plug that 24 port switch into your business network. All imaging will stay local to that 24 port switch but the clients that are imaged will be able to reach your business network servers and the internet if needed.

@george1421 We have 3 switches between the computers and the FOG-server.

The problem is resolved!

Our Solution:
The WebGUI from the switch showed the options in the IGMP Snooping as enabled, in the config-file some of the needed options were disabled. After enabling them in the file and uploading that we tried another mutlicast task.

The timeouts still are in the multicast.log.udpcast.x, but the task completes successfully.

@Tom-Elliott
Thank you for your attention.
I did not find a solution. In my business, we have chosen a different type of computer and everything is fine.
It’s just so that you can close or delete this topic which is useless in the end.
I need help elsewhere, but I have a new topic on this subject.
Thank you for this Fog product which is powerful, varied and effective !!!

@msi I am wondering why you have two IP addresses within the same subnet assigned to your FOG server? Any good reason to do this?

I also noticed that it is using enp0s31f6 IP address instead of p2p3 IP (192.168.1.230). is it normal since both IP’s are working when accessing the web console?

FOS uses the IP set as FOG_WEB_HOST (FOG Configuration) to call out to the FOG webserver. I suppose you have set 192.168.1.230 in that field, right? That shouldn’t matter from my point of view.

If you have checked all the passwords and resynced as described by George I may ask you to do a simple FTP test: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@beardedfool If you want to go secure boot there might be a way using your own custom Certificate Authority to roll out things. I haven’t done this myself and can’t give you any details. You’d need to talk to @Lee-Rowlett about this. First checkout his posts here: https://forums.fogproject.org/topic/13832/secureboot-issues

@Sharo It’s not that hard to get this back up. No need to reinstall just because of that. Shall we do a shared desktop session? See speak bubble in the top right corner.

@Sebastian-Roth Thx for your help, Sebatian!
I commented out line

chroot_local_user=YES

And now everything is just fine about my FOG installation.
MB it makes sense to add into FOG wiki - that vsftpd option is incompatible to FOG.

Now I need to find a way to chroot one user but not to chroot other, but it is definitely not a FOG problem. (And, it’s simple)

Thanks again.

Best regards!

@ddo Do you have some GPOs or other means of software deployment in place that would install 0.11.16 after 0.11.17 was installed?? I have done some intense testing on this back in the days when this came up and I am fairly sure it’s not FOG doing this by itself. But it is possible due to missing checks in the MSI installer if you use other means of deployment alongside.

Solution: Uninstall both, re-install one, maybe even use the latest release 0.11.19.