Posts made by Tom Elliott

@Eliseu WEll your bootserver is coming from 192.168.0.17, not 192.168.0.16 which I think is part of the problem, there’s nothing handing out the boot files from your fogserver

@PatrickL Are there any other utilities running on your server?

What version of PHP are you using?

Is your FOG Server exposed to the open internet?

@Eliseu Is 192.168.0.17 your actual fog server?

@george1421 They definitely are it even says:
Windows 10 [Executando] - Oracle VM VirtualBox

@adam1972 The AD setting isn’t general. Basically it’s enforcing the reboot happens to change the hostname and/or complete joining the domain.

I think since there’s multiple points of hostname changing this isn’t working correctly (obviously) as the hostname shouldn’t need more than maybe 1 or 2 times to change it. Snapins running still is the end of the problem though? Not sure how to approach. Since hostname change is expecting to reboot maybe this is preventing the snapins from running. We could test that by disabling the hostname changing option altogether on this host?

@JJ-Fullmer This sounds like what we might see when secure boot is enabled? I could be wrong though.

Simlarly, ipxe.efi wouldn’t be the only file to try. ipxe.efi would be the best one to start with as it generally encompasses a series of different ethernet drivers, but possibly snponly.efi could be better?

@adam1972 I believe the snapin running is expected to happen anytime, but I do know know the FOG Client code as I do pretyt much every other aspect of FOG unfortunately.

It is possible snapins cannot run until a user has logged in, but I don’t really have a means to validate that. (This would be specific to linux machines. I suspect mono engine that helps perform those tasks may need the user to login to establish permissions so this may not even be directly a fog client problem, but the installed mono package?)

The enforce host change thingy, that is under the host -> Active Directory and labelled:
Name Change/AD Join Forced reboot?

@anube Sorry for the clarification needed, but ipxe.exe doesn’t exist was this a typo and you meant you tried ipxe.efi or did you try ipxe.exe?

@fairoozfarhan looking at a glance I think your dhcp-range line is incorrect:

I believe it should be:

dhcp-range=192.168.11.2,192.168.15.254,12h

@ghayut /images/dev is the placeholder when you capture images.

THe ‘id for library’ as you put it is the machine’s mac address that was used to capture the image.

As apart of the process of the capture, once the actual block capture is completed it checks back into the server which the server then moves the image from /images/dev/<macaddress> to /images/<imagepathname>

If you don’t see this occurring it’s almost always because the capture didn’t completely fully and the capture task was just powered down.

If that helps (I hope it should) then you can manually move the image to hte pathname it’s expecting.

There is no automation we can provide that will be able to do this for you though.

@Baessens Reinstall fog. It should download the latest kernels and inits of which what was referenced on that post is the EXP items. (So it’s now the default)

@adam1972 I may be confusing you:

Hostname Changer isn’t a native part of FOS but it is a native part of the FOG Client. Are you saying this isn’t working? In other words, you shouldn’t have to write a snapin to change the hostname, it should just work.

I was only asking about snapins because to use them, that means you have the FOG Client installed.

Now that we have that cleared up, what is the error log for the FOG Client on one of the machines giving issue?

The log is located at /opt/fog-service/fog.log.

@adam1972 I am not sure of the question exactly. There isn’t a hostname changer after imaging for Linux but there is the fog client that when installed should be able to perform this for you. Snapins seem to indicate that this is already in use?

@Fog_Newb @JJ-Fullmer I wonder if this would work better separated out:

mkdir /images1
mkdir /imagesdev1

mv /images/dev/* /imagesdev1 #everything here to imagesdev1 for example
rm -rf /images/dev #only after moving everything first (including . files/directories)
mv /images/* /images1

rm -rf /images #only after moving everything first of course)

ln -s /images1 /images
ln -s /imagesdev1 /images/dev

Does this work?

Of course your fstab would need adjusting if it does, but jus trying to think what may be causing issue is that a root system (/images for example) doesn’t know how to handle the inode movement occurring from another filesystem (/images/dev for example) If you were to move /imagesdev1/file to /images1/file it should work just fine because you’re crossing filesystems which doesn’t pose a problem due to the root structures actually being at 2 different physical points. I believe this is a limitation of linux, not necessary a limitation of FOG persay.

@ccatcc Sourceforge hasn’t been updated in almost a decade, so I think you’re FOG version is MUCH newer than that considering the bzImage version is 6.6.44 and the one you " updated " to is 4.1.2

please attempt updating your latest fog version?

@MarkG What i mean is loading the actual system.

RIght now it seems (to me from the image provided) that it doesn’t get you into FOS. It loads, just gets stuck?

@MarkG So that leaves me with a few notes already:

1. Need a storage for global arm Kernel and Init
2. Need to associate architecture to appropriate kernel/init.
3. Later we need to get kernel/init actually loading/booting?

@Fog_Newb

Manually moving a directory (which couldn’t possibly fit on vda) from /images/dev (vdc) to /images (vdb) caused the virtual disk size on vdb to increase. IMHO, it seems clear the directory was initially stored on vdc. Am I wrong in assuming this confirms that the mounts are correctly configured and functioning?

Yes. vdb is /images, so moving a file from /images/dev (vdc) to /images (vdb) should cause the disk to increase on vdb? The sice on vdc wouldn’t decrease but the amount of usable space off vdc should be increased by the amount of the file that was moved to now vdb?

That’s what I’m understanding here. I don’t know if this means there is an issue or if this is working as intended, but it seems like it is?

@adam1972 With the task in debug now, that you’ve done the e2fsck:
Now run fog from the blue prompt and it should run though the normal process just pausing as it goes along.

@Fog_Newb You seem to have the same uuid for both vdb and vdc