@Sebastian-Roth
I think to know what is blocking.
I have to change vlan and fog IP adress to make updates but it use IP parameter in the updateDB() function :

wget --no-check-certificate -qO - --post-data="confirm&fogverified" --no-proxy ${httpproto}://${ipaddress}${webroot}management/index.php?node=schema >>$error_log 2>&1

@ordinatous You mentioned you have the fog server on esxi. Is putting your image vm on esxi an option? That’s where I keep mine and it works rather well. I just keep it turned off when it’s not being configured and captured.

@brakcounty A 6.1.22 test kernel is available on Github. Be aware those kernels are untested so far. I dod not have the time to even do the simplest bootup test.

@Fog_Newb Here you go: https://github.com/FOGProject/fos/releases/tag/20230331

Be aware those kernels are untested so far. I dod not have the time to even do the simplest bootup test.

FOG 1.5.10 was kind of re-released (technically just re-tagged on Github) just now to patch issues causing trouble when updating from an earlier version with the location plugin enabled.

@george1421 All those binaries are shipped with FOG and installed by default - see the list of ipxe binaries on github.

It’s more or less a question on which binary we make the default when generating the dhcpd.conf - which obviously not everyone is using anyway.

@dimoura At the risk of repeating myself, someone needs to make a commitment to maintain the docker image. This is not going to happen if everyone keeps asking for others to do it.

@jblomquist said in Is there a way to restrict FOG menu access to specific users?:

I’d like to allow a particular user to be able to deploy an image, but not quick delete a host through the PXE menu.

Which version of FOG do you use?

The quick delete option is secured in the iPXE menu in FOG 1.5.10 (github commit).

@AlexPDX said:

i see u did not find the time to fix the M.2 NVMe problem 😐 …and the Storage Nodes being Unauthorized 😐

No, we haven’t yet. You are very welcome to get involved and help fix this stuff.

@JJ-Fullmer said in HP EliteBook 840 G9 - Cannot deploy image:

So at different points in the process of pxe boot, it gets a different mac when pass-through is enabled, I’d expect it to always use the passed-through mac.

Unfortunately there is not much we can do about it if we stick to relying on MACs as the (only) source of identifying hosts. This happens because FOG uses different “compontents” for the PXE booting and imaging process. The PXE menu (and first host recognition) happens with iPXE while when registering/imaging the Linux kernel is doing the job. Each using their own drivers and they can behave differernetly (not have to). Especially the USB adaoters and MAC pass-through bring up this as an issue more and more.

Probably someone with more time in the next months needs to dig into this old Github issue and give it a go: https://github.com/FOGProject/fogproject/issues/198

@george1421 I’ll be damned, pardon my french.

So I guess I was just not patient enough. You guys were right, the acpi error has nothing to do with this other than distracting it from the real process.

After changing the log to level 7, I noticed at some point it says its resizing right before the acpi errors take over. I realized its not stuck, its just taking a while to proceed bc resizing always takes a little longer when capturing image.

So I just let it sit there and eventually it proceeds on capturing the image. It doesn’t look pretty with all the acpi errors but it still does what it suppose to do.

Thank you @george1421 and @Sebastian-Roth for helping on this.

@Sebastian-Roth Challenge accepted!😁

@Sebastian-Roth Just an FYI, I ran into this again on different hardware. An HP Z2 G4 Workstation did the same thing.
There may have been more to it though, still troubleshooting a bit. My failsafe in the postdownload script to have it still join the domain through the unattend file was injected into the file, but the computer did not join the domain through that method, there may have been a different reason for that though.

Point being, there could be other hardware that weirdly doesn’t get all the variables. I sadly can’t super test on this hardware as I discovered it when imaging a production machine that I can’t take out of production for testing. But I can probably find a chance to get the fos level device info or something.

As a side note:
The image type description in the wiki (I got there from the balloon help: https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images) points to a non-existing page (404): https://docs.fogproject.org/en/latest/management/image-management.html

Thanks! @JJ-Fullmer would you find the time to fix that quickly?

Fixed!
@medchemii thanks for letting us know. We changed the structure of the new docs page a bit and it affected the links. We’re working on getting redirection working for old links still

Hello SERR,

Did I understand correctly all what i need in settings is set multiple partition image - all disks?

Depending on your operating system and the hardware you use this is true. If all of the PC’s have the same hardware, it should work. Of course you’ll have to take care of the licensig of the operating system if you don’t use Linux.

If you don’t have the same hardware and you want to deploy Windows you should create a golden image and think about driver injection.

And can FOG deploy from image correct ssd - ssd and hdd - hdd (i have this issue from clonezilla sda was cloned to sda but disks can not correct plug in motherboard)

I capture the images inside a VM and deploy to ssd and hdd. I don’t think that there should be a problem. Also cloning an old hdd to a new ssd via dd or ddrescue never caused a problem for me.
If you want to copy it to a different computer with different hardware it could be possible that drivers were missing. But I never used clonezilla, so I’ve got no expierience there.

And so i interested of speed of deploying to PCs (i want to deploy for 5 pc simultaneously). All network is 1G

Fog supports multicast sessions suited for larger groups of computers. I deployed my image to about 10 PCs over 1 GB network without multicast and it was really fast enough for me, but I did not take the time. It definitely was faster than I thought it would be.

@Sebastian-Roth said in Windows Keys Management Plugin:

overwrite each others settings

Yess…this was the cause …i’ve uninstalled the plugin and now all seems ok 🙂
10x dude 💪

@Punti I have never seen this error before. Doing a little search engine foo I came across this topic where they talk about an issue in the GnuTLS libraries used by git and that the whole issue was magically fixed (by Github?) in the end: https://discourse.pi-hole.net/t/error-git-remote-https-died-of-signal-4/56558/17

Though on the other hand this is really strange because I did give it a try in my Ubuntu 20.04 test machine and it does not run into the same problem. Maybe this really is a temporary Github problem??

@ITSLUIGICASALE said in How to setup multi-site fog:

I’ve made some work on this, but replication seems to hang many times

Can you be more specific on why you think the replication hangs? Best if you can lost log files to proof what you think is happening.

@fagner-patricio OK so you have the latest version of the kernel. So lets debug a bit more.

Manually register this computer with FOG. You will need the mac address of the network adapter. You will create a host definition file with this action. Connect the host to an image (doesn’t matter which one at the moment as long as it exists).

Now schedule a deployment task to this computer. But before you hit the schedule task button, tick the debug checkbox. Now schedule the deployment task.

PXE boot the target computer. The computer should go right into imaging and not stop at the fog iPXE menu. After a few screens of text that you have to clear with the enter key you will be dropped to the FOS Linux command prompt on the target computer. NOTE: You will probably see the same errors as before, but in debug mode it should let you get to the command prompt.

Now at the FOS Linux command prompt key in the following.

ip a s
lspci -nn | grep -i net
grep -i firm /var/log/syslog

Snap a clear picture of the output and we will decide the next steps.