@Karrade said in Server information error?:
I was also changing httpd settings and restarted it and php-fpm
What exactly did you change?
Check the logs and post here (see my signature…).
@Karrade said in Server information error?:
I was also changing httpd settings and restarted it and php-fpm
What exactly did you change?
Check the logs and post here (see my signature…).
@Critchleyb Not sure what else we could advise. We have tuned things a fair bit but still you seem to have clients drop out of multicast fairly often. Are you good with network analyzing using Wireshark? Don’t really think you’ll find something causing this in your network but it might be worth a try having a look.
Maybe crank up --retries-until-drop
to values like 1000
. But on the other hand a slow client will just pull down the speed for everyone else.
Something that might be causing such dropouts could be network driver issue. Are all the clients you have cloned in the last batch exactly the same? What network cards do they have? Exact model? If it turns out to be a Linux network driver issue that might explain things.
@astrugatch said in Active Directory after image deployment not working.:
If I am installing FOG for the first time (as opposed to upgrading) and I enter the DNS name as part of the new installer and having the CA generate a cert with the DNS/hostname does HTTPS become the default.
Ahh, now I get you. No haven’t changed the default to be HTTPS as it would involve compiling the iPXE binaries as well. Think that is the next step. I will consider removing the iPXE binaries from the repo and simply rely on compiling them on each install altogether. iPXE code is usually fairly stable. What do you think @Tom-Elliott ?
@astrugatch said in Active Directory after image deployment not working.:
If you fill out these values during a clean setup does it make default FOG to https?
What do you mean by that? What values? Clean setup?
@bmorine I am sorry we’ve left you with this but I have not found the time to really look at it yet.
assigned the snap-in to hosts in group temporarily and then tryed deploying the snapin and it worked.
You mean assigning the snapin to each host individually by hand? Did you deploy for the whole group or as well individually for each client?
@maxcarpone Unfortunately our build server seems to play up. Has not started building yet and I am not sure why…
@sgennadi This is specific to your hardware I suppose. Have you tried on a different PC (a bit older model)?
As George said, please take a picture of the error and post here.
@Dee said in Apache2 error-Won't download-We're DOWN :
It would be nice if there was something in the Forum about what files can safely be removed unless I missed it.
It all depends. Never know if you need files from 1.4.2 at some point. I suppose you don’t, there should be no need to keep but I don’t want to phrase this as an official statement. Take a look at the folders and decide yourself if you think you might need those later on.
@AndrewG78 Having thought about this for a bit more I think this can be achieved without too much of trouble. I would suggest to not run dnsmasq service on all your FOG servers but have one FOG server designated as master proxyDHCP (dnsmasq). This way you don’t even need iptables to filter the packets. I played with the dnsmasq config a bit and came up with this:
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# make dnsmasq act as proxy server
dhcp-range=192.168.2.7,proxy
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1
dhcp-userclass=set:ipxe,iPXE
dhcp-match=set:ipxe,175
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
dhcp-mac=set:team1,F0:DE:F1:EB:02:E0
dhcp-mac=set:team2,F0:DE:F1:EB:02:E1
# Team 1
pxe-service=net:team1,net:!ipxe,x86PC, "Team 1", undionly.kpxe, 192.168.2.7
pxe-service=net:team1,net:!ipxe,IA64_EFI, "Team 1", ipxe.efi, 192.168.2.7
pxe-service=net:team1,net:!ipxe,IA32_EFI, "Team 1", i386-efi/ipxe.efi, 192.168.2.7
pxe-service=net:team1,net:!ipxe,BC_EFI, "Team 1", ipxe.efi, 192.168.2.7
pxe-service=net:team1,net:!ipxe,Xscale_EFI, "Team 1", ipxe.efi, 192.168.2.7
pxe-service=net:team1,net:!ipxe,X86-64_EFI, "Team 1", ipxe.efi, 192.168.2.7
dhcp-boot=net:team1,net:ipxe,filenotneeded,,192.168.2.7
# Team 2
pxe-service=net:team2,net:!ipxe,x86PC, "Team 2", undionly.kpxe, 192.168.2.4
pxe-service=net:team2,net:!ipxe,IA64_EFI, "Team 2", ipxe.efi, 192.168.2.4
pxe-service=net:team2,net:!ipxe,IA32_EFI, "Team 2", i386-efi/ipxe.efi, 192.168.2.4
pxe-service=net:team2,net:!ipxe,BC_EFI, "Team 2", ipxe.efi, 192.168.2.4
pxe-service=net:team2,net:!ipxe,Xscale_EFI, "Team 2", ipxe.efi, 192.168.2.4
pxe-service=net:team2,net:!ipxe,X86-64_EFI, "Team 2", ipxe.efi, 192.168.2.4
dhcp-boot=net:team2,net:ipxe,filenotneeded,,192.168.2.4
You can have as many “team definitions” as you want and can assign clients via MAC address to any one team you want them to be in. The only thing you need to adapt is the IP addresses, search for 192.168.2
in the conf file and adjust to your needs.
Simply add new hosts to your dnsmasq config and they should perfectly register with the FOG server you teamed it up with.
This is a first proposal. Sure you could generate the dhcp-mac=
definitions from the database. It would also be possible to add more dnsmasq foo to direct unregistered clients to a special PXE menu where you could choose which team it belongs to and send it off to register on a particular FOG team server. Sure it need some modification of code to achieve that but I am sure it can be done.
@Critchleyb Have you done several runs? Is it always the same clients having the issue? Are they all on the same switch?
You might want to try setting the sysctl parameters on the clients as well. For that edit /images/dev/postinitscripts/fog.postinit
and add the systcl calls at the end of the file. Make sure that file is executable chmod +x /images/dev/postinitscripts/fog.postinit
, start a new multicast task for your clients and boot them up.
Merged the changes, should be building new inits now. @maxcarpone Will let you know as soon as they are available for download.
@Abuelika Not need to say sorry or even delete the post. It’s perfectly fine to ask and I think it’s great to have this here in the forums so others might find it and can help themselves as well.
@AndrewG78 @george1421 I started adding the refind 32 bit stuff but then saw that I have a couple of open questions hanging. So I just opened a new feature branch for that and pushed the first proposal of code changes - see here. This way we can discuss things and I can make further adjustments before actually merging this back into dev-branch
.
refind_x64.efi
- any suggestions why this would harm anything?@6rilT I am sorry but the wiki and forums are as much of documentation we have. Read through the code and you sure will figure it out.
@svalding Did you ever get this solved? rEFInd 0.11.4 is out and you might give it a try.
@JJ-Fullmer Ohhhh my …, must have lost track of this in the middle of a hectic months. Sorry! Do you still have those devices at hand to test?
@DarkSwordsman And here is another idea. Possibly the scan_for
option if causing the hang on blinking cursor. Not sure why but possibly it is. Maybe try setting this to manual
only and add a menu section at the bottom of your config - see here:
menuentry "windows" {
volume 0:
loader \EFI\Microsoft\Boot\bootmgfw.efi
enabled
}
Make sure you comment all the other pre-defined menu sections and set default_selection 1
to choose this entry for you.
In that same post it’s also mentioned that rEFInd 0.11.2 (current at that time) was not working on a specific HP workstation. Reverting back to verison 0.11.0 helped. Maybe another try. You see there are lots of options and sure one will get you beyond the blinking cursor.
@DarkSwordsman said in Auto Deploy restarts PCs, but boots back into Windows:
I just tried booting into http://10.1.0.50/fog/service/ipxe/refind.efi from the ipxe CLI and it came to the same blinking cursor icon.
To me this sounds as if this particular machine / UEFI firmware is having an issue. I don’t think it even gets as far as loading any Windows components at all!! Have you updated the UEFI firmware to the very latest version?
Maybe try booting rEFInd from a USB key just to see if that ends up in the blinking cursor as well: Format a USB stick with FAT32, create directories EFI\BOOT
, download the refind.efi binary from your FOG server, put onto the USB key as EFI\BOOT\BOOTX64.EFI
and add the refind.conf
(you were talking about refind_efi.conf file?!?). Now try booting from this USB key and see what you get.
If that doesn’t work out you might want to try loading the 32 bit version of rEFInd (refind_ia32.efi) found in the official archive.
PS: There is no way around it. You need to stick to it and try different things to figure out why it is not working.
@Beber55 Ok, permission error was missleading, nevermind.
You need to edit the file: nano /etc/default/tftpd-hpa
Now make the change, save (ctrl+o), exit (ctrl+x) and then run the other commands to restart and read log file as suggested earlier.
@hancocza Try using TRUST=gdroot-g2.crt.pem,gdig2.crt.pem
https://certs.godaddy.com/repository/gdroot-g2.crt
https://certs.godaddy.com/repository/gdig2.crt.pem
I think you need to convert the gdroot-g2.crt to PEM format. I read that iPXE can only handle PEM but not DER cert format. Convert using openssl x509 -inform DER -outform PEM -text -in gdroot-g2.crt -out gdroot-g2.crt.pem
You might want to check the whole chain using openssl as well: openssl verify -CAfile gdroot-g2.crt.pem -untrusted gdig2.crt.pem fogcert.pem
all untested…
EDIT: Posted on the iPXE developers mailinglist: http://lists.ipxe.org/pipermail/ipxe-devel/2018-December/006395.html