@Sebastian-Roth Yeah I was thinking the same thing. So now that tablet is booting reliably every time. I’ve moved to another one and it’s getting the errors again. This is totally a tablet-related issue and not a Fog related one.

@Dominique From what it reads in the other post the issue seems fixed in the working branch and I have done some minimal multicast test lately.

The FOG dev Team is not very strong at the moment as people have other important things on their private schedule and can’t put as much time into FOG. So I can’t promise you a date for the next release yet. But I think it’s not that far away.

If you use FOG in your company you might think about helping out in the FOG team to make things go a bit faster. One way to help is by answering questions in the forums. Or even get involved in coding and testing.

@george1421 thank you!!!

I don’t think the permissions are changing on a reboot (possible, but I have doubts). I can see the permissions may be changing (not staying the way you set) when you capture an image and only for the captured image.

Can you provide a screen shot of what the permissions are being changed to?

@Sebastian-Roth It is any option to clone the images in the storage server and not in the main server? If there is how it works? Thanks!!

@Nono Marking this solved as well now as I finally found the root cause of it and added a fix to the installer (ref).

@bsalogga said in upgraded to Ubuntu 18.04.1 LTS:

Using desktop. Since you mentioned server version, I gave it a try, but added gnome desktop. Same error.

Was this a fresh clean install? Please provide the full logs again so we can have a look. It’s not helpful to just say “same error”.

Haha I know that’s why I’m completely dazed. I appreciate the help though, we’ve gained some insight as to how to build our images moving forward because of this.

@jfarmer said in Adding needed repository failed.:

Gotcha, okay thank you I will just use ubuntu

That wasn’t what I was saying. I guess you will run into the same problem with ubuntu 18.10! Use 18.04 for now (ubuntu or kubuntu) and you should be fine!

@AndrewG78 Ok, fixed in working branch (ref). Will be in the next release. Thanks again for reporting.

@kboutelle Any news on this?

@Sebastian-Roth
Lets say I deploy an image to host1 and join it to the domain. I want to image host2 next, so I thought maybe delete or just rename the host1 to host2 and start the deployment?

Looks like that worked, so I am just renaming the host since I’m using the same mac address

@Raymond-Bell Can you please post a picture of the host’s AD settings?

The log message says a user is logged in. Is that true? Did you try with and without a user being logged in?

More info about this 🙂

Now we have configurated the client cheout time = 275 seconds. In September we had to increase it to 900, but after the changes we have setup it as I tell, 275 seconds.

This is a capture of goaccess tool:

0_1540379551079_goaccess_RHEL.png

The capture is after 6 minutes of activity, we can see that:
Total request: 8436 -> 23,5 req/sec
1378 visitors requested the /fog/service/getversion.php?NewServise&json page. This says that 1378 client are connected simultaneous.
1 visitor requested /fog/service/progress.php 114 times. This client is doing a download task.

Is necessary take in account that when a cleint is doing a dowload, capture or multicast task, this client asks or reports to the server his advance (yes is very pretty and cool see the progress bar) but this info has a price. The client reports his advance more or lees every three or four seconds, when you have one tasks is “pecata minuta”, but when you have 100 or more client doing download or cpature tasks is a problem, because the php server can not process all request simultaneous and is not only the php server, is the mysql server too.

For example in this capture of htop command (like atop or top):

0_1540380690148_Captura de pantalla de 2018-10-24 13-08-54.png

We can see that the vCores are busy, but not at 100%, the load is high, mysqld is using 221% of CPU. In this moment the server is proccessing only the FOG client requests of the computers, there is no any tasks (When the technicians send download, multicast or capture tasks, the server is burning … literally. I saw the load at 60 or more, the server could not attend the all request and refused them ), In this capture shows the activity of the two NUMA nodes clearly.

Node 0: 1, 2 ,3 and 4
Node 1: 5 ,6, 7 and 8

Where is working the mysqld proccess?

# ./numa-maps-summary.pl < /proc/1787/numa_maps N0 : 636053 ( 2.43 GB) N1 : 14336 ( 0.05 GB) active : 352378 ( 1.34 GB) anon : 649153 ( 2.48 GB) dirty : 649153 ( 2.48 GB) kernelpagesize_kB: 1016 ( 0.00 GB) mapmax : 480 ( 0.00 GB) mapped : 1276 ( 0.00 GB)

In the Node 0.

I downloaded a little script, i forgot from where, that shows the usage of RAM of each proccess:

# ./ps_mem.py Private + Shared = RAM used Program 4.0 KiB + 12.5 KiB = 16.5 KiB agetty 4.0 KiB + 15.0 KiB = 19.0 KiB mysqld_safe 4.0 KiB + 47.5 KiB = 51.5 KiB rpc.statd 4.0 KiB + 49.5 KiB = 53.5 KiB rpc.idmapd 4.0 KiB + 57.0 KiB = 61.0 KiB lvmetad 36.0 KiB + 31.0 KiB = 67.0 KiB atd 4.0 KiB + 73.5 KiB = 77.5 KiB VGAuthService 88.0 KiB + 32.0 KiB = 120.0 KiB rhsmcertd 92.0 KiB + 41.5 KiB = 133.5 KiB systemd-udevd 112.0 KiB + 22.5 KiB = 134.5 KiB sleep 88.0 KiB + 55.0 KiB = 143.0 KiB vsftpd 88.0 KiB + 65.0 KiB = 153.0 KiB gssproxy 148.0 KiB + 23.0 KiB = 171.0 KiB udp-sender 156.0 KiB + 30.0 KiB = 186.0 KiB crond 164.0 KiB + 30.0 KiB = 194.0 KiB in.tftpd 180.0 KiB + 20.0 KiB = 200.0 KiB numad 192.0 KiB + 16.0 KiB = 208.0 KiB rhnsd 128.0 KiB + 83.5 KiB = 211.5 KiB master 176.0 KiB + 35.5 KiB = 211.5 KiB xinetd 188.0 KiB + 54.5 KiB = 242.5 KiB auditd 232.0 KiB + 29.0 KiB = 261.0 KiB irqbalance 192.0 KiB + 88.5 KiB = 280.5 KiB qmgr 208.0 KiB + 87.0 KiB = 295.0 KiB sh 240.0 KiB + 109.5 KiB = 349.5 KiB rpcbind 588.0 KiB + 36.5 KiB = 624.5 KiB systemd-logind 668.0 KiB + 75.5 KiB = 743.5 KiB dbus-daemon 596.0 KiB + 311.5 KiB = 907.5 KiB polkitd 800.0 KiB + 175.5 KiB = 975.5 KiB vmtoolsd 916.0 KiB + 64.5 KiB = 980.5 KiB FOGpxe.sh 936.0 KiB + 135.0 KiB = 1.0 MiB dnsmasq 1.1 MiB + 386.0 KiB = 1.5 MiB NetworkManager 1.4 MiB + 413.5 KiB = 1.8 MiB pickup 2.0 MiB + 101.0 KiB = 2.1 MiB rpc.mountd 2.2 MiB + 67.5 KiB = 2.3 MiB systemd 2.6 MiB + 308.0 KiB = 2.9 MiB tuned 2.9 MiB + 355.5 KiB = 3.2 MiB mysql 2.7 MiB + 846.0 KiB = 3.5 MiB bash (6) 3.0 MiB + 822.5 KiB = 3.8 MiB FOGSnapinReplic (2) 3.1 MiB + 682.5 KiB = 3.8 MiB FOGImageReplica (2) 4.2 MiB + 80.0 KiB = 4.2 MiB nsrexecd 4.1 MiB + 718.5 KiB = 4.8 MiB FOGSnapinHash (2) 3.6 MiB + 1.3 MiB = 4.9 MiB sudo (3) 5.4 MiB + 1.0 MiB = 6.4 MiB FOGTaskSchedule (2) 7.5 MiB + 118.5 KiB = 7.6 MiB glusterfsd 1.9 MiB + 6.1 MiB = 8.0 MiB sshd (7) 2.5 MiB + 7.1 MiB = 9.5 MiB rsyslogd 10.3 MiB + 713.5 KiB = 11.0 MiB FOGImageSize (2) 7.0 MiB + 9.9 MiB = 16.9 MiB systemd-journald 21.5 MiB + 791.0 KiB = 22.2 MiB FOGPingHosts (2) 25.6 MiB + 1.0 MiB = 26.6 MiB FOGMulticastMan (2) 315.4 MiB + 14.6 MiB = 330.0 MiB php-fpm (51) 2.5 GiB + 289.0 KiB = 2.5 GiB mysqld 5.1 GiB + 14.9 MiB = 5.1 GiB httpd (12) --------------------------------- 8.0 GiB =================================

Any reason why you’re using raw image over something like resizable? Is there something special about the partitions or disk layout?

It also wouldn’t hurt to update FOG to the latest 🙂

@Quazz Nice explanation of the issues regarding the order of the partitions and the starting positions. I think that’s exactly what was going on. Since the actual usage of the original 1TB drive was only ~150GB, I went with a 240GB SSD which has always worked for me before. It gave me that “Seems like you are trying to restore to an empty disk…” error every time I tried to deploy that image to anything smaller than 2TB. Now that the two little partitions at the end of the original drive are gone, I recaptured it and it deployed just fine to a 240GB SSD.

@DJ Amazing we found this after such a long time of intense digging in packet dumps and testing. Thanks for posting the information on the switch so people can find this here in the forums.

I have though about this but don’t really see why we should “fix” NFS mount to use high source ports. I might be wrong here but from what I have seen in the packet dumps it seems like this is general behavior and changing this would need a fixup deep down in the NFS client libs code - something that we would need to maintain over a long time since I don’t see this change making it into the official code line. What do you think?

@dustindizzle11 Thanks for the heads up. Possibly I need to revisit what I said. Possibly there is a huge difference and it does make FOG run much faster in your case (and possibly for others as well). What I could think of is the php-fpm issue we still have in FOG 1.5.4 (see George’s post here). What is yours set to on Debian?

@CJR_ie Here you go. FOG detects your windows system partition to be fixed as well and therefore does not expand it on deployment. Edit the file d1.fixed_size_partitions by hand using a text editor and make it read

:1

Then schedule a new deploy task for your host and it should expand to the full SSD size properly.