@nockdown OK, while 1.5.8 is not new it’s still good to try out the latest FOS inits. This is what you see booting in the machines when you schedule a task and PXE boot it.
I can imagine using partclone might be enough but if you still run into an issue come back and we’ll tell you how to get and install the latest FOS inits.
@nockdown From what you write and what we see in the pictures you are using an old version of FOG. Which version do you use exactly?
I suggest you update to the latest version and then try again capturing again.
Image Manager - Partimage
Any reason you use Partimage? It’s the “older” tool while Partclone is the newer one.
@nockdown said in Error(5): Could not map attribute 0x80 in inode 23779: Input/output error:
As I understand this option impacts to partition shrinking and so to image size. Am I right?
Yes. Although it’s probably increasing the size of the image files on the server only by a fraction. Not to worry about I reckon.
@Jacob-Gallant I looked at the PCAP for quite some time now. We see clear signs of “network congestion” - meaning that packets are being re-transmitted causing the TCP connection to slow down.
The connection starts just fine and the host sends a file read request to the FOG server. Now the FOG server starts to send a first large packet. Standard ethernet MTU is 1518 bytes and the FOG server sends 7240 bytes in one single TCP packet - a so called jumbo frame.
So I am wondering if you can improve speed by disabling LRO (Large Receive Offload), TSO (TCP Segmentation Offload) and GSO (Generic Segmentation Offload) using ethtool. Schedule and boot into another debug deploy session. On the shell run:
ip a s
ethtool -K eth0 lro off
ethtool -K eth0 tso off
ethtool -K eth0 gso off
The first command is just to confirm the network interface name (could be eth0 or different) to use with ethtool later on. You can try disabling all three at once or just one and give it a try.
There are various I219-V cards/chips listed with different PCI IDs. Searching with 8006:15fc I couldn’t find much on the web but searching for I-219V there are a few people complaining about issues:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1802691
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1785171
https://forums.linuxmint.com/viewtopic.php?t=327435
https://access.redhat.com/solutions/3615791
Though I am really in doubt if any of those match your exact situation.
@george1421 said in Install FOG on Ubuntu Server 21.10 issues:
I have a concern about supporting these non-LTS releases since they have a 6 month support cycle by the vendor. It seems like we are constantly chasing our tails here with the rapid release cycle plus supporting 5 or 6 different distros. Not to mention maintaining support for old LTS releases towards the end of their life. You are already validating 20 discrete OS’ now.
You make a very good point here. I was long hoping to get this solved by re-working the installer scripts to use as little as possible (or even better no) package version information. As far as I can remember most of the problems we see with newer OS versions is that we need to update PHP version numbers. Sure there are some seldom cases where package names or contents changed to cause trouble but I reckon it’s mostly the version issues.
Up until yesterday I though we probably never get to re-work the installer scripts intensely enough to get rid of that but here might be sun rising: https://github.com/FOGProject/fogproject/issues/450
@BURUGUDUY Not sure if there is a missunderstanding of legacy BIOS and UEFI. You can’t just switch the iPXE binary between UEFI (*.efi) and legacy BIOS (*.*pxe). As you can see in the dhcpd.conf posted the FOG installer generates a configuration file valid for several different PXE client vendor classes/architectures. Sure you can fiddle with those, e.g. change from the default for legacy BIOS undionly.kkpxe to ipxe.pxe but switching over to an UEFI binary will surely cause you trouble.
Not all iPXE binaries can be use on each and every machine/VM. As you’ve seen in your case intel.efi did the trick. Some machines only work with snponly.efi. I suggest you play with those in your dhcpd.conf directly. Take a backup copy of that file when you have your prefered settings.
Once again, don’t mix up UEFI and legacy BIOS as it will cause trouble sooner or later.
@ricotty said in fog management console is blank:
In this case, what is the the most or better linux edition for install and use Fog ?
You might want to take a look at @Wayne-Workman’s great install stats as well as the latest auto installer tests. You can add AlmaLinux 8 and RockyLinux 8 to this list as I have tested those manually lately using dev-branch.
@wt_101 said in Fail to mount during image deployment:
1024-65535/udp
I think the issue is here. NFS used TCP high ports. So you’d need to ask for 1024-65535/tcp as well. Though obviously this would render a firewall more or less useless.
If you can’t open the firewall then you might get involved in FOG development and help adding NFSv4 or other solutions like sshfs more quickly.
@george1421 I think the kernel arg should be noapic, right?
@rude26 said in could not boot: exec format error:
can i just drop this file in the correct place?
Yes for the binaries itself but no for the checksums. The script is made to always re-download the checksums to make sure it would pull a newer kernel/init file even if an older one sits there in the tmp folder. I know this is not great for the situation you are in right now.
Are you ok with editing shell scripts? That way we could help you get around this. https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L2422
The other option I can suggest is downloading kernel/init binaries and checksums plus the fog-client binaries and host those on a local mirror for the moment. Just put in “github.com” to your /etc/hosts.
@rude26 Well done!
May I ask you to use separate topics for each issue you want to talk about. No trouble on the unclean NTFS stuff here. We just try to keep things sorted in the forums so others find information and help more easily.
@tesparza Thanks for the details. Will look into this.
By chance we might have someone else who just reported the same thing: https://forums.fogproject.org/topic/16039/fog-client-not-auto-registering-hosts
Though I am not sure this was fixed in the developer version already. Stay tuned.
@lebrun78 said in https, with home certificates and boot.php… No such file or directory (http://ipxe.org/2d0c613b):
./installfog.sh -C -K
I really hope you don’t use the fog-client software as re-generating the internal CA will break all communication to the fog-clients.
I modified /etc/httpd/conf.d/fog.conf with…
This will be overwritten as soon as you re-run the FOG installer. I know this part of FOG needs some more attention but I can’t find the time to get into all of this. So I lost track of the SSL stuff a few weeks ago. Will need to work on the wiki article about this again: https://wiki.fogproject.org/wiki/index.php?title=HTTPS (this is not ready-set-go yet)
I tried to generate a new ipxe configuration
cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/
./buildipxe.sh
You will need to specify your CA cert on the command line when building and manually copy the binaries over after that, e.g.:
cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/
./buildipxe.sh /etc/httpd/cert/DigiCertCA.crt
cd ../../packages/tftp/
find -type f -exec cp -Rfv {} /tftpboot/{} \;
@george1421 @TaTa Even the latest dev-branch version is not compatible with PHP8 yet. You might want to give the dev-branch-php8 branch a go. But this is really new and not tested much at all.
@JYost Updating to 1.5.9.111 is one way but you can also just update the FOS init.
In the picture we see you’re still using the FOS init that was released with FOG 1.5.9. This init definitely has issues with newer 20H2 (and also earlier version I think).
To update the init just follow these commands (run as root on your FOG server):
cd /var/www/html/fog/service/ipxe/
mv init.xz init.xz.orig
mv init_32.xz init_32.xz.orig
wget https://github.com/FOGProject/fos/releases/latest/download/init.xz
wget https://github.com/FOGProject/fos/releases/latest/download/init_32.xz
Try a new capture and pay attention to the “Init version” that is shown on bootup. Should be newer than what we see in the picture now.
@george1421 said in Ubunutu Server 21.10 Install Fail:
Now after you get FOG 1.5.9.110 or later installed, go into the FOG Web ui and download the latest FOS Linux kernel.
Just want to mention that FOG dev-branch will install the latest kernel directly. No need top manually do that.
@matthieu-jacquart said in Change IP fog Server : unable to change Node storage and TFTP IP:
Do I have to use –recreate-CA and –recreate-keys after I change ip ?
No, you should not have to so this. The installer will regenerate the certificate nevertheless but it won’t touch the CA - which is not the same thing!!
@TaTa The default NFS in FOG is still version 3 which has no concept of user authentication/authorization. Sure you can try to lock things down a bit by setting access rights on the FOG server filesystem.
But if you want to go beyond that you will need to look into NFSv4 which is not implemented yet: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3
@rogalskij said:
On my 1.5.9 server you can absolutely see the AD password. It is blanked on the setting itself, but if you go into a host and click the “join domain” you can see that password in plain text no issue.
Well that’s a different story. Good you are pointing this out because I didn’t see the forest for the trees. If you click the checkbox Join Domain after deploy it fill pull the global AD settings (FOG Configuration -> FOG Setttings -> …) and apply those to this host. You are right, someone can find the password this way. We shall fix that soon (reopened #337).
@george1421 Not sure I get what you mean. We already have the password hidden and a button next to the field to show it in clear text. You are still using FOG 1.5.7 in your productive environment, right?