Topics created by WT_101

Hi there,
this Problem allready existed in this forum and has been signed solved, as the threadstarter resigned and used the EXIT-way in Fog
(https://forums.fogproject.org/topic/16762/local-grub-booting-fails-from-fog-menu-pxe-uefi/7)

For me the problem persisted, as I need the features in refind for dualbooting the systems.

Meanwhile I tried some more scenarios.
My PC’s have 2 OS’s : Windows 10 and Ubuntu

With Ubuntu 20.04 everything was fine untill one Update (still have the Image) and all version from there on show the the Kernel panic.

I tried several configs in initramfs - different compressions, I thought it is a bug

I think I followed all descriptions from all experts in the net for this Error.

But the system (as you allready know) boots fine, when booted directly

So I start to ask myself - what is the difference?

refind and booting from the memory fog-pxe presents.

is it possible, the compression gots worse?
that for some reason the initramfs gots bigger
is there a way to reduce the initramfs filesize

It is a pitty ther is not enough logging

@WT_101 As I mentioned, FOG doesn’t support imaging over wifi. The first roadblock that you will hit is iPXE because it needs the drivers and then your wifi settings to connect to. The second issue you will have is with FOS Linux, none of the wifi drivers are added into the kernel, nor is any of the wifi utilities compiled into the initrd file system. You would be better served with a usb ethernet adapter.

@Sebastian-Roth May i know which part of the PHP will passing these argument into kernel ?

@Sebastian-Roth Thanks I change the mounting point then it works.

@piotr86pl said in CentOS Partition Count Failed:

The script checks how many NTF

In order to use “Single Disk - Resizable” option during the installation CentOS for the /boot directory i use ext4 instead of xfs. As a result it can be capture without error but the image client size still remain the same size as the disk.

@george1421 said in postinit script changing kernel parameter "fdrive":

AFAK you can’t edit the kernel invocation line.

@WT_101 While I think George is right on this part I can still see how you might achieve what you want to do by overwriting the fdrive variable within a postinit script. The postinit script is being sourced (ref) instead of called (subshell).

This is just from brain to keyboard and I have not done any testing. Give it a try and see…

@WT_101 Currently FOG does neither store the error message nor does it stop the task in case of a failure. Probably a nice feature to add if you are keen to get into it.

You wanna start by looking at the FOS script code. Pretty much all errors cause a single function to be called: handleError() in /usr/share/fog/lib/funcs.sh (code reference). This function could be extended to report back to the FOG server and even cancel the task.

@wt_101 Well juggling three with running chainsaws doesn’t make it a bad idea, does it?

The 15 character limit is a windows NT thing. Since the majority of the folks that use fog for image deployment the developers have set it to 15 characters. If you have a use case where you need more than 15, I don’t see the harm in expanding it to more than 15 characters. That is the beauty of opensource. If it doesn’t work for you out of the box, if you have the skills you can change it.

You just need to be mindful if you have to interact with windows that the computer name might get truncated 15 characters when the computer name is set.

But also be aware that I don’t know of anyone who has tried to set computer names long that the MS defined standards either. Other things in FOG may break (thinking fog client if its hard coded at 15 characters).

@wt_101 said in USB Booting a usb network adapter:

ncm–ecm–axge.efi

I have no idea what that boot loader does. Its a component of iPXE.

So tell me about your dhcp server. What is the manufacturer and model.

The idea is that if we can uniquely identify that usb drive, maybe we can send the proper boot file name. If you are using a windows dhcp server and setup efi policies, that is getting us in the direction. That policy looks to see if the arch value is 0 (bios) or 7 or 9 then its uefi. If we can combine the uefi test with the manufacturer id of the mac address then we could send that alternate boot file name when the target computer is uefi and the mac manufacturer matches. Its easier to do with a linux dhcp server or using dnsmasq as a proxydhcp server.

@wt_101 said in CentOS LVM Slow Imaging:

what do u mean by RAW image type?

This is a mode for partclone when it can’t determine the format of the disk, this is a default mode when no other disk format filters exist, such as with LVM. In linux terms partclone uses dd (disk dump) format to image the disk. This is the slowest and largest format since it copies all disk blocks. Partclone might change to this format if it detects and encrypted drive where it can’t read the partition information because its encrypted.

ref: https://partclone.org/usage/partclone.dd.php

@WT_101 Hook events are called by the FOG code. Don’t think this is what can help you with activating plugins. Did you look into directly updating the database tables as mentioned in your other topic yet?

I create a “activatepulginrun.php” and place under “fogproject\packages\web\management”

the file can be call by the url “http://fogip/fog/management/activatepulginrun.php?plugin=accesscontrol” with the plugin name passing in

First the code need to include below 2 line
require ‘…/commons/base.inc.php’;
$FOGCore = $GLOBALS[‘FOGCore’];

then i include both

activate plugin code
copy from “activate()” at “fogproject\packages\web\lib\pages\pluginmanagementpage.class.php”

install plugin code
copy from “installedPost()” at “fogproject\packages\web\lib\pages\pluginmanagementpage.class.php”

@WT_101 said:

I’m trying to change some wording such as “Host” to “Platform”

Not sure it’s wise to do as we don’t understand your working here in the forums. 😉

Take a look at what the installer does:

msgfmt -o ".../path/to/messages.mo" ".../path/to/messages.po"

How to use “web/management/language/en_US.UTF-8/LC_MESSAGES\message.po” and “packages\web\commons\text.php” ?

The later file was initally meant to be used for a general place to define variables for most used terms and phrases that could be used throughout the code. But I think it’s not being used in each and every stop in the code. Searching the code (or github) you can find many places where this variables are used: https://github.com/FOGProject/fogproject/search?q=foglang

I have found the correct file to change which is “pdodb.class.php”

Cert to add here
6fe5af73-ef3f-4cad-a605-3da5c1c0eca4-image.png

While the port can specify at $dsn
a83bd0c8-cc7c-4f80-bdd2-679fe4221514-image.png

@wt_101 I can tell you that multicast is more problems than unicast. Multicast requires more resources (things setup correctly) than unicast.

The way fog works is that the udpsend (multicast sending program) is launched by the web server. So multicasting is linked to the server where the web ui is running. The storage nodes do not have a web ui. So the key here is that multicasting is started by the FOG web server.

It is technically possible to launch a program on a remote linux server using ssh. This requires ssl certificates to be put in place so that the ssh connection uses certificates instead of a password.

A storage node is technically a normal fog server except it uses the master node database and the web interface is shut off from browsing. The web interface is there, its just blocked from access. So the udpsend program should also be installed, so it could send out multicast images. FOG isn’t designed that way, but its not impossible to do if you had the motivation and php programming skills.

The last thing I can think is if:

The FOG API can be called on a “Storage node” AND You can schedule a multicast deployment via the API

You could make a curl call from the master node to the storage node to initiate a multicast deployment. I’m only mentioning this because it might be possible, but I have not tried to know if it IS possible to do.

So to recap I see 3 ways to get a storage node to multicast.

Use ssh and call udpsend directly from the fog server Write a custom php page on the storage noted that would launch udp send based on a web page call that passes the required parameters. Use the FOG API to call a multicast send on a storage node.

I can’t tell you if any of these methods will work. I can only tell you that the sending of multicast image is tied to the FOG Web UI.

@wt_101 I do have a proof of concept for NFSv4 and I’m running it on one of my production FOG servers. https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3/10

The tough spot is that you need different inits with NFSv4 enabled. The default inits that come with FOG have nfsv4 disabled. The other issue with nfsv4 is that the shares are changed a bit into a virtual share. My PoC thread also covers that. I really need to consolidate that into an easy to follow thread. I was going to save pushing for nfsv4 in FOG 1.6.x series but that series is getting pushed out because of the lack of dev time. Here are the inits from Jun 2021 with nfsv4 enabled: https://drive.google.com/file/d/1EHLhmM9-kXpFO7kfk3H1ydEZF3q8lID1/view?usp=sharing

@WT_101 Probably you have a proxy server in your network. Search the forums for proxy and you’ll find information on this.

@wt_101 If I can suggest you look at this post: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

it gives you an idea how to do this with windows. You can use the same concept, except for maybe look for the partition that has an /etc directory.

Here is a bit older script that shows a few different techniques. https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

@wt_101 When I say heavy lifting is done by the client computer, I mean all of the work and the actual performance of fog imaging is directly impacted by the target computer’s capabilities and components. While I understand this is technically impossible, but if you have 2 computers that are exactly matched, except for one has DDR3 1600 and the other has DDR4 2133 RAM, the second computer with the faster ram will deploy the image faster because the transferred image is decompressed in ram on the target computer (more on that in Q2).

Q1 To be honest I never paid attention to what the web ui says for size vs what is on the disk. Off the top of my head having a 3:1 compression ratio seems a bit high in my estimation. Is it possible, yes. What really is a metric is what is the size of actual data on the target computer vs the size of the image files. Its possible that the web ui is recording something different that raw source disk vs compressed image file. There is a compression slider in the image definition. This tells the compressor what compression metric to use (not the right words) during compression. The higher the number the more compression methods it uses to compress the data. i think the slider is set for a default of 4 or 6 for gzip that value is a good balance between compression size and speed. For zstd the Goldilocks number is 11. Where the gzip compressor has a range of 0 to 9, zstd has a range of 0 to 22. I don’t think anyone has done any testing to find the actual Goldilocks number in a quantitative way though. I suspect they found a number that worked well for them and called it good.

Q2 Option A is correct. The image is compressed/decompressed on the client so only a compress image is ever communicated with the client. This saves on storage image size on the storage node as well as transfer bandwidth. From a metric standpoint I know that a 25GB target image can be transferred in about 4 minutes. The only way that’s possible on a 1 GbE network is to transfer a compressed image.

Q3 See that is where the magic of FOG is. The developers created a custom version of linux. That version of linux is called FOS (FOG Operating System). That OS has all of the tools built in that FOG uses to image a target computer. Yes FOS has zstd and gzip compressors built in. When you pxe boot a computer during image, first the iPXE boot loader is transferred to the target computer. iPXE is responsible for the FOG iPXE menu. Once you make a menu selection (like registration) you will see two files transferred to the target computer if you have a fast eye. You will see bzImage (the kernel) and init.xz (virtual hard drive) send to the target computer, that IS FOS linux being sent over. The OS is very small and very fast.

For Point 4, that is more of a question for the developers. I don’t look under the hood for statistics settings. I just know that on the Partclone screen what that speed number means. I don’t know if the FOG program as a way to record that speed or not. As for taskelasped time I think that means something else. As I mentioned above, on a 1 GbE network a 25GB image should take about 4 minutes of transfer time. 16 seconds seems a bit quick.

For Point 6, The fog client is used for more than just renaming the client and connecting the target computer to AD. Its also used for application deployment and some rudimentary system management. You do not need to run the FOG Client if you don’t want to manage the target computer after image deployment.

Q1 yes there is a way. On my campus, which is mostly MS Windows based, I don’t use the fog client at all, yet I still have a touchless deployment. I leverage a feature in FOG called a Post Install Script to make changes to MS Windows unattend.xml file just after the image is pushed to the target computer. For a linux client it is just as easy most of the things that configure linux is just in text file, and FOS Linux is… wait for it… linux, so the possibilities are endless. The concept of a post install script is that you would create a bash script on the fog server that is executed by FOS Linux. That bash script would mount the target computer’s hard drive (post image deployment) and make the necessary adjustments to the hostname and any other deployment specific settings. The post install script can have access to fog host definition variable so you can leverage some of the extra fields in the host definition for specific uses (like other1 and other2 fields).