I’ve added these items:

FOG_TASKING_ADV_SHUTDOWN_ENABLED
FOG_TASKING_ADV_WOL_ENABLED
FOG_TASKING_ADV_DEBUG_ENABLED

With schema update 252 of the working branch of fog. They will do what you were hoping for here now.

@andyroo54 I’ve added error checking for getting the $_FILES[‘blah’][‘error’]

The problem, in the case of too large a file chosen, is it completely blows away ALL $_POST/$_FILES variables as blank. This is why it’s reporting the “blank name”.

Unfortunately there’s not much I can do to fix that.

I have also added the suggested 3g limit instead of 100 megs. Of course, it won’t change this if your values have been set to other the the 8m (post_max_size) and 2m (upload_max_filesize).

@jj-fullmer and I had a remote session and the cause of the resize issue as described was found.

The issue he was seeing was the resize allowed a partition to be sized larger than the boundary of the disk. This only occurred, as far as I could tell, in the case of 4k disks again, but I’ve added code to correct for this in ANY case of the chunk size passed in.

Just thought I’d give an update to the “resize” issue as it was described and I’ve released RC-16 in an attempt to ensure this is corrected for.

Confirmed, found, fixed and pushed (Notice I didn’t say tested cause well I don’t have anything to test with. sorry).

Apparently with 0.2.88 (maybe earlier but before that for us was 0.2.69) they added a “note” feature

The picture shows the (note:) line now which shows the Storage location and the Image name.

Just a guess but this drive is likely based on 512 sectors expecting to be started at 63 but the image is in 2048 which makes the drive not understand how to use the drive (why Windows showed it as inactive)

Might I ask what you’re using this for? This wasn’t added because it caused other problems (when I tested it).

Adding it is simple enough sure, but what other impacts does it have?

I’ve found the issue as described and it is now fixed in the latest.

Added in working.

@Tom-Elliott Fix pushed.

This already exists in the form of a notification gui. It will give the user 60 seconds before any action happens. It also allows the user to select a delay/postpone.

@coco65 I’ve edited the code and removed the .mo files. They will only be generated if installlang variable is set.

I can’t really remove the language menu item though. So not having the .mo files will make any language selected automatically defaulted to english.

https://www.microsoft.com/en-us/Useterms/OEM/Windows/10/UseTerms_OEM_Windows_10_English.htm

In case anybody’s overly concerned. Here’s the OEM EULA. Notice, it states that you are allowed to transfer the license to another user so long as it’s with the device and the software is installed and the product key is given with it. There are no rules on what you can/cannot document. That’s like saying you can’t pull the serial number from the bios.

Just trying to get people to calm down. We know the device and software are owned by the person. We know how to obtain the information. We don’t know how the user intends to use it after it’s been stored, but that’s out of our hands. We cannot control what the admins/users do with the key once it’s know, but that’s out of our control to begin with. There’s plenty of ways for users to get that information to begin with, I don’t see anywhere in the EULA where it states we cannot store a copy of it for ourselves.

Confirmed, found and fixed for unregistered hosts.

I haven’t looked in a while, but I believe the history table on the SQL db will contain all of this information. I added a bunch more logging a while ago in an attempt to at least maintain the data. I haven’t gotten around to actually parsing the table into a nicely formatted report or anything, but the data, itself, should be there.

@Quazz Possibly, yes. I’m trying to rework the way these things get specified. Currently in 4 million lines of code lol.

FOS already contains a registry editor too, just in case anybody was unsure. That’s how we do “hostname early”

@Wayne-Workman forgot to write here but this should be good now.

Also I think you are not understanding what registration is doing.

When it sends the information to the server it’s sending all macs that it finds. The order the macs are sent is based on how it comes into the machine.

So a machine with two Ethernet cards might come up with: eth0 and eth1

When fog pulls the macs it pulls it in order. So eth0, eth1 would be sent.

If eth0 is the nic that’s not communicating it doesn’t matter. It’s just sending information it’s finding. You could work this by disconnecting the nic that doesn’t communicate to fog, or switch the ports around so eth0 is the nic communicating to fog.

Either way, this isn’t something we can fix with a simple arp as we need to know which nic is communicating to the fog server, not the fog servers MAC address.

This likely will not be addressed for 1.5.0 as we really are trying to get a machenism that doesn’t rely on the MAC address. While we could make this work, it would not be a simple thing, and would only be used for a very short amount of time.

Found and fixed. Will be in the next RC.