Best posts made by Wayne Workman

It’s not permissions related. All snapins run as the SYSTEM user, which actually has more privilege than a local administrator account.

@Quazz is right, it says in the log that there is a hash mis-match.

also, in the log, it says 7410 and 0.11.2

I’m not entirely sure how that’s possible, I’m pretty sure that 0.11.2 didn’t exist back when 7410 was pushed, Seeing as 0.11.2 was released yesterday and current trunk is almost 1,000 trunk versions ahead of 7400, I don’t think something is right.

Is this FOG server in a VM? Did you restore a snapshot from way back? How are you updating your server, exactly?

The thing to understand is that the new fog client and the fog backend and web interface are being developed simultaneously. Changes are made to both at the same time to make things work, fix stuff, add features, and so on. What this means is, if you don’t use the version of the fog client that the version of fog you’re using came with, things are likely to not work.

Additionally, simply properly updating your main server to the very latest could potentially fix your issue.

Lol I’m out - gunned here. I’m on mobile.

@george1421 it’s the fog users ftp root directory. As soon as you authenticate via ftp as fog, you plop into the users home directory.

I should explain to the best of my abilities how replication happens, where relevant to this topic.

The fog image replicator replicates only images that have a definition in the database. What this means is the entire images directory is not necessarily replicated completely. If for instance you delete an image but do not delete the image data on the hard disk then that image will no longer be replicated. All uploads go to the dev directory and of course get moved after upload is complete to the images directory. I think the only case where replication might try to copy a file that is currently being written to is if the images directory and the dev directory are on two different disks. The dev directory is never replicated. So I don’t see how in probably 99.9% of cases how lftp would try to replicate an image that is being currently written to.

@PeterT said in How To Acquire New Kernels?:

I suppose the next version of FOG might automatically update storage nodes along with the master node, but now that we figured it out, we don’t mind doing it ourselves.

I’m actually actively working on this. In the future, if PKI authentication is setup for the Main server to all storage nodes (one way), then when running the installer on the main, you’ll have the option to update all nodes at once as well. I’m working on making it easy - there’s a lot involved, and I’m almost done with it.

@fry_p Excellent job. What you posted is exactly what I would have had you do.

Just keep in mind that this is only likely to work with the exact sub-model, the one you said: Surface Pro 4 1724

For future readers, all that’s needed to make a vendor class for other sub models is a packet capture posted here on the forums, or analyzed by yourself. Simply look at the device’s DHCP Discover packet, inside option 60 you’ll find the vendor class identifier.

@TomBagley said in http:///service/ipxe/bg.png Error 0x3e11613b / Fog UI Stuck in Loop:

http://service/ipxe/bg.png… Error 0x3e11613b (http://ipxe.org/3e11613b)

I just noticed that line is missing both the IP and fog. It should be this:
http://192.168.150.10/fog/service/ipxe/bg.png

My first advice would be to check in Storage Management, look at all node’s Web root field. This should (generally) be /fog

Then look inside of FOG Configuration -> FOG Settings -> Web Server -> FOG_WEB_HOST and FOG_WEB_ROOT.

Web host should be the fog IP address. web root should be /fog/

@pmonstad The pictures you posted are for the legacy client I believe. Updating of the new fog client is controlled here:
Web Interface -> FOG Configuration -> FOG Settings -> FOG Client -> FOG_CLIENT_AUTOUPDATE

“The parameter is incorrect” literally means the parameters the client is being told to use are incorrect. Check your Active Directory settings for this host. Ensure domain name, username, password, and OU are all correct.

I helped via team viewer.

The location were images was being kept was changed from /images to /deploy but fields in Storage Management, /opt/fog/.fogsettings, and in /etc/exports were not updated. After doing that, everything was fine.

@Jay-Bosworth said in FOG menu not showing up on some machines after DHCP server rebuild:

it is asking for the address of the tftp server.

That tells me you have more than one DHCP server, and one or more are mis-configured.

@george1421 Next, he’ll ask about how to suppress the menu.

@K.Hays said in Problem updating fog: Backing up Database ... failed:

Any idea to what caused this whole thing?

Somebody messed with the .fogsettings file and put in the wrong information. If things in there are wrong and you update - things in fog will be wrong.

For you and future readers, information on the .fogsettings file and passwords are in these two articles:
https://wiki.fogproject.org/wiki/index.php?title=.fogsettings
https://wiki.fogproject.org/wiki/index.php?title=Password_Central

@kpeterson said in Schema update issues RC-9:

I guess first thing I will try is pull down a fresh copy of RC9

As well as deleting /var/www/fog and /var/www/html/fog and then re-running the installer.

The way .32 and 1.2.0 handled things were really different. .32 was very solid - but it’s old, it can’t support newer hardware, newer disk types, newer HDD types like nvme, flash, hybrid drives, SSD, and it can’t handle GPT type disks, or UEFI booting. 1.2.0 wasn’t any better at any of these things but had a newer linux kernel. But 1.2.0 made a lot of assumptions about the disk which made it difficult to work with.

Would you be willing to upgrade to the release candidate for 1.3.0? What OS is your FOG server running on, first?

If you use the powershell template when you create a new snapin, it already has execution policy bypass in the arguments for you.

your problem is that you cannot “capture” the image. Please do a debug capture. This is a checkbox that you tick on the capture confirmation page. When you network boot the system for capture, it’ll land at a linux shell eventually, you’ll need to press enter a few times to get to the shell to pass the informational windows.

Here, run these commands and give us the output:
lsblk
fdisk -l

From this we should be able to figure out what’s going on.

Two approaches here.

Create a fake image and make its path /images/drivers and setup the fake image so it’s shared with the other servers via groups or whatever way you have the images set up.

Script it with rsync & make it into a CRON job on the main server.

@dbakerwardog

cd /opt/fog
vim .fogsettings  #or nano

locate the line that begins with packages and ver and veradds and remove those lines, save, then re-run the fog installer.

Reference:
https://wiki.fogproject.org/wiki/index.php?title=.fogsettings
and:
https://wiki.fogproject.org/wiki/index.php?title=Vi

@palloquin said in Passwords, I broke 'em...:

Why can I change the ‘fog’ user’s password through the web interface if this just breaks it…

I should clairify something here - the web credentials you use to log into the web interface are not the same credential-set as the storage node’s default ‘fog’ account. These are two completely separate and independent things. The wiki article called “Password Central” explains every single password in the FOG Server, how it’s used, what it’s for, where to change it. You might look through it if you’re really interested in learning more linux-config-dark-magic-stuff

@amo862 Try these files:
ipxe7156.efi and i386-7156/ipxe.efi

Which kernel that gets used is dynamic. If you look here in your web browser, replacing the Xs with your FOG Server’s IP address: x.x.x.x/fog/service/ipxe/boot.php You’ll see a line that looks like this near the top:

cpuid --ext 29 && set arch x86_64 || set arch i386

That’s what sets the arch parameter inside of the iPXE environment, it is what determines which kernel arch gets used - this is all automatic.