@Sebastian-Roth

No, unfortunately not. I was so busy these last few days that couldn’t make some time to experiment.
As I said, I just took over the management of our university networks and setting everything right will take some time.
But I have this issue on my to-do list because O am directly interested so I didn’t forget. I’ll get back here when I have news.

Done testing and I can confirm that AOMEI Backupper causes the problem.

I re-captured the image using dism, injected the install.wim into the install media, installed from it (essentially allowing Windows installer to re-create the EFI and MS reserved partitions) and now the restore works perfectly.

This error still appears:
https://photos.app.goo.gl/7UWrM7y2dNgELa8E9

But it has no negative impact on capture or restore.

So, the bottom line is that, from now on, I won’t capture any drives that were restored with AOMEI.

AOMEI is a very good free tool, I’ll still use it but only for images that go to the final user, not images that are captured for deployment.

@lwafflard @Tom-Elliott I just moved your posts to a new topic (https://forums.fogproject.org/topic/13039/multicast-udpcast-options) as I think it’s not related here and we better discuss this in a new thread.

@Sebastian-Roth
Yes, problem solved. The error is gone (sorry for the bad photo):
https://photos.app.goo.gl/ZhWkYuHLTwndZBZPA

Thanks!

@Sebastian-Roth Yep! That fixed it!

Thank you.

Andrei

Oh yes, I forgot about it. You recommended it to me the last time too. This time I’m going to save it on my deployment server desktop, to have it there for debugging.

I remembered something about FOGMulticastManager. Here is were I red about it.
Thanks again.

I’ll be back with feedback after my next deploy.

Never mind. It was an OS issue. Solved.

Not solved in 1.5.4. Problem is still there.

@Rhywden said in Error while installing FOG on Ubuntu 18.04:

I tried it on both Debian 8 and Ubuntu 18.04

We have automatic daily installer test running and there is no general issue with Debian or Ubuntu I can assure you.

Make sure that interface is up and has an IP! Run ip a s before running the installer and post output here.

Basically I want to set it up thus that it’s able to connect to an existing network over Wifi.

Ok then you need to configure both interfaces. First WLAN, get an IP and make sure you have internet access through that (ping -c ix.de). Then configure enp6s0 with a static IP and make sure the interface is UP!

ip a s
…
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
…

Hi!

Search for dhcp.conf or dhcp3.conf or something in /etc edit this file with nano or vi for each host you need an entry of this form:

host MYCOOLHOST {
hardware ethernet 00:00:00:00:00:00;
fixed-address 1.2.3.4;
}

Replace the 00:00:00:00:00:00 hosts MAC Replace 1.2.3.4 with your desired IP restart dhcp service or simply reboot

hth
xibeaga

@tom-elliott
Thank you for your reply. I thought about this too but I’m a bit uncomfortable with modifying the FOG code. Plus, it would break if I upgrade.
I got another idea yesterday, after writing this post. I was thinking about a script, that would run from cron, about every 10 minutes. It would check if udp-sender is running. If it isn’t, it would just exit. If it is, it would start monitoring the process and, when it finishes, it would launch my custom code.
This would work if udp-sender runs only during multicast. I suppose this is the case. I don’t see any reason for it to run otherwise.
How does this sound?

I’m back with some more info.
It looks like the problem was that udp-sender wasn’t started by the multicast manager service. If I restart the service, the udp-sender starts. I reboot the workstations and this time it starts deploying.

Yes, sure. I have to set up a machine for another one of our labs. I am going to do a capture with the “shutdown” option on, and one without it. Let’s see what happens.

Also, I am going to gather data during deployment. I have 2 more labs to deploy next week. Will post here as soon as I have it.

@andreiv I moved your last post to here since it’s a separate issue that you found: https://forums.fogproject.org/topic/11157/checking-schedule-shutdown-after-task-completion-causes-the-running-task-to-hang/2 Please follow it there.

@andreiv and is it fixed?

@sebastian-roth Great! Thanks.

@george1421 I’ll do some more testing Monday and get back with the results.

Thank you for your answers.

@Wayne-Workman

Of course. I’ll keep you updated with my progress.