Posts made by Tom Elliott

https://news.fogproject.org/fog-1-5-7-officially-released/

@Rivybeast What about:

SELECT hostName,iHostID FROM fog.inventory LEFT OUTER JOIN hosts ON inventory.iHostID=hosts.hostID;

Likely will be huge again.

@Sebastian-Roth From the sounds of things, “Blank Page” is not quite what it seems in this scenario.

The Page itself is loading perfectly fine. The “Headers” are displaying, then disappearing. This is likely because there’s no inventory data to print to the screen.

What’s the output of mysql statement:

select * from fog.inventory \G

This is really good information. I suppose it could be useful especially with the speed of NVMe usurping so many other disk access things, maybe udev is the issue the whole time in regards to “sporadic access” and usability?

Thank you all for the debugging and communication.

@Sebastian-Roth Typically it would be found in /var/log/php-fpm/www-error.log

@Eric-Johnson what about replacing sync with sleep 5? Sync is just ensuring cached items in wait get pushed to disk, maybe the scripts are working just a slight bit too fast?

@imagingmaster21 this is at the command prompt. When you boot into a debug session, before you type this command you’ll be asked to press enter two times. Then you will have a command prompt like

root@fogclient ~] #

Here is where you enter the grep command

@zone67 it doesn’t quite work like that. People have been nice and I’m not saying they won’t have it. But please understand the VM method isn’t really any easier than just creating your own vm and installing fog on it. Logistically it isn’t a feasible method. That’s not to say nobody can get you one.

If the file is now called fog.man.reg.cust, and the postinit script is looking to copy over fog.man.reg.fix, it would seem it really is a typo. As we still haven’t seen the contents of the new servers postinit script, I’m still having to lean towards a typo just as much as Sebastian is.

Found and Fixed in latest. Thanks for reporting.

@Razuel remote management is what it sounds like. Public facing meaning the fog server is accessible from the internet.

While technically possible to image, it really wouldn’t be the best experience. By remotely managed we simply mean you can change the host name, tell it to join a domain, configure printers, set up snapins, and that kind of thing. I wouldn’t recommend imaging over the internet as it would be constrained by your internet upload speed and the remote sides download speed.

Usually download speed is fine anywhere but upload is typically limited much more so.

@Cheetah2003 in working-1.6 this was already addressed though I may rethink how to work it. This is somewhat easier for the 1.6 side as the pages and elements are much more modularized.

Sure this can be unexpected though I don’t fully understand. Not that I don’t understand the reason this could be an issue, per se.

First why would you need to create two hosts and use one of those hosts Mac on another host?

This should be relatively easy to address but I really don’t understand how/why someone would do this. Create two hosts, then assign the Mac of one of those hosts to the other. Or more specifically, the primary Mac of one of the hosts being assigned to another already defined and primary Mac having host.

It can open .gz, but you’re right. By default, we use XZ compression for the init’s.

Even more odd is the fog/images/init.gz being the configuration path from the old 0.32 versions (and earlier) when it referenced the init from /tftpboot/fog/images/init.gz

Did you follow configuration from a very old tutorial?

The interface setting on the server used to work for this, but it also caused issues if you had the wrong interface name.

Rather than deal with the interface naming for a task that needs to be exact, the IP of the fog server is used to automatically determine the interface to use for multicast tasks.

The interface setting in the GUI, now, basically just sets up the interface to check bandwidth from.

@arnaudrigole I believe I understand what you’re saying. You already have Windows installed on the machines, and switching to AHCI from the current RAID configuration will make your install unable to boot.

That said, while I understand the hardship it can require, you could switch it to AHCI and reinstall the instance of Windows.

That said, it seems, too me, that you may be potentially doing something illegally.

1. You have your machines and they came pre-installed with windows. This is fine by itself, but trying to capture an image is not technically allowed.
2. You’ve customized the machine to how you need it, and are trying to make an image that you can use for multiple machines of the same make/model. This shouldn’t cause any major issues from a legal standpoint so long as the machines to be receiving this image are using the very same install disk and software. But I believe customizing the OS is not allowed from a legal standpoint.

If you’re hard set on using the RAID in the current mode, I believe you would need to add mdraid=true on each of the machines host arguments that this would impact.

@Joe-Gill Then something is not working for yours as the “magnifying glass” should look like:

Notice the search text field.

I’m not seeing an issue with entering the search and pressing enter or entering the search and clicking the magnifying glass.

@Sebastian-Roth No ideas really.

However, the fact that it’s referencing the “boot” sector as the issue, I’m guessing the Partition table is configured in GPT? Does it look similar to the other GPT threads where the last partition in the disk is also the boot partition?