Posts made by george1421

george1421

@DBCountMan The issue/explanation is that the unregistered hosts deployed via the ipxe menu doesn’t go through the normal task creation process so there is no database interaction. When you call the deploy image task the fog server creates the ipxe menu needed for imaging but that’s it. The fog server never “really knows” and unregistered guest was imaged.

Now what can you do on the back end? Probably a post install script could open a file in the /images/dev folder and write the mac address into a text file with the current date/time. This is possible, but I don’t have an example I can point to. If FOS Linux had a ail client it could send an email when it was done imaging too.

george1421

@JamiesonCA092 I can’t really give you a solid solution because fog isn’t designed to work the way you want it with unregistered target computers.

But I know how FOG works. There are 2 “hook” scripts. One is before imaging starts and one after the image push is complete. The bash script that is called before imaging starts is the postinit script. When this script runs all of the kernel parameters have been expanded to variables, including storageip value. This value as well as most others could be reset by this postinit script.

I have a tutorial on a postinstall script that uses the IP address of the target computer to decide what OU the target computer will connect to. That mechanics of the bash script could be the basis to update the storage IP variable. I don’t know if it works, but if you are that deep into modifying the ipxe script, creating your own bash script shouldn’t be to complicated.

Edit: Post on point. https://forums.fogproject.org/post/69725

george1421

@mentaluproar said in Could not select: Exec format error:

/var/www/html/dban/test.html

try it in /var/www/dban/test.html

different distros have a different apache2 document root.

george1421

@t-schuurmans Looking at the error message I can tell you that /dev/vda is the wrong answer in regards to a software raid array.

There was just another thread in the forum where someone else was doing the exact thing as you.

Edit: https://forums.fogproject.org/topic/17626/issues-with-capturing-an-image-with-a-raid0-array

I would suggest the same thing here. Set the global flag for mdraid=truethen schedule a debug capture. At the fos linux command prompt key in lsblk and then see if fos linux assembled the array for you. If yes, find out the correct device name it is for the array. And finally back in the fog web ui, in the host definition set the hard drive to use the same name as what was discovered in the debug console.

george1421

@mentaluproar The mount -loop or simply copying the files there does the same thing. So the url you should be using is http://<fog_server_ip>/dban/<filename>

There could be a number of things going on here. the path of the files may be /var/www/dban or /var/www/html/dban depending on the apache servers doc root settings.

As a test I would create a file in the dban directory, lets call it test.html in that file put the following.

<html><head></head><body>It works!</body></html>

Now try to download the file at http://<fog_server_ip>/dban/test.html Does it load the file?

If no then the fog configuration for the web server is getting in the way.

There are other options, but lets first see if

george1421

@sega I don’t know enough to answer your question intelligently.

I can tell you that for multicast imaging FOG uses the linux commands udpsend and udpreceive.

I don’t see any command line switches to pick which igmp mode is being used.
https://users.soe.ucsc.edu/~kent/test/udpcast.html

I can say its rare that there is ever a question on the revision of igmp being used.

george1421

@45lightrain said in Issues with capturing an image with a raid0 array.:

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?

FOG captures disks in block mode. It doesn’t care about partitions (mostly). Also make sure that md0 is the true device for these drives. When you are in the FOS linux shell you can / should create a mount point and then mount /dev/mdX partition to see if you can read the content. I have seen where sometimes md0 is created but the real raid array is /dev/md126.

Also FOG calls a script before imaging starts. Sometimes its needed to assemble the array in this postinit script. Or do other things to prep the system for imaging. So the postinit script (found in the /images directory on the fog server) is a the place to put that code.

Also when you start in debug mode (when debugging the imaging process) you can actually start the imaging process from the command line by keying in fog. The imaging will stop at each debugPause; command in the imaging code as a breakpoint. If you notice something wrong, you can hit ctrl-C to exit back to the command prompt. To restart the imaging process again just rekey in fog.

While it doesn’t exactly apply here I wrote an article 8 years ago about imaging using the intel rst adapter that may contain a nugget of help: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

george1421

@45lightrain how did you create the raid 0 array? From within linux or using the intel rst controller?

FWIW: I have not been able to make the vroc arrays work with FOG, but if you have ubuntu loaded on a vroc array then it has to work and we need to talk.

If you created the array with intel rst or using a software raid created by ubuntu then you have some luck. The first thing I would do is go into the fog global settings and look for kernel parameters field. Then add mdraid-true into that field. That tells the fos linux kernel to look for a raid array.

Next I would schedule a capture or deploy image, but before you hit the schedule task button, tick the debug checkbox.

PXE boot the target computer, after a few screens of text you need to clear with the enter key you will be dropped to the fos linux command prompt. Key in lsblk to see if FOS Linux assembled your array for you. It will probably be listed as /dev/md0, or /dev/md126 or 127. If its there THAT is the device name you need to key into the host record for this target computer in the hard drive field. This way FOG will not try to use one of the nvme drive, but the raid device.

If the device is not automatically detected you may need to assemble the array, but lets first start with making sure you have the kernel parameter set and that fos linux sees the array.

george1421

@jfernandz Would you post a screen shot of the configuration for the ldap plugin? Be sure to blank out only the bits that could make the picture content identifiable.

george1421

@mentaluproar so this dban.bzi is located in the /tftpboot directory on the fog server?

The exec format error is iPXE saying the kernel file is not bootable.

Locate that file on the fog server (should be in the /tftpboot directory) and then issue file dban.bzi does it say its a linux kernel file?

george1421

@mentaluproar I have seen this when you try to boot an bios based image on a uefi based computer. How are you starting dban? Are you loading the kernel and init.rd file or are you trying to boot from an iso image?

george1421

@sega Multicasting should work correctly if the fog server and target computers are on the same subnet. You said that may not be the case. For multicasting to work your router has to support forwarding multicast packets or your router or some device that has access to all of the vlans need to be running an igmp-proxy. This is akin to what a dhcp-helper/relay is to dhcp. You should see exactly what you are seeing if the network doesn’t support multicasting. The FOS Engine is started using unicast messaging, the partcone part is where the multicast stream really starts moving data.

george1421

@gribbler Something is telling me the bzImage and init.xz files are out of sync or init.xz is damage in some way.

Looking at your OP and the screen cap I still can’t believe that this is FOS linux starting up. Especially this part:

fstab on host
/dev/mapper/rl-root / xfs defaults 0 0
UUID=811b72e5-eba6-446a-b8f7-90cbc88c6d08 /boot xfs defaults 0 0
UUID=E788-250F /boot/efi vfat umask=0077,shortname=winnt 0 2
/dev/mapper/rl-home /home xfs defaults 0 0
/dev/mapper/rl-swap none swap defaults 0 0

The xfs file system and the second partition having a short name of winnt that’s not FOS Linux. The fos linux filesystem in init.xz is ext2 or ext3, I can’t remember, but its surely not xfs. This makes me think its the target computer’s OS for some reason.

Working with the understanding that this is truly a FOS linux boot, lets have you reinstall FOG. Simply rerun the installfog.sh installer. It will take all of your previous settings and won’t touch the database, but it will reset all of the files in the fog server. Once that is done then use the web ui fog configuration->kernel update to bring the kernel up to 6.6.x. Don’t do anything by hand in the fog server host computer’s file system. This should restore the files back to a known state.

I didn’t happen to ask you what version of FOG you are using, hopefully is 5.10.x

Lastly about your ahci question, yes that driver has always been in the fog kernel. But if you want to look the kernel configs are located here: https://github.com/FOGProject/fos/tree/master/configs

george1421

@kalmarteve I see you have the latest kernel and version of FOG. So we can rule out an older build.

It appears that you are uploading the image to the fog server. So this is the linux kernel having an issue with the structure of the files on the target computer’s hard drive. This would be the second partition on the disk. Do you have a similar system of same make and model to test to upload. My intuition is telling me there is something wrong with the data on this disk or the disk itself is damaged. Its saying it can’t compress the disk image before uploading it.

If you “absolutely need” to upload this target system to the server, change the disk mode from single disk compressed to single disk uncompressed (I don’t remember the exact words, but it configured in the host definition page for this target computer) Taking it uncompressed will bypass this step, but just be aware that there seems to be something not right with this source disk.

george1421

@gribbler While I understand where its failing in the linux kernel booting process, I’ve never see the FOS Linux kernel do that. Just for clarity is this the target OS booting creating this message or is it happening when you begin to capture/deploy an image?

george1421

@sideone First let me say I don’t use the fog reports or have I used fog 1.6. Byt, all of this data exists in the FOG database in mysql tables. If you know sql you could write a query to dump the tables into a csv file so you can then import to excel or other spreadsheet program. Then you would have full access to the underlying data. I haven’t looked at the database in a while but most of the data should exist in the fog data and hosts table.

george1421

@sega said in Deployment stuck at x percentage:

As I seen the FOG server and the client pcs has to be in the same VLAN for multicast? That’s not our case, they have different ones.

Generally the fog server and target computers should be on the same vlan for multicasting to work. It can work if you have a igmp-proxy server setup on your router between the vlans. Multicast traffic don’t normally pass a normal router.

But now in your network you’ve introduced another choke point in your router must be able to handle the load of these 10 systems being imaged simultaneously. As I said you can flood a 1GbE link with between 2-3 simultaneous unicast images. Also on your fog server, is the image stored on what media ssd or hdd? If hdd, how many spindles are being used? That will have an impact on performance too if its hdd.

george1421

@gribbler Can we get an actual screen shot of the error? The context of the error is almost is as important as the actual error itself.

When you get the kernel panic is it when FOS linux (bzImage) is booting or your target OS? Typically I’ve seen this when FOS linux engine is booting and for some reason bzImage doesn’t match init.xz file format. Such as if you use a new init.xz file with an old FOS linux kernel or the init.xz file isn’t created by the fog project developers.

george1421

So when all are deplyoing at the same time, the rate is decreased.

Ah you are deploying more than one image in a push. Just be aware that you can saturate a single 1GbE link with between 2 and 3 simultaneous unicast image deployments. If you need to deploy 10 at a time them I would look at using a multicast image deployment. This will only send out 1 image with all 10 receiving that same image. Its much easier on the network.

Also if you want to do this with unicast messages, upgrade your fog server network link to 10GbE. If that isn’t possible add 2-3 network ports connected in a network LAG (trunked) configuration. With multiple unicast deployments a LAG group will surely help.

george1421

@kalmarteve This sounds like a hardware error, but lets start with what version of FOG are you using and what version of the FOS Kernel are you using (FOG Web UI->Fog configuration->Kernel update. You should probably be using the latest in the 6.x series. But lets document where you are at today, then plan the next steps.