Posts made by Tom Elliott

@sassonie I believe the problem is you’ve been updating FOG (I suspect you’re on 1.5.10 or later?) and have just updated for quite some time.

Now why is this important?

Well, lStorageNodeProto was added to 1.5.10 when it was released last year:
https://github.com/FOGProject/fogproject/commit/48e781f5ecf452662528a7aed4f3cadbc0bb4160

However plugins unfortunately do not have a “schema” based system and when a database update occurs, plugin tables are left largely alone as the intent for plugins are to be maintained by the community. Now we have been trying to keep up with plugins, but on top of everything else, we generally approach plugins as, if it’s not working, remove and reinstall (after backing up relevant information of course).

I suspect that’s what you’re seeing.

Basically my suspicion boils down to the UI expecting the key lStorageNodeProto to be a column on the locations table, but it currently does not. This is why you’re seeing a warning. Now, that alone shouldn’t pose any problems, but I haven’t looked deep into the codebase to see if there’s any logical checks specifically trying to load a bit of data using this specific key.

@anube Can you please clearly indicate what you’re doing?

I mean, you say you cannot boot MSI Cube 12M, or use it as a FOG Server?

The messaging seems to be lost and at no point have you shown us anythign that’s showing this device cannot boot to FOG (assuming you have a FOG server somewhere?) and your first message says ? I can't run the exe on MSI Cube 12M. As a pxe FOG server.

It’s unclear what you’re actually attempting to do and what you’ve actually attempted to do. Basically, I believe, at this point, you’re just putting the .efi files on the device expecting it to boot?

While you did provide the kernel versions we install, it doesn’t seem like you’re actually configuring a DHCP server to set the Option 66 to the FOG Server’s IP address and Option 67 to the boot file (whether static or dynamic adjusted)

@benc The versions of FOG you had installed, and/or specific date versions of the FOG Inits.

While we’ve been making adjustments to the code and even had an init or 2 that probably were broken for a small period of time (which we’ve since fixed) it seems you’re having the problem with the latest versions as well?

I highly doubt that it’s in the code because if it was, we’d be getting reports almost non-stop I’m sure. We have people running FOG 1.6, 1.5.10, 1.5.10.x (where x is 41 or higher on the stable sides) etc… and i’m pretty sure if resizable images were broken we’d have many more reports of this occuring.

Now that’s not to say you’re not having the problem of course, just that it feels like it was more a timing of when you got your init which may have just been missing a bit of code.

Now that I look at your picture a bit closer, though, it seems likely it’s something on this disk.

If you can upgrade to the latest stable (or 1.6 version of fog) then youu’d be willing to make this a capture debug task (just delete the current tasking, create it like you normally would, but before you just hit continue, check the box for “Schedule as debug” then hit continue.

Boot this machine, then when it gets done, it will load to a linux terminal.

From there you can try just run the fog program and press enter at each pause. it’s intended to give more details and time to look at things.

After that when this error occurs, break out with CTRL+C

Then run “fixparts /dev/sda”
Then when prompted the three commands you’ll type will be y w y

After that bring the output (either image or ssh to the machine and copy paste from a putty/ssh session - the latter being preferred for readability.

To ssh:
at the command on the host machine in debug, run passwd and create a new password.

SSH to the machine in question (us ifconfig or ip a s command to find your IP address and do the same fixparts /dev/sda command, then copy paste the output.

@benc so I believe you’re having an issue and I believe you have a work around. I’m trying to think about differences and I think in your case it is specifically the kernel/init. More specifically the init as that is where the programs and scripts reside. What I am going to say is that if this were a version issue, basically all people after 1.5.10 would be broken when dealing with resizable images. Can you provide specific versions you were running and seeing these issues?

@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?