@amo862 said in EFI Chainloading Failure - Venue 11 x86:
However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?
Do what JJ Fulmer below said, that’s the best advice.
Also would still urge you to migrate.
In your head - you’re thinking the most easy path is getting your existing box back the way it was.
That’s not the easiest way - lots of unknowns that way. How to get the DB back the way it was without backups, what settings & things did the new installer put on the box that may not work with the old version, and whatever other problems your old server might have too. I don’t know.
But what I do know is how to migrate fog servers, and I know this really well. I wrote that article I linked to below, and if you follow it, it will work.
The most easy and shortest and most sure path is to build a new box and move stuff over.
@Jaymes-Driver said in Imaging Causes Phone Problems.:
Ahh yes, lovely QoS
Crap QoS. IPv4 itself is flawed. A large transfer doesn’t allow other packets through, it’s like a missile going down the wire. There’s been an integration recently into the Linux Kernel called fq_codl that solves this issue, it was authored by Dave Taht. If you used routers and switches that run using a new linux kernel, you can blast the network as heavy as you want to with as many streams as you want to, as many massive file transfers and imaging as you want to - with no configured QoS - and no seperation of services via VLans - and VoIP will be crystal clear - because the kernel will make room for the smaller packets to go through no matter what.
If you need QoS, then really you need a new network.
</rant>
@Tom-Elliott This appears to work for hashing the last 10 megs. Also works for files that are sub-10MB
[root@fog-server Acerbase]# tail -c 10485760 d1p1.img | md5sum
326ea3163c9bc3e202fa323e47f02b23 -
@MikeoftheLibrary said in FOG Imaging Doesn't Respect Max Client Setting:
the last time I tried it, it took 5+ hours for 5 computers.
Multicast performance isn’t really dependent on an awesome server - that’s part of the method. The server only sends one time and many receive.
Your problem is probably poor-quality network equipment you were using for multicast. Higher-end network equipment like Cisco Catalyst would not have these issues. The cheaper the network equipment, the worse multicast will be. It’s total-internal-throughput that matters. If you have an el-cheapo crap 10 dollar switch that is advertised as 1Gbps, it may only have 2 or 2.5Gbps total-internal-throughput. The max it can transmit in and out of all ports simultaneously at any one time. To truly take advantage of multicast, if your 1Gbps switch has 8 ports, it needs 8Gpbs total-internal-throughput. If it’s a 48 port 1Gbps switch, then 48Gbps of total internal throughput.
@MikeoftheLibrary After reading that, there’s another thing I forgot to mention. Each multicast session only goes as fast as the slowest host. So if one of them has bad RAM or a failing disk or bad patch cable, this would slow down every host in that multicast task. This could be your issue - and most likely is since you’re using business grade network equipment.
This is related to access controls, which FOG 1.x doesn’t have, not really. Options are fog mobile, or full admin. Access controls are something that are already part of the 2.0 rewrite.
I’d give them a mobile account and tell them what image to use.
@HaRD The steps to delay those services don’t include mysql, you would just add it into those steps.
Read what the lines say. First one disables FOGMulticastManager, FOGSheduler, FOGSnapinReplicator, and FOGImageReplicator. The next line disables nfs-server, next one disables rpcbind. You just need to add mysql to the list.
Same goes for /etc/rc.d/rc.local Just modify it to start mysql after 30 seconds too.
Also, this would be the first time I’ve ever heard of a timing issue with MySQL on CentOS 7.
There’s also this article about it: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
@george1421 we should get your sysprep shutdown piece into there too I guess?
@thequicken This last time around you appear to have configured the partitions correctly, from the command output everything looks in order. Please run the below commands that Tom posted, we will go from there.
@george1421 That will be overwritten the very next time he updates fog unless the blexports option in /opt/fog/.fogsetting is set to 0
You can edit this file with vi or nano and set that option to 0. This way the changes that George suggests will stick the next time you update fog.
Reference:
https://wiki.fogproject.org/wiki/index.php?title=.fogsettings#NFS
First, 1.3.5 has been officially released, you should update. It has lots of fixes in it - and this issue may or may not be fixed already.
Two, we need photographs of the error you’re seeing, or even video (upload to youtube) of the boot process so we can see what’s going on.
And, we need to know the model(s) of the hosts you’re having problems with, if they are in UEFI or BIOS/Legacy mode or not. Find out these things in their firmware.
After those things, we can help more.
@TTellez said in FOG Server host registration issues:
@Wayne-Workman Updated to the 1.3.5 official.
The Model of the host is a Dell E5570
Now that I have updated from the RC, it is asking me to enter the tftp server?
Usually, when the tftp server is requested, you have two or more dhcp servers serving the subnet and at least one of them isn’t configured correctly.
Follow along with George, he’s on the right path and more available than me.
@TTellez said in FOG Server host registration issues:
option domain-name-servers 127.0.1.1;
That is surely incorrect.
Do you have a good reason for using /images/fog ?
If you put it back to just /images does it work?
Also, I would strongly urge you to move to FOG 1.3.5, as 1.2.0 is quite ancient and incapable of supporting newer technologies. You may find this article of interest: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
@oraniko When a snapin or snapinpack runs forever, usually this means it’s waiting for input. And snapins are not allowed to receive input, nor interact with the end-user in any way.
So, to troubleshoot, Step back and start without even involving fog. Unzip all these files to somewhere - open an elevated command prompt, cd to the directory and run setup.exe and see what happens. If it doesn’t “just go” without asking for any input whatsoever - then it needs work. Once you have it “just going” without any help, take that work and those commands and make a snapin or snapinpack with them. The links I posted below are full of resources & ideas.
We just need to troubleshoot.
Are you using the FOG Client?
Where is the reboot happening, exactly? What’s going on just before?
Can you capture an image without sysprepping, and deploy that successfully?
The boot file isn’t the problem here, I think.
@Avaryan said in FOG Client Service Not Starting Automatically:
Reason: cause we’re still on a old version and I don’t want to reupload the image when we update FOG.
You can have an old version of the client in your image - this is perfectly fine. You absolutely do not need to re-capture an image just because there’s a newer client out. The client reliably updates itself after image deployment when it sees the server has a new version. The new version will then do everything you have set for it; naming, domain joining, snapins, printers.
Make sure NFS is running with:
systemctl status nfs-server
Set the ownership of the images directory to user fog and group root like this:
chown -R fog:root /images
Then try again.
Also, see what this says:
showmount -e
You should see something similar to this:
Export list for fog-server:
/images/dev *
/images *
Also, you may find this helpful: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS