Best posts made by Trevelyan

Random other suggestion; check /tftpboot folder, see if undionly.0 exists. If it doesn’t, try this as root:

cd /tftpboot

sudo su

ln -r -s undionly.kpxe undionly.0

Well it broke it but it stopped the “thing”!

Do a cat /etc/passwd and see if the output looks like this:

fog:x:1001:1001::/home/fog:

If it does, there is no shell associated with the user. As root, try the following:

chsh -s /bin/bash fog

Let me know if that fixes it for you!

After a day of using it, I actually really like it - so long as you can find a way to redirect old forum links for anyone who might have hardlinked to threads here!

What does the forum use now?

Yeah so in the “List all images” area, you still have to make them again. They exist, they’re taking up space, but you still have to have that image entry in FOG (it doesn’t automatically just pick up things dumped in the /images/ folder, for example).

Just make a new entry, give it whatever name you want, and then make sure you give it the right file path (as well as what OS you use and what type of disk it is - for example multiple partition, single disk)

It won’t use any rearms at all unless you actually run sysprep. If you do run sysprep and you don’t want it to rearm, just include Skiprearm set to 1 in your unattend file.

Here’s a bit of my unattend file so you can see where the SkipRearm bit should be:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:sc....
    <settings pass="generalize">
        <component name="Microsoft-Windows-Security-SPP" .....
            <SkipRearm>1</SkipRearm>
        </component>
    </settings>

As for not being activated - I found it annoying and activated in the end, since you have something like 3 rearms you can use. But I think it at least affects Windows updates so if you wanted to include those on your image, then activate once if you can.

@Wayne-Workman

or Link the file

sudo ln -s -r undionly.kpxe undionly.0

But that shouldn’t be the problem, since you’re explicitly stating the file you want via TFTP. I’ll go with the idea its a permissions problem on the Windows side.

Running as a regular user:

C:\Users\Trevelyan>cd C:\Windows\System32

C:\Windows\System32>tftp 10.1.6.1 get undionly.kpxe
tftp: can't write to local file 'undionly.kpxe'

Running as admin:

C:\Windows\system32>tftp 10.1.6.1 get undionly.kpxe
Transfer successful: 103273 bytes in 1 second(s), 103273 bytes/s

I’ve noticed that first thing in the morning, our server is fine. Its only when PCs start powering up that we see issues - but it isn’t even a hundred that cause it. Just loads and loads of high-CPU hogging apache2 instances that never seem to end.

For the record - all of these are new clients (we have no PCs running the old client anymore)

@Wayne-Workman

Same guy

If you’ve changed your IP address, there are a number of files you need to change.

• /var/www/fog/lib/fog/Config.class.php
• use "grep -r <old fog server ip> /var/www/fog/lib/fog/ " and find any references you missed there
• /tftpboot/default.ipxe
• /etc/hosts
• /etc/dnsmasq.d/ltsp.conf
• /etc/network/interfaces

Full list is here

https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

Actually, I remember when I first started using FOG we had duplicate MAC issues. This was caused because I had “approved” pending MAC addresses - which included VMWare virtual networking adapters. These were all identical, since I had installed VMware Workstation on a base image and it had retained the same address on every PC.

@Dragnous said:

HP 215 G1

Is it possible to disable IPv6 PXE booting in bios?

I remember on DQ87PG/Viglen 800s boards, we had to change about 150 PCs to booting from UEFI PXE to legacy OPROM. Landesk and FOG both had problems with this - so maybe its a similar kind of thing.

Note: all hosts are using the legacy client

As started here, I have noticed two bugs here: the first is that “approving” a pending mac address simply makes it disappear from the list of pending macs (still present as of 3587).

The second is potentially more devastating. I could be wrong in my assumptions here but I think its pretty sound. What seems to happen is, is that MAC addresses are now being associated with a host even if they are only pending.

This is a huge problem if you use virtual adapters. In my situation, virtual mac addresses get generated as part of the VMWare Workstation installation, which ends up being installed on ~500 PCs in our labs (IE 500 pcs will have the same two virtual mac addresses). This hasn’t ever been a problem and previously (1.2 and below), these cloned virtual addresses became “Pending” addresses. Simply ignoring their existence is fine and does nothing.

Now, however, only one host has those mac addresses as “Pending”. But all other hosts who aren’t registered on FOG, or who have a problem initially retreiving their physical mac address (happens with some hardware configurations it seems), will check in thinking that they are that one host (because they have the same virtual address, which is still a mac address, and its associated with a host already. Despite being pending)

If I remove those two virtual macs from being associated with that single host, another host will then associate itself with the virtual addresses next time it checks in to FOG. All the other machines that associated themselves with that single host will rename themselves to that host, which then means they’re unable to logon to the domain here.

• If a machine is not registered on FOG, it will now add its MAC address to the list of pending addresses for the host to which it has renamed itself to.
• If a machine is registered on FOG, but whose MAC doesn’t show up on the post string when checking in to FOG (happens when the FOG service starts too quickly on our SSD machines), it won’t add its MAC to the list for that host, but it will still associate itself with it.

For now, I’ve created a single host called “BROKEN” and turned all services off and given it these two virtual macs explicitly. But this is still a bad situation to be in.

The final issue is that the MAC address filter in the settings doesn’t seem to be listened to. Hosts can still exist and be registered and pending macs will still enter the list even if they start with the same string as listed in the FOG registration settings.

So this comes down to three bugs in one:

• Pending macs are still used
• Approving pending macs just makes them disappear
• Host filter doesn’t work

If anyone has any questions or feedback, or corrections, please post

Cheers guys!

Everything seems happy now!

Thanks

PS - Hosts and Users report shows up as error 500 - links to (fog server…) /node=report&sub=file&f=SG9zdHMgYW5kIFVzZXJzLnBocA==