@kman1232 Create a batch file and get it to work like that first. Batch files have a .bat extension, they are considered a windows executable type of file.

You’d upload the script into a new snapin, then test deploy that on a client and see if it works or not.

@ivan68 the reason you guys are seeming that default/pxelinux folders missing is because they are. The do not exist between 1.0.0 and 1.2.0.

@Uncle-Frank

Hi Unkle frank,

I haven’t yet looked deeply at location plugin, I will test that sooner. Maybe you can set this thread as solved, because answers given here are clear enough, and only tests will give me a definitive answer.

Cheers.

@ch3i said:

I think it’s a tftpd server limitation.

I guess this is for security reasons. tftpd is not allowed to leave the “cage” of /tftpboot … not even to follow a symlink back into the cage. “Keep it local”.

Thank you for your suggestions. We will test and report back.

I’ve been thinking A LOT about the many many problems with all the Vendor Class identifiers that Apple has…

Because PC is so standard (like PXEClient:Arch:00000 and PXEClient:Arch:00007 ), and because Apple are extreme non-conformists,

It makes no sense to try to define a class for each apple device. it’s stupid.

I say - make ipxe.efi the default and then make classes for the various PC PXEClient architectures.

Abandon Macs that are 32 bit. Just don’t worry about them.

Yes, I tried changing it between and it’s still the same. By the way, how exactly can I edit the initial setup settings? I found the the fogsettings file located in the fog user folder but I have no permission over it and don’t know the default password for it.
Are the settings in the web interface all there is? Because I tried there to change between eth0 and 1 but got nothing still.
Thanks.

@Tom-Elliott I will leave was just going to try to clean up DB because it is like 96Mb

@Trevelyan The only way to find out is to play around with it.

I’d suggest first creating a single partition disk resizeable image - and then just specify in the host’s general properties which Host Primary Disk to use. To find out what that is for the 2nd drive, boot into a debug upload task, and just find the name that fog uses to refer to the 2nd disk. It’ll be in the devices virtual file system ( /dev ), it’ll likely be /dev/sdb but you must look to be sure. Specify the correct Host Primary Disk in the host’s properties page and then do an image capture as usual.

Then try to deploy that image to a test machine (not your golden machine) and just see what happens. Make sure you specify the Host Primary Disk parameter for the test machine.

If that works as you want, try it on a different model test machine, with maybe a different sized hdd in it. See what happens.

Please let us know how it goes and what you learn.

@Jbob exactly what I was looking for thanks!

@mtmulch I help run FOG Trunk at 6 (soon to be 21) public schools. Respect the Trunk - it is a great thing to have it virtualized with snapshots before each major change or upgrade. Backup your DB often, keep your old DB backups. And don’t upgrade on a whim. Upgrade when you have a need to do so.

And of course, if you have any issues; the fog community is always willing to lend assistance.

I formatted the machine again, only this time I created the partitions before sending install direct. In this way it worked.

@Junkhacker I tried to build a custom USB boot drive for FOG a while back using several potential methods. I fear I simply just don’t know enough about the technologies and projects I was trying to use to get them to work right.

Simply using an image prepared by someone else WOULD WORK - but I’d really like to make my own.

@Uncle-Frank Thank you for the link!

Success on all fronts.

I have successfully created a generalized virtual server running CentOS 7.1 with FOG Build 4820. I can dump an image of it onto any hardware we use, mobile, desktop or virtual and it works exactly as desired.

I like it so much I’m making it my new standard.

There were some new hoops to jump through, but the CentOS community and online documentation provided solutions using native commands and features.

I even succeeded with no issues whatsoever in converting my vm development fog from Debian8.2 to CentOS7.1 in about 15 minutes.

I love slaying dragons. 😎

@pmonstad said:

syntax error in conditional expression: unexpected token (

Probably CentOS 5.11 has a pretty old version of bash running which cannot handle regular expressions in condition clauses. I guess there is no easy solution to this but update your OS. Probably best if you can setup a new server for testing FOG and if you are happy with it you can still consider updating your existing OS.

I think the default is set to 10 minutes. You can update this time by editing the value (in seconds) in the Config.class.php.

It’s found in the svc_setting method of the Config class file.

You mean booting the KVM VM up with FOG and draw an image from it? I am not exactly sure about KVMs network boo abilities but I guess it should run without much trouble. I am doing exactly this with qemu here on my laptop to find issues. Way easier than having physical machines for testing around.

Because, the other installers did NOT require setting of the password. Arch and Redhat. I made a large move to commonize the installer so things were more or less presented the same way across the board.

@Uncle-Frank You’re amazing! What you posted is very similar to what I came up with in a thread, but I haven’t gotten around to testing it.

If you get dnsmasq to work with co-existence then you’re like… everyone’s hero… for real. Because if we can get a rock-solid dnsmasq config for all types of booting - then for 95% of fog setups out there, we’ve eliminated the need to change DHCP. Fog can then come with dnsmasq setup by default and it JUST WORK without further setup.

In my opinion, Linux DHCP is far superior to Windows DHCP… but dnsmasq would be the ultimate solution if we could just get it to work.