@sideone You use location plugin, correct?
Posts made by Tom Elliott
-
RE: Snapins not deploying: Illegal characters in path.
-
RE: FOG 1.6.0-beta.2134 - Host won't add automatically
@sideone I just pushed what I hope might help with this. I cannot guarantee it will fix it, but it should give more forward progress.
-
RE: FOG 1.6.0-beta.2134 - Host won't add automatically
@sideone So I see it getting invalid host, then trying to register.
Is there, by chance, a php-fpm log around the same time?
Specifically hoping to see an error or even a warning.
Is there anything after the registration attempt?
-
RE: FOG 1.6.0-beta.2134 - Host won't add automatically
@sideone I don’t believe this is a bug in FOG 1.6.0 specifically, I suspect, you’d run into a similar issue using any other version just as much as this 1.6.0
That said, the issue is Invalid host.
Are you not seeing this host show up in “pending”? IIt might be one of the mac’s this machine is sending is registered to another machine that’s in a pending status?
-
RE: I am getting stuck on `EFI Stub`
Try follow this information please:
https://forums.fogproject.org/post/155885 -
RE: The image deployment is slower than before
@Cristian 1000GB a minute? I’ve seen 20gb a minute, and that is really saying something.
10GB a minute is still well above a typical (generally in my eyes) “normal” speed deployments.
So i’m not really sure where to go.
-
RE: lightdm user detected, wont change hostname
@AUTH-IT-Center That is correct. That’s what that FOG Settings item is meant to do. If that is checked, on registration it should set that flag on future registrations, but it doesn’t on existing hosts that were registered before it was checked. If after this is checked and a new host registers and this isn’t working, I would believe there to be a bug.
Though a workaround exists, so while, it would be a bug, it may not be the biggest concern to get fixed immediately over say actual imaging issues.
-
RE: lightdm user detected, wont change hostname
@AUTH-IT-Center hostEnforce falls under the UI for AD stuff because initially this was thought to only be required for Domain Joins (as hostname, restart, domain join, restart) would generally be the order of things. Then we extended the client to work on Mac OS and Linux. However, we just never moved the “enforce” changes.
Why? Domain joins for all systems also require reboots, so this “checkbox” is needed for both AD stuff and just baseline Hostname changes.
-
RE: lightdm user detected, wont change hostname
@pilipp_edv I don’t know. The hosts don’t have that thing checked. Maybe there’s a bug, but I don’t know.
What I do know is that the individual host is supposed to have it checked. I thought the value there effectively worked as a global toggle.
-
RE: lightdm user detected, wont change hostname
@pilipp_edv That’s the same thing.
In the DB the actual name is FOG_ENFORCE_HOST_CHANGES, and for 1.5.x we tried to do some fancy things by replacing
_
withFOG
-
RE: lightdm user detected, wont change hostname
@pilipp_edv FOG Configuration Page -> FOG Settings -> FOG_ENFORCE_HOST_CHANGES will set this globally, though for existing hosts it may need to be enabled as well.
If this is okay for all hosts, just create a group -> add all hosts to the group -> then set up things in the same way from the group to enable this setting for all hosts that already exist.
-
RE: TFTP Problems After Update
@kenneth-sisco These are the packages installed on a fresh system generally:
attr bc curl dhcp-server gcc gcc-c++ genisoimage git gzip httpd jq lftp m4 make mariadb mariadb-server mod_ssl mtools net-tools nfs-utils openssl php php-bcmath php-cli php-common php-fpm php-gd php-json php-ldap php-mbstring php-mysqlnd php-pecl-ssh2 php-process syslinux tar tftp-server unzip util-linux-user vsftpd wget xz-devel
I think the relevant one is tftp-server. Why i tgot removed is a bit strange in my opinion, but hopefully this helps.
-
RE: Capture UEFI image on hyper-v VM
@Baessens Unforutnately the EFI stub: Measured initrd data into PCR 9 seems to be hitting us a lot lately and I don’t know why or what’s causing it.
I have heard mixed results of using older kernels, and sometimes newer ones fix it for the person. Not really sure what will be the right case here.
From FOG UI you can downgrade the init based kernel by FOG Configuration -> Kernel Update.
Please try some of them and let us know, if any, which works for you.
6.1.89 was one (20240430_1) was one that seemed to work for somebody. Maybe there?
The configs don’t change much between newer version, but we were seeing similar errors using the 6.1.22 version. This leads me to believe something was added to the kernel code, potentially removed, then re-added to it later. Just a suspicion I have.
-
RE: Number of snapins appears limited in PXE boot environment
@David-Scott I see what you’re asking, but if you press enter, it will display the next set in the list. If you enter in an ID and then press enter it will go to the next step assuming you wanted whatever value you entered as the id (or ids) associated to the host you’re registering.
-
RE: Number of snapins appears limited in PXE boot environment
@David-Scott I’m. Or sure I follow the problem. The max displayed per page is defaulted to 20. Once that cap is hit it says “Press enter to continue or enter the ids you’d like to add” or something like that. Are you unable to hit enter to see the rest of the list?
-
RE: Storage Node Error
@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/48e781f5ecf452662528a7aed4f3cadbc0bb4160However 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.
-
RE: Fog does not run on MSI
@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)
-
RE: Error at beginning of capture--Could not fix partition layout (runFixparts)
@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 bey
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, runpasswd
and create a new password.SSH to the machine in question (us
ifconfig
orip a s
command to find your IP address and do the samefixparts /dev/sda
command, then copy paste the output. -
RE: Error at beginning of capture--Could not fix partition layout (runFixparts)
@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?
-
RE: Network
@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