Posts made by dolf

Yes I am sysprepping. If I deploy the same image to a PC that was in my FOG db before, it works. The new PCs are also identical hardware to the ones we already had (Dell Optiplex 990 USFF). If I deploy to one of the new PCs, it doesn’t join the domain. One some of them (about 10%, at random) the hostname changes, but it never joins the domain.

I’ve been running around, joining them manually today because it was urgent…

I don’t know what “early hostname changer” is.

I’m having the same problem as this: HostNameChanger says hostname is correct

Running Version 1.3.0-RC-1
SVN Revision: 5936

Ubuntu 14.04

I added a bunch of new clients and imaged them last night. Identical hardware and images to what I already have in the lab. The log says:

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 2016/07/14 08:19 PM Client-Info Client Version: 0.11.3
 2016/07/14 08:19 PM Client-Info Client OS:      Windows
 2016/07/14 08:19 PM Client-Info Server Version: 8595
 2016/07/14 08:19 PM Middleware::Response Success
 2016/07/14 08:19 PM HostnameChanger Checking Hostname
 2016/07/14 08:19 PM HostnameChanger Hostname is correct
------------------------------------------------------------------------------

But the hostname stays something like username-randomnumber.

Output of http://lab2-server.ee.sun.ac.za/fog/service/ipxe/boot.php?mac=problematicmac:

#!ipxe
set fog-ip my.fog.server.ip
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
sanboot --no-describe --drive 0x80

I can log in as the local user and join the domain manually.

Great! I was about to say that the same goes for group unicasts. WOL by the FOG Scheduler service should be fine.

Thanks! It flies now.

FOG version 8595
Ubuntu 14.04
Accessing FOG web interface from Google Chrome 51.0.2704.106 m

When creating a multicast task using the web interface, the next page only loads after all of the PCs have turned on (they so so sequentially - it’s quite a beautiful thing to see). During that time, the browser shows “loading”. Now when I do this with many (50+) PCs, either the browser or PHP (unsure) becomes impatient at some point and terminates the script prematurely. The result is:

• the multicast task is created, and waits for 50 hosts to join
• n < 50 tasks are created for hosts to join the multicast task
• m < n PCs have actually turned on (because of WOL)

Maybe this is due to PHP script timeout? Maybe it is due to the browser deciding that the server must be dead if it doesn’t respond in time? In either case, it’s not scalable. I would like to task ALL my hosts at once.

It would be better if there were a background process to create the tasks, so that the next page can load while that continues.

@Tom-Elliott you genius

Yes, I was copying files which I captured manually. Your three suggestions, to

• temporarily disable replication,
• not create the image definition,
  or
• use the dev folder

all work, and I’m not sure why I didn’t think of that… #facepalm

@Wayne-Workman That sounds like a feature request… Having a deploy folder on SSD. Not something I would need though. We’re drifting off topic

Oh and by upload I meant capture. Stuck in the old terminology…

@Wayne-Workman I didn’t, I’m just speculating. One possible use case might be if you have an SSD for dev to upload faster and a big slow HDD for the long term storage.

@Tom-Elliott I was writing on the master only. The problem is that lftp should wait until I’m done writing before it sends the file to the slaves.

Sure enough, when I restarted FOGImageReplicator, lftp decided that the file (the one it tried to mirror while I was writing to it) is no good, promptly deleting it on all the slaves and sending it again. This is not a bad outcome. But it means we sent unnecessary traffic before.

I’ve noticed that the FOGImageReplicator service calls lftp, which mirrors the /images folder from one node to another. However, it also tries to sync files that are still being written to. I’m not sure how smart lftp is, but it will waste traffic at best, or copy incorrectly at worst.

This is a minor issue, since there is the dev folder, and if the last step is always to move the image being worked on from dev to dev/.., it happens so quickly that lftp would (AFAIK) not start copying before it arrives.

Oh, wait… if for some reason /images/dev and /images are not on the same filesystem, mv is not atomic, and lftp will try to transfer incomplete files.

But maybe lftp is smart enough to account for this? I couldn’t find it online. I did, however, find a way to exclude files with a modification time of less than a few minutes ago: http://serverfault.com/a/693787/301389

Or does it? I just started from scratch on a new image with a new HDD, and I’m having the same problem… MFT gets corrupted. I’ll do some more thorough tests when I have time.

Sorry, since I did away with the second storage group, it’s hard to test this. I’ll create a second storage group and test this when I have more time. For now, I’m pushing a deadline to get the lab deployed before Monday.

Nope. I’ll check it out. But piping stuff around in linux is simple and effective.

Yep, it works now.

Just for fun: This is the command I use to pull random data from a remote host (and monitor the speed):

$ ssh user@remote "cat /dev/urandom" | pv > /dev/null

Great! Sorry for the re-post then.

Have you tried it with a different mechanical HDD? I’ve had hard drives fail right after chkdsk /F /V /R /X reported that there are no errors or bad sectors.

No, it’s more simple than that: I just moved a physical HDD from one box to another, without changing any settings. The MAC is determined by the physical NIC in the Dell PC.

However, I’m also seeing random PCs in my lab starting up at random times, so I suspect I’m not the only one sending WOLs on this network. These PCs were migrated from another faculty’s lab to the one I’m managing with FOG. I don’t know what they are using. Maybe they are still sending WOLs to the MACs they had long ago…

This is very low priority, and probably not a FOG issue. I’m just curious …

I’ve seen both of these things happen in recent trunks. It depends whether you

1. “Delete all selected items”
   or
2. Edit the image and click “delete”

When I scp from lab2-server to Gleeble, it still shows an orange line instead of a blue one. When I copy something from gleeble to another PC, it shows that lab2-server is transmitting (the blue spike):

Maybe toe transmit/receive is not swapped, but rather the server names?