@sebastian-roth Ahh, I didn’t see that either. Okay, so in DHCP I changed the router to 192.168.22.1 and range starting IP to .20

In fogsettings, I changed both routeraddress and plain router from 192.168.22.11 to 22.1

The test client gets online just fine now.

Thank you again, Sebastian!

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

@john3892 Best if you open a new topic. Just cross link this forum post here as reference and then send all your details like FOG version, Linux OS/version, steps you took (in detail)…

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

@d2freak82 From the little information we have so far I would expect you run into the issue where Ubuntu started disabling TLSv1.0 and TSLv1.1 in the Apache configuration. Find more details on this here: https://forums.fogproject.org/topic/15151/fog-client-installation-error-cannot-install-ca-certificate

An updated and fixed fog-client installer is available: https://github.com/FOGProject/fog-client/releases/download/0.12.0/SmartInstaller_fixed-tls.exe

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

@lcsmd I see it has you have 2 different issues at the moment.

The mac address is changing between iPXE and FOS Linux. The image transfer stalling out loading bzImage (FOS Linux kernel).

You are able to get iPXE to boot so your chromebook has an i86 compatible processor in it (in the era of ARM you always have to ask).

Lets tackle the mac address thing first since hopefully that is the easiest. We have seen this in the past where the firmware bios has an option switch for “mac address pass through” This is where the laptop doesn’t have a physical network adapter, but contains a mac address for the physical adapter. The idea is that the built in mac address would overwrite what is in the USB dongle making the device have a unique mac address even if you are using a single dongle for all of your device. This is great and exactly what we would want in an ideal world. FOS Linux’s driver understands this pass through uefi request and honors it.

The problem comes in at the iPXE level, its drivers are not as advanced as linux so it only sees the mac address of the dongle and not the pass through address built into the tablet.

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

@tom-elliott
Big customers for me is institution or business who can donate this amount to support FOG.
I was thinking a bit more “big customers” who use FOG all days ~100. Maybe I aimed wide.
But you are right it’s just donation, and not bind for all years.

@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

Hi I run into the same issue trying to boot a linuxmint 20 (and also ubuntu 20). After some digging, it appears that the Unable to find a live file system on the network show up because do_nfsmount() from the casper script chipped inside the initrd isn’t able to mount correctly the nfs share.

I extracted (using unmkinitramfs) the nfsmount binary to test it standalone on a working nfs share using the same option provided by this casper script (nfsmount -o nolock -o ro ${NFSOPTS} ${NFSROOT} ${mountpoint}) which work well.

I also tried to use the initrd from a linuxmint 19 to load the linuxmint 20 iso and… it worked but without any big surprise I ran into issue while I tried to install the os.

The differences between mint19 and mint20 are some check performed after nfsmount call:

do_nfsmount from mint 20

do_nfsmount() { rc=1 modprobe "${MP_QUIET}" nfs if [ -z "${NFSOPTS}" ]; then NFSOPTS="" else NFSOPTS=",${NFSOPTS}" fi [ "$quiet" != "y" ] && log_begin_msg "Trying nfsmount -o nolock -o ro ${NFSOPTS} ${NFSROOT} ${mountpoint}" # FIXME: This while loop is an ugly HACK round an nfs bug i=0 while [ "$i" -lt 60 ]; do if nfsmount -o nolock -o ro${NFSOPTS} "${NFSROOT}" "${mountpoint}"; then if is_casper_path $mountpoint && matches_uuid $mountpoint; then rc=0 else umount $mountpoint fi break fi sleep 1 i="$(($i + 1))" done return ${rc} }

do_nfsmount from mint 19

do_nfsmount() { rc=1 modprobe "${MP_QUIET}" nfs if [ -z "${NFSOPTS}" ]; then NFSOPTS="" else NFSOPTS=",${NFSOPTS}" fi [ "$quiet" != "y" ] && log_begin_msg "Trying nfsmount -o nolock -o ro ${NFSOPTS} ${NFSROOT} ${mountpoint}" # FIXME: This while loop is an ugly HACK round an nfs bug i=0 while [ "$i" -lt 60 ]; do nfsmount -o nolock -o ro${NFSOPTS} "${NFSROOT}" "${mountpoint}" && rc=0 && break sleep 1 i="$(($i + 1))" done return ${rc} }

I tried to add some debug to identify what is going wrong but I couldn’t manage to “repack” the extracted initrd into a clean working one ending up on a kernel panic (I spend quite some time trying out, initrd archive structure seems to have recently evolve to chip intel and amd firmware inside). The only changed I made was adding some echo into the casper file. If someone manage to do so, it would be interesting to check what is_casper_path and matches_uuid does and return.

As I wasn’t able to produce a custom initrd, I tried to configure a http server to serve the iso on similar way as suggested on the comment bellow by @pacman366. But ubuntu/mint desktop iso are quite big (2GB) and 4GB ram isn’t enough to be able to extract the iso. I also tried to boot from http following these instructions: https://www.plop.at/en/ploplinux/live/networkboot-linux.html#pxel61 without any success. I’m not sure how | in the url work (no request received on the nginx web server).

I’d really like to be able to fix this, any idea/help would be appreciated

@george1421 said in One central FOG server plus multiple Storage nodes in different locations possible?:

You can only capture images to the central server. The storage nodes are deploy only.

This is the most important point I think. From what @tesparza said so far it sounds as if image capture to storage nodes is wanted.

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

@fogman4 This looks suspicious.

choose --default os.Debian.10.9 Live via ftp --timeout 3000 target && goto ${target}

The tag name should not have spaces. Looking at the actual menu item

param sysuuid ${uuid} :os.Debian.10.9_Live_via_ftp kernel tftp://${fog-ip}/os/debian/vmlinuz initrd tftp://${fog-ip}/os/debian/initrd imgargs vmlinuz initrd=initrd boot=live components fetch=ftp://${fog-ip}/filesystem.squashfs

I wonder if the underscores are breaking the default option.

:os.Debian.10.9_Live_via_ftp

They are translating to white space characters. Use dashes or dots in the tag name and see if that fixes it.