Best posts made by Sebastian Roth

@exworker9to5 This error is specific to the hardware you try to register. Please try other machines. I am sure you won’t see the same issue.

You can either register this type of machines manually through the FOG web UI and add noapic as Host Kernel Arguments in the host’s settings.

Or you can add noapic as global kernel parameter via FOG Configuration -> FOG Settings -> General Settings -> KERNEL ARGS. Just save the settings and try registering this machine again.

Be aware that setting this as a global kernel parameter will use it for each and every host you register/capture/deploy. There might be drawbacks with other kinds of machines using it. That’s why I suggested you manually register/add the machine via the FOG web UI and adding the kernel parameter just for that single host.

@OmegaXis OK the partition layout looks simple and correct. Not much that can go wrong here.

Searching the forums I found this topic that seems related: https://forums.fogproject.org/topic/15599/resize-centos7-fails-e2fsck

We will try to replicate the issue and see what we find. @Wayne-Workman any chance you find some time to look into this?

@dashwell said:

I’m attaching an image of the PCI ID’s.

Ok, NIC is 8086:15FC - haha, searching the forums I just found that we already had someone with HP ProBook 640 G8 complaining about slow speed and there are two fixes available for this issue:

1. Plug in a random USB storage device (not kidding!)
2. Enable “Storage Controller for VMD” under “System Settings” menu in the UEFI settings

Find all the details here: https://forums.fogproject.org/topic/15132/hp-probook-640-g8-imaging-extremely-slowly

@WillingMost7 Please try re-installing the fog-client software in this machine.

@tesparza The sync is constantly running. If they are still not in sync, something is wrong and you need to look at the logs on the master node to find out why…

@tesparza Yeah, todays log is full of “No need to sync …” messages. Seems all fine.

The replication process does check file size and checksum of the files on master node and each storage node. In case they don’t match the replication deletes the file on the storage node and resyncs that file over. So in general there shouldn’t be a case where replication is “stuck” with one file not in sync even if it was broken half way.

@tesparza said in Computer not communicating with FOG client. Errors in Log.:

Response Invalid security token

Go to the FOG web UI and open the settings for this specific host you got the log from. Click the “Reset Encryption Data” button.

@mrp When we struggled with this I didn’t think as far as only using identifiers for deployment. I will see what I can do when I get back from my holiday in a couple of days.

@robertkwild I don’t think there is an easy and general way of telling the BIOS/UEFI firmware to boot from CD, DVD, USB key or other alternative boot options. Chainloading to the local disk seems to be a special thing that can be made to work. Though we also see that it does not work in all cases.

https://forums.fogproject.org/topic/14501/new-snapin-cannot-change-directory

@jmeyer said in Fresh install debian 11:

Yes. I’m an running Debian on a Qnap with Container Station.

Have you ever had FOG running on that before? NFS can be an issue in container virtualization. It definitely is on Proxmox when you use the default settings. I don’t know about Qnap.

@mrp No, unfortunately have not found enough time to work this out. But I have it on my list and will get to it in the next two weeks I reckon.

@Testers @Moderators Anyone here using HP Probook XXX G8 devices who can confirm this being an issue? The next step would be to compile iPXE from the latest source (we provide a script for that) and then talk to the iPXE developers.

@altitudehack said in unusual network traffic to/from fog client:

 11/3/2021 7:27:59 AM Client-Info Client Version: 0.11.19
 11/3/2021 7:27:59 AM Client-Info Client OS:      Windows
 11/3/2021 7:27:59 AM Client-Info Server Version: 1.5.9.98
...
 11/3/2021 7:28:00 AM ClientUpdater ERROR: Update file is not authentic
...

Any suggestions on how to address the root cause in case other clients are affected?

Your FOG server is on a pretty recent version but the fog-client is not. Unfortunately our certificate for digitally signing the SmartInstaller binary ran out about a year ago and since then the auto-update from 0.11.19 (and older versions) to 0.12.0 is not possible.

So you might just download the fog-client installer (either within the FOG web UI or from github) and manually install that on machines having that issue.

@madeyem said in FOG deploy: partitions 4 and 5 too big for disk:

...
/dev/nvme0n1p5 : ... name="attrs=\x22RequiredPartition GUID:63"
...

Wohoooo, it still has that same name/attrs problem. No idea why as I thought I had fixed that.

Edit: OMG, after some more digging I found that the change I made and committed to github didn’t make it into the test init I updated a few days after I asked you to test. My fault, because I work on another issue with someone else using the same test init. I am sorry. Please download the latest init from github once again, re-capture the image and we should see it work this time I am fairly sure. Pay attention to the Init Version: 20211107

@Gameman @george1421 The wording (“bug”) kept me from looking at this for a while now. Found a bit of time to look into this and I think it’s not a bug really. When editing an image definition there is no drop down for “Storage Group” but a whole new settings tab for this (right of “General”). Here you all should be able to assign images to different storage groups as you wish.

Though I have to admit that it might be a bit of a challenge to find this. Not sure why it was designed like this in 1.5.x.

@george1421 @Pilar I moved your posts about disk space and all that to the other topic: https://forums.fogproject.org/topic/15904/repositorio-de-imágenes-duplicado

Somehow just saw the logs you posted…

2021-12-07 12:01:33 0 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibtmp1 failed with error 28
2021-12-07 12:01:33 0 [ERROR] InnoDB: Could not set the file size of ‘./ibtmp1’. Probably ou t of disk space
2021-12-07 12:01:33 0 [ERROR] InnoDB: Unable to create the shared innodb_temporary
2021-12-07 12:01:33 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
…
2021-12-07 12:01:38 0 [ERROR] Plugin ‘InnoDB’ init function returned error.
2021-12-07 12:01:38 0 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2021-12-07 12:01:38 0 [Note] Plugin ‘FEEDBACK’ is disabled.

Is this the most recent log entry?

What I found is this: https://stackoverflow.com/questions/59029267/mariadb-error-on-startup-keeps-restarting

While it’s very similar from the log messages it has the error “Unknown/unsupported storage engine: InnoDB” which you don’t have.

Well could still be a disk space issue but from what we have seen in the output of df -h (reference) it doesn’t seem to be the case here.

@nockdown Ok, then we have one more option, the so called CAPTURERESIZEPCT. Open the FOG web UI -> FOG Configuration -> FOG Settings -> General Settings tab. Increase the default value of 5 to maybe 8 and then try capture again.

@nockdown Please try updating the FOS init as suggested below.

Even though you might think it’s exactly the same error it’s still helpful to take a new picture of that and post here. More often than not we find very important information in those pictures that you might not know about.

@nockdown Taking another look at the pictures I see this is not happening within partimage/partclone but earlier when partitions are being shrunken.

Therefore switching to partclone won’t help you I reckon. I still think it’s good to do if you don’t have a specific reason to use partimage.

For updating to the latest FOS inits run the following commands on your FOG server command shell:

sudo -i
cd /var/www/html/fog/service/ipxe/
mv init.xz init.xz_old
wget https://github.com/FOGProject/fos/releases/latest/download/init.xz
mv init_32.xz init_32.xz_old
wget https://github.com/FOGProject/fos/releases/latest/download/init_32.xz

No reboot of your FOG server needed. Just PXE boot the machine into the task again. If you still run into an error please take a fresh picture and post that here.