@mesaman0182 Thanks to @Tom-Elliott this is fixed in dev-branch. So if you want to install FOG on Ubuntu 21.04 you just need to use the latest dev-branch version from github.

@tom-elliott said in Dev branch 1.5.9.79 Installing package: php-gettext.............................Failed! has to use -X switch to get it to work.:

in my testing language translation worked properly using the common provided version

Then it’s all fine. Good that we don’t need that extra package anymore!

@george1421 That makes sense, thanks!

@rotoi Are you still running fog 1.3.3? More specifically you updated the kernel to something more modern, but have you touched the init.xz file? FOG 1.3.3 doesn’t (shouldn’t fully) support NVMe drives. The NVMe protocol wasn’t created until much later than FOG 1.3.3. Its akin to trying to install Windows 95 on an 11th gen laptop. It would kind of work, but not really well.

@george1421

By and large I agree with you about the hash algorithm being irrelevant, however, some entities have requirements for minimum acceptable hashing for such kind of verification. I think a baseline of a choice between md5 and shasum baseline is fine, especially while development of the feature is ongoing (md5 is still widely used in forensics), however that will not always be the case and building support in for additional options might be better. The time cost involved is something the end user should accept when they select the additional complexity.

Just as a test, I timed sha 512 on my Windows 10 image. Here is the results:

Took about 2m 8s for 8 GB give or take. So the wait isn’t terrible at higher algorithm complexity. This test was done with a two virtual processor VM on a server with a bunch of other vms running.

Interestingly enough, the shasum utility on ubuntu can compare hashes to a text file for verification.

Also, I don’t think the hash need be taken inline with the imaging process, but be done post imaging, either on demand, or run in background automatically before image is made available for distribution.

Thoughts?

@george1421 I was asking for the suggestion made by @fogman4 which seems to be focused on Ubuntu, with a large amount or ram set for ramdisk

@cf20corvuss Well lets think about this for a minute.

The screen shot you provided looks like the fog ipxe boot loader. If it is we can then make a few assumptions. My hesitation ATM is that some hypervisor’s use iPXE as their pxe boot rom (Virtual box being one). If we work under the assumption that the screen shot shows the FOG iPXE boot loader we know this.

The target computer can speak to the FOG server. We know then because the iPXE boot loader was sent by the FOG server and received by the PXE booting computer. The target computer is getting a dhcp address from some place AND that dhcp information told the client where to get the iPXE boot loader from. So we know that dhcp is working. We know that iPXE has the proper driver for the network card in the pxe booting computer because iPXE sees the mac address of the network adapter.

Where we typically see this is with the network configuration where Spanning Tree is enabled but one of the fast spanning tree protocols are not used. Standard spanning tree will listen for a loop back interface for the first 27 seconds a link is active then start forwarding data. With imaging when the PXE ROM hands off control to iPXE, iPXE will reset the network interface causing the link to drop briefly as iPXE boots. Well this link briefly dropping causes the spanning tree counter to reset. So when the target computer is trying to get an IP address again, spanning tree is still listening for a loop back. By the time standard spanning tree starts forwarding data again, iPXE and FOG have already given up.

You can test this in a physical world by putting a dumb unmanaged switch between the building network and the pxe booting computer. This unmanaged switch will keep the building switch from seeing the brief link drop. Most cheap switches do not support spanning tree. So its all good there.

Now NAT and imaging do not go together with FOG. Everything needs to be bridged with real addresses for FOG imaging to work.

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

Yep. The only thing I can figure is that somehow either the DHCP Relay or Arp Proxy in Pfsense is doing something weird, or the DHCP server is not processing my second range definition in its entirety (which is weird because booting into an OS proper, the exchange happens normally and gets the right settings).

Although in the mean time I have had to move along in my research so I moved the DHCP/ Bind DNS to PFsense and have configured it to have the correct options. EFI boot from fog server is working in this new configuration. I am leaving the existing configuration in place on the fog server though to return to this issue (which I think has value to try and solve).

@sebastian-roth
I was able to figure it out - when I made the vm that I took my image from my fog-server address was different as I installed it many times trying to get it to work.
The machine I captured the image from had the fog-client pointed to the old server, once I removed the fog-client and reinstalled with the FQDN it did the trick.
Thank you

@DiscoNaut While you surely can mess with the port in the Apache config I am fairly sure this will break some of FOG’s features like wake on LAN, snapins and maybe even PXE booting. Will definitely take some manual adjustments in files in the FOG server to get this somehow working.

What’s your intend in doing this?

@lee-rowlett I would be very interested to see how this could be achieved. I have 1000 Lenovo devices and I would prefer to not have secure boot reconfigured on all machines…

Thanks @tom-elliott . So, if I understand correctly, I only use the first one and it must not be encrypted, am I right?

@sebastian-roth The kernel update works now and image capture is successful.

I’ll start a new topic on the networking issue.

Thanks Sebastian!

@arowana Does your remote site have a server where you can preposition these dependencies files? Remember for windows the script or installer runs as a windows user. The fog client runs these snapins as SYSTEM which has admin rights on the local computer where the snapin is being installed. Your install script can map a drive to a windows file share and copy the files over smb to the target computer. That would be the easiest. If the files were stored at the remote site then it would not impact your metered connection rates. If you used a powershell script to install your application you can use a function similar to curl or wget to download the file from the internet using scripting. You might be able to use FTP too, but I have never tried. You don’t need to specifically download from the FOG server, but you can. If you wanted to download from the FOG server, I would setup a new user on the FOG server that has very limited rights, maybe to read only from the source directory and that is all. I would not use the FOG ftp user because that has more authority than what is needed here.

@Afernandes Just updated the FOG kernels to 5.10.34 and included the firmware as requested. You can keep using the kernel George provided or update to the latest as you like.

@sebastian-roth or the web items are being compressed, but not decompressing for display.

@jonathanho92 said in Help in deleting image in fog server:

When i try to click delete they prompt me for credential i am not sure which credentials to key in to delete the image

That’s the same credentials you use to login to the FOG web UI. It’s just a safety thing to prevent people from deleting image files in a rush.

@jbandy Edit C:\Program Files (x86)\FOG\settings.json on the client machine. Then restart the service called “FOGService” or the computer.

@jbandy said in SSL Issue srvpublic.crt:

... "GET /fog/management/other/ssl/srvpublic.crt HTTP/1.1" 302 631 "-"

What we see in all those access log line is status code 302. So really, each and every request is not being answered directly but redirected.

Maybe this is something special Ubuntu is doing to push SSL/HTTPS forward? I am not sure. To try and see where this is coming from we need to start digging through the apache configs. First post the contents of the file /etc/apache2/sites-available/001-fog.conf here in the forums.

How do you change the url it’s using to communicate?

Edit C:\Program Files (x86)\FOG\settings.json on the client machine. Then restart the service called “FOGService” or the computer.

@george1421 said in iPXE iso vs iPXE FOG:

Something isn’t working as we know it should.

I’m going to try and find a second PC with the same motherboard to test with but currently, they are all in service.