Best posts made by Quazz

FOG uses the IP at many locations.

https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

Should contain the necessary steps for a proper migration, afaik.

Import is typically used during migration or to add new items. If it encounters a MAC that already exists in the database (associated to a host) it will complain because it has to be unique of course.

So, as far as I know, deleting the host list and importing the list is the only way, but you might want to hold on because I could be wrong.

@vinodjotshi Centos 7 is generally considered to be an excellent choice.

@verdierr So the image does work and it does have an entry in the UEFI then?

If that’s the case, it likely means the “EFI Exit Type” will have to be changed for that host/globally. You will have to try some different options, see which works for you.

Did you change the DHCP options to point to the new IP?

Go over https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG if you haven’t already. (don’t forget to also update /opt/fog/.fogsettings)

As for the nodes, I’m guessing that while the main server has got the correct information, the nodes themselves aren’t informed about the IP of the new server.

@pa_fog_man This error happens when you try to load a file designed for UEFI BIOS while you are booting in LEGACY BIOS.

Try bootfile ipxe.pxe instead.

Possibly related: https://forums.fogproject.org/topic/12059/fixparts-missing-1-5-4-win-10

I think rerunning the installer will download the newest binaries.

@ykarami You can get a different kernel straight from the WebGUI under Kernel Update. Just pick a 4.15 version. Make sure to get bit the x86 and x64 version to support all your clients.

4.16 kernel has a bug where erasing MBR/GPT tables takes several minutes (instead of seconds). Change kernel to 4.15 version to address that.

Partclone speed is determined by several factors: connection speed, target CPU, target storage system, target RAM, server storage system, server CPU, server RAM.

@snaggel https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP#Credentials_.2F_Passwords

You have to rerun the installer if you changed the .fogsettings file.

@derek-newbold What’s the output of

cat /images/STAFFIMAGE-WIN10/d1.fixed_size_partitions

cat /images/STAFFIMAGE-WIN10/d1.minimum.partitions

cat /images/STAFFIMAGE-WIN10/d1.partitions

@jackiejack What’s the difference with no. 4? Is that a newly created one?

Assuming yes: my guess is that your original image was compressed much in the way that your BasicImage is, setting the Image Manager to the right value will hopefully restore functionality for that image definition.

@tywyn Please fill in the variables

routeraddress='yourrouterip'
plainrouter='yourrouterip'
dnsaddress='yourdnsserver (possibly router)'
dnsbootimage='yourdnsserver (possibly router)'

in /opt/fog/.fogsettings

Assuming you want FOG to handle DHCP of course…

If not set

dodhcp='N'
bldhcp='0'

in /opt/fog/.fogsettings

You could potentially use postdownloadscripts instead for something like this.

@ek_n Can you share the script you’re using? We can’t really comment unless we know what you’re actually using.

It appears to be George’s script at a glance, but it could be an older version or modifications made to it that we don’t know about.

At any rate, for it to display that error message means that rsync encountered some kind of error. We don’t really know which one at this point, however.

Common problems: spaces in paths, permissions, firewalls (and network in general)

@ek_n Okay, good. So rsync fails at some point, we need to know why that is.

If you modify

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"

To something like

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch] with error code $?"

And then try again, it should now also give us the exit code of rsync which should tell us what goes wrong (though not necessarily why)

@Jonathan-Cool Ok, so the label should match now at the very least.

Did you recapture the image since implementing the latest sed?

If so, what do your d1 files look like for this image?

@Jonathan-Cool My “fuck this shit” solution atm is the following if you’d like to try it

Note that this is experimental and can cause issues on systems with odd labels so use at own risk… but

sed -i -e "s#\\[Rr\\]\\[Ee\\]\\[Ss\\]\\[Ee\\]\\[Rr\\]\\[Vv\\]\\[Ee\\]\\[Dd\\]#[Rr]*[Ss][Ee][Rr][Vv]#gi" /bin/fog.upload
sed -i -e "s#\\[Rr\\]\\[Ee\\]\\[Ss\\]\\[Ee\\]\\[Rr\\]\\[Vv\\]\\[Ee\\]\\[Dd\\]#[Rr]*[Ss][Ee][Rr][Vv]*#gi" /usr/share/fog/lib/funcs.sh

This seems to allow the regex to match at least, of course it’s far less precise now. Still don’t know why it hates é so much, but that seems to be the issue unfortunately.

Should also work on English and Dutch systems I think.

@george1421 I’ve seen that on the latest kernels on normal installs too, doesn’t seem to hurt anything afaik.

You can grab and drag the bottom right corner of it to resize it