Surely you jest. Fog 0.29?
Would you kindly update your Fog and your kernels?
Surely you jest. Fog 0.29?
Would you kindly update your Fog and your kernels?
Did you do a scrub on the hard drive that you are attempting to image? Could it have GPT garbage left over on it?
I am looking to deploy the Fog Service to Windows machines already running in our domain via a GPO and the Fog Service MSI. But I am having a hard time creating the MST that will tell the MSI what IP to use for the Fog server, and allow me to control the other options presented during a typical install. Anyone have anywhere for me to start?
If your hardware supports it then possibly, but that is rare for hardware to support.
apt-get upgrade actually tells your linux server to upgrade any modules it found updates/upgrades for from the aptitude lists.
EDIT: “apt-get upgrade -f” should also tell your system to check for and attempt to repair broken dependencies.
Are you completely certain that the system you are uploading from does not have a corrupt OS/partition or a failed/failing hard drive? I have had Fog be very… forgiving for failing drives.
It doesn’t matter where you navigate to, if you get prompted to update the schema then you have gone to the right place. As for the fog main page being blank, that’s very odd. Is Apache still throwing tons of errors? Have you ‘apt-get update’, ‘apt-get upgrade -f’ lately?
Agreed, if you must use a ‘new’ OS and like the Debian ecosystem, then go for pure Debian 7.5 . I can tell you from first hand experience that Debian hasn’t changed anything that affects Fog from 7.4 to 7.5, and that Fog 1.0.0 works flawlessly on Debian systems now.
Oh, and I also have a Domain with a DHCP server already running. It posed no issues to tell Fog not to be a DHCP and then make the modifications to Options 66 and 67 on the Domain DHCP.
Good post. I ran 0.32 under Debian 7.4 for a while. I did have to do the first three modifications, but I never ran into the ‘Unable to Mount NFS Volume’ issue.
That being said, after I switched to Fog 1.0.0 and did a clean install, I did not have to make any modifications to get it to work. So good news for Debian users as we move forward.
I would say go with Sysprep. Once you get comfortable with it, you should be able to automate your tasks whenever you do have to remake an image. I just don’t see paid products that do what sysprep does being worth the money.
[quote=“need2, post: 26632, member: 21891”]What revision are you on? I was on release 1594 and didn’t notice until this morning that TFTP was completely borked for me. Tried a bunch of things, but in the end updating to release 1601 fixed it.
EDIT: Would have posted about this in bugs but I never figured out what exactly the problem was and it looks like Tom fixed it. Looks like I need to stay on revisions that he posts about in the Fog 1.0.0 thread.[/quote]
Seriously though, your issue sounds exactly like mine which I encountered on a completely different setup. An update is probably your best fix.
What revision are you on? I was on release 1594 and didn’t notice until this morning that TFTP was completely borked for me. Tried a bunch of things, but in the end updating to release 1601 fixed it.
EDIT: Would have posted about this in bugs but I never figured out what exactly the problem was and it looks like Tom fixed it. Looks like I need to stay on revisions that he posts about in the Fog 1.0.0 thread.
Alright, that answers that. I appreciate the consideration.
Fair enough. The one problem machine was going to take 4+ hours for about 15 GB, and I know this is an odd case.
While this is the wrong wrong wrong thread for this question, its under Fog Configuration.
eth0 is the interface set… everywhere I can think to look. eth1 is also linked, but I never specifically set any Fog related services to touch that interface.
I’ve tested it in IE, Firefox, and Chome. They show the chart, just no graph is ever drawn on it regardless of actual throughput.
Yes, typically you would want a decent machine to be your original image host, so that the whole process gets done faster for you. But there are situations like doing a pre-service backup with Fog on a crap machine where a better processor isn’t an option.
Clearly, this is not a dire need, but it would speed things up in a few situations. It also shouldn’t affect the default workflow for users if the default setting is to use the system-wide compression level setting.
On Fog 0.33 (but this issue also occurred in a separate 0.32 install), if the Fog server has multiple ethernet ports that Linux (Debian 7.5 in this case) has been allowed to team, the Transmit and Receive graphics on the main Fog GUI screen never seem to report bandwidth usage.
Obviously this is not a dire issue… everything else works golden. Just curious if anyone else has run into this and has any fixes.
Sure, but was that drive used for previous Windows installations? It just seems like there was junk partition info left on the drive from the images that were being made on the server. Also, if you are doing an NTFS Resizable partition, it doesn’t matter what the original partition size is, only how much of it is used by data.
EDIT: Tom’s post gave me an idea. I assume this is a Windows 8 install that you upgraded to 8.1? 8.1 is not a service pack, its almost like an OS reinstall that you happen to get to keep your programs and files through. I would not be shocked if the 8.1 upgrade does some partition junk during its upgrade process to give it some fallbacks in case it fails during its install.