Posts made by 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?

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

@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

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

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

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

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

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

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.

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

@sega Ok the picture tells me more about where its hanging. When it hangs here it more indicative that you have a network infrastructure issue. At this point you are running under the FOS (linux) engine. You could always try to update the kernel to the latest 6.x version using the web ui fog configuration->kernel update. But my intuition is telling me its something outside of the fog ecosystem causing this outage.

The transfer rate of 948MB/min is also not good. On a well behaved/designed 1GbE network you should see 5.7 to 6.5GB/min To translate that 948MB/min == 16.4MB/sec

1GbE is 125MB/s
100Mhz is 12.5MB/s

With data compression 16.4MB/sec is pretty close to 12.5MB/s. So just using some wild guessing I would have to say you have somewhere between the FOG server and the target computer a 100Mb/s network link.

@YYoudi Yes I understand, you are trying to do what I was attempting to do in the past. I was able to prove what was happening in the past and why it was failing. To fix the issue will require a change in the FOG php code.

@rogerdodger I looked into Windows Configuration Designer since I dont use it. FOG is not the right tool here to use. This WCD creating a deployment package that windows oobe uses /installs from local media. So windows is running at that time, FOG can’t touch the system since its running linux. Unless you can access the wcd package files from a network share, you are stuck using a usb/sd card.

@rogerdodger Typically to would bake that into your golden image, so your deployment was all self contained.

But to your point answer me what is on that sd card? Do you boot off from the card or do you boot into windows and then run a batch file from the sd card?

There are a few options if its self bootable or you can make a winpe image that containes the files you need and then you can boot that from the fog server. SO you have a few options based on what you have on the sd card.

@Tom-Elliott Thank you for the update. I should have looked at the code.

So the OP needs to update the current curl call with this ?

    base64mac=$(echo $mac | base64)
    token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php")
    curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php" -A ''

To make it work now?

@sega It would be helpful to have a picture of the error message to know where its getting stuck at a percentage. But If I have to guess, it would at the beginning of the imaging process where its downloading bzImage or init.xz to the target computer. When it gets hung it doesn’t ever continue.

If its getting stuck here you might want to rebuild iPXE with the latest version.

Also you didn’t mention the version of FOG you are using.

@Eazis the Arch value is probably not unique enough for your needs. arch 7 defines one of the uefi flavors. The likelihood that both of your systems being the same uefi type is pretty high.

There is something else that might be a bit more hardware specific. That value is the uuid field. I can tell you that for Dell computers the uuid is model specific. Actually the first 4 characters of the uuid is Dell spelled backwards in ascii.

So how can you tell the system’s uuid? Use wireshark on a witness computer connected to the same subnet. Start wireshark and use a capture filter of port 67 or port 68 or use a display filter of bootp With wireshark running pxe boot the target computer. You should see 4 or more packets. Look at the DISCOVER packet, this is the target computer saying “hey I’m this come configure me” In the discover packet is the uuid field. Compare these uuid fields between the two different hardware in question as well as 2 of the same model of computers. With that info you can create a custom dhcp class filter to send the appropriate boot file for the unique uuid system.

@Tom-Elliott I think I understand what is going on here, and what the OP is trying to do. I think I tried to do the same thing and ran into a similar error.

If I can guess correctly, the OP is trying to create a custom task, as with maybe the fog built in task to scan a vm for a virus (only used as an example). What the OP did is create a new custom task with the task type edit plugin. The intent of his task is to boot using the parameters values, as if you were to create a fog ipxe menu. What the OP wants to do is to apply a custom task to a set of computers. Have the target computers reboot and then run the contents of the parameters block as if there was a tech sitting in front of the computer and select the menu entry. So that is the premise of what I was trying to do.

What was really happening is that the task was applied to the target computer and then rebooted, but instead of booting using the parameters in the parameters box, it boots into fos linux and applies the contents of the parameters block as kernel parameters instead of booting winboot. So in this case the OP is getting the Null message because fog didn’t tell it to unload or download an image. I’m not sure if I explained it properly, but I can understand why the OP got the Null message, because that is coming from FOS Linux and not wimboot.

@zaboxmaster This should work unless something changed in the inits.

So first lets start a debug deployment. Tick the debug checkbox before you schedule the deployment. pxe boot the target computer. After a few screens of text that you need to clear by pressing the enter key you will be dropped at a the fos linux command prompt (I understand that you usb boot but we need to pxe boot here to get into the right mode).

(insert flash back) you updated the fog.man.reg file and its copied over to the FOS image using the fog postinit script file. Its possible that the custom fog.man.reg file is not being delivered to fos linux.

So what you will do is single step through the deployment until we get to the postinit section.

(back to reality) at the fos linux command prompt key in fog At each breakpoint in the deployment you will need to press the enter key. Somewhere along the way before the partclone screen you will see the message about the postinit scripts running. Press the ctrl-c after the post init scripts run. Now verify that the fog.man.reg file in /bin on the fos linux engine has been updated with the curl command from your OP.

If that file has been updated. then try to execute the curl command from your OP. That should create a file in /tmp as hinfo.txt look to see if it has content. It should have many lines of variables with its value.

@fogcloud Do you have a specific concern about having ssh enabled on the fog server? Are you trying to meet some kind of compliance certification?