Server

• FOG Version: 1.5.0 RC-6 Working V16
• OS: CEntOS 7

Client

• Service Version: 0.11.12
• OS: Windows 10 & Window 7

Description

Can someone tell me what’s normal with regard to snapin execution reporting. I’m on the Working Branch. I’m hoping folks can tell me what they see in v1.4.4. I don’t want to post this in the developer area unless it’s unique to v1.5.0.

Here’s the issue:

When deploying an image with snapins, the FOGSERVICE runs all snapins until it hits a snapin that requires a reboot. It reboots and then runs a bunch again without stopping. This is all good.

The problem is that the Snapin History for the host and the Snapin Log both show the start times for each snapin in an unbroken series to be the same time when in fact, each starts after the previous Snapin finishes (snapins do not install in parallel, but in series).

The effect is the reported/recorded duration of any snapin changes depending on the duration of all the snapins that ran before it.

Here’s a sample:

Note that the first 4 snapins show the same start time. The 4th reports taking 2 minutes 37 seconds to complete, while it actually took 2 seconds for the snapin to run (the difference between the its end-time and the end-time of the previous snapin).

Since the 4th snapin forces a reboot, 5th snapin starts another series of 7 snapins, all showing the same start time.

The impact is that we can’t determine anything from the history of each snapin over time, nor can we use this info to help set valid execution duration for each snapin.

So the questions are :

• Does v1.4.4 work the same way?

• Would changing this be a feature request, bug fix, what?

thanks,

Jim

@tom-elliott

Tom,

I’ve done some testing and here’s what I’ve found:

• When I have 2 or more Hosts deploying Snapins, and I apply a host name search filter to the Active Snapin Task display, I get a subset of the Active Snapin Task list that matches the filter.

• The search filter appears to be persistent as this screen refreshes - so this is working as I had hoped it would. We can now track the progress of specific machines - and we can change the filter while we’re looking at it and the display changes - so we can track specific machine’s progress on the fly.

• There are some deleterious impacts to other screens.

• The filter appears to be effect the display of host when one hit’s the Hosts Icon and / or hits List All Hosts under the Hosts Icon. The display doesn’t show the filter text in the Search field, but the list is blank until one goes back to the Active Snapin Tasks Screen and removed the search filter.

• The Active Tasks display appears to have the same filter value in the Started By field, with the text showing. From this I’m guessing the search filter is being retained and applied to the display screens based on the field’s position in the list rather than based on the field name. This would explain the empty list in List All Hosts. In the Active Snapin Tasks list, the host name is the 2nd field. The 2nd field of the Active Task List is the Started By field, but the search filter displays the Host name search filter value I entered on the Active Snapins list. The List All Hosts second field is a check box - so that explains why the list is empty until I remove the Host Name search filter from the Active Snapins list.

• Possible Solutions:
  * Clear all search filters when you change screens by navigating (back arrow or clicking anything).
  * Track the field that has the filter and retain and display it in subsequent screens and blank it when the column to which the filter is applied isn’t displayed.

If I got to choose, I’d pick the first approach. It would be good to have all filters blanked when we move off any page - but I leave that to you.

thanks for working on this.

Jim

Sebastian,

Here’s d1.partitions:

label: gpt
label-id: 6561AEE9-3184-4274-B8E2-359A32B76FD5
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 104857566

/dev/sda1 : start=        2048, size=      921600, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3E77A64A-2E46-40EC-93D0-03CFD0BDDDC9, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=      923648, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2CF8BFD9-3B61-4FAD-A4DC-6FC2A1E6E134, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1126400, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=1222537C-11F5-4B9F-9FB2-68AE743C5D79, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1159168, size=   103696384, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=0C2EDC77-DB4B-45A1-BF2B-2BE3B844CF47, name="Basic data partition"

Here’s d1.fixed_size_partitions:

:2:3:1

Jim

@tom-elliott

Tom - I tested this on several Gen2 VMs and they all extended to the fill disk size.

Thanks - SOLVED.

Jim

@tom-elliott

Here are the screenshots for each step of the fog iPXE process:

@tom-elliott

Tom,

I ran an image deployment with the kernel switches you list. At the start, it said it was logging. Can you tell me where the log is and how to get it to you? If I need to record another way, let me know.

There were no errors. All actions appeared to work as I stepped thru the deployment process. Specifically, resizing after the 4th partition was downloaded said Done, but the partitions wasn’t actually extended.

Also, should I take George1421’s recommendation that I wget bzImage and bzImage32 from fogproject.org or do I have the latest versions as part of the current working branch?

If this is something you don’t want to address right now, I have a work around with a Snapin that appears to work fine so I’m not dead in the water on EFI testing.

Thanks,
Jim

Has anyone attempted to deploy an image to a Gen2 VM in Hyper-v with the latest v1.5.0 RC?

I’m finding that my images are not expanding to include the whole disk drive.

This occurs only on VMs - at least based on the limited testing I did (1 HW PC).

I’m not sure when this stopped working, but I believe imaging for these VMs worked in previous v1.5.0 RCs. It certainly worked in v1.4.4.

As a test, I used FOG to deploy the image to a Gen2 VM and had it shutdown after imaging. I was able to mount the VHDX file and extend the volume using the Virtualization Host OS - so the volume is expandable. After dismounting the VHDX file, the VM booted and continued normally with FOG tasks (like joining the domain).

We also created an ExtendVolume Snapin that appears to work.

Snapin runs diskpart /s extend.txt

extend.txt has the following in it:
select disk 0
select volume 0
extend

I’m curious to know if we’re the only ones having this problem.

thanks,

Jim

Tom,

I’m only trying to be helpful. The product will be whatever you think it should be.

What I’m pointing out is that the search fields at the top of most lists are very helpful for shortening very long lists. Specific examples are the Snapin Report page. the search fields make quick work of tracking an issue down on a PC or a Snapin.

For the auto-updating screens that have these same search fields, the issue is the time between updates and the temporary nature of the data one enters in the field. If one is tracking Snapin installation on a specific host, and filters the Active Snapin Task to do this, for my installation, which updates in a second or two, the list is reset to show all tasks in very short order.

So, is the time to update Auto-Updating screens a current FOG setting?

if so, I’ll look to set mine install for 10 seconds or so. I type slowly.

If there were a way for the filter to remain in place across a data refresh on the screen, that would be good. If it were, one could leave the screen up, monitoring progress on a give host until the list was empty.

That’s all I’m trying to say. I didn’t mean to imply in my message that this was a bug or a requirement. I worked with FOG v.32 for some time and have been off doing other things for the last 4 years. I’m familiar with the differences between v.32 and v1.5.0, but not so v1.0.0 thru v1.4.4. I surely have no idea how hard it would be to implement what I’m suggesting.

My apologies…

Jim

Server

• FOG Version: v1.5.0 RC-6 Current Working as of 9am today
• OS: CEntOS 7

Description

Not a bug but an issue… Maybe this should be a feature request… Not sure…
The Search Filters Common to the lists in the new UI Style are useless in screens that auto update - like the Active Tasks and Active Snapin List. The filter only applied to the data in the existing list and is reset as soon as the screen updates - which for my set up is a few seconds.

We really need to have filters for auto-updating screens remain in place until we exit the screen or manually clear a filter. Otherwise tracking progress will be very difficult when the server is in use by several people with several separate work tasks active.

Jim

Server

• FOG Version: v1.5.0 RC-6, working branch updated 8/2, 10:00pm EDT
• OS: CEntOS 7

Description

Was testing Muitlcasting, created a group. Tried to delete it from the Groups/List All Groups screen. Checking several group names or a single group and hitting the Remove button did nothing (not even a screen update).

Selecting the group from the list and then hitting the Delete tab/button (last item in 2nd-level list) successfully deleted the group (after entering credentials).

Jim

George1421,

I only needed to set the Fog timezone parameter and the date and time recorded correctly. I didn’t have to change php.ini. Also, throughout the problem, the system’s clock and timezone were correct.

Consider this solved. Thanks.

Jim

@jim-graczyk
To add more info -

I deployed several hosts with snapins. The Task Management Icon display showed the deployment with snapin, but once the imaging portion was done, the item disappeared from that screen. At no time was anything displayed on the Active Snapin Tasks screen. Periodically checking the Snapin History for each machine shows Queued, Complete, or Checked-In, yet nothing showed up under Active Snapin Tasks.

What am I missing?

Thanks,

Jim

Server

• FOG Version: v1.5.0 RC-6 Updated 8/1
• OS: CEntOS 7

Description

I’m seeing timestamps on images that appear to be in GMT (4 hours ahead). Is this intentional?

I’m seeing the same time issue in Image History tab for the Host.

Jim

Tom,

Sorry - bad terminology - and perhaps my expectations are off.

I was expecting to see pending and active Snapin tasks when I have them pending or in progress somewhere under the Task Management icon - assuming this would be under Active Snapin Tasks. I see image tasks there that are pending and in progress under the Task Managment Icon, so I was expecting the same for . I wasn’t expecting to have to go to the Snapin Report to see Pending Snapin tasks.

It was/am expecting to use the Task Management Icon and below to track things as they happen and to know when a task (image w snapins, image w/o snapins, deploy 1 snapin or deploy all snapins) are in pending and progress. I was/am expecting to use the reports to have a historic view what happened, when and results.

Does a “Deploy” task (Image and Snapins) remain in the Active Task display until all snapins are deployed? If so, is there any way besides checking the machine Icon/Snapin History or the overall Reports/Snapin History to determine progress. With a lot deploying at once, that’s a lot of jumping around when several PC deployments are in play. I had expected to see Snapin-by-Snapin in the Active Snapin Tasks list.

I’ve tried to test this but many of my snapins run very quickly. I’m not sure what I should be seeing where and when. The Task Management/Active Tasks list show pending tasks, as well as active tasks.

Does the Active Snapind list function the same way?

Thanks,

Jim

Server

• FOG Version: 1.5.0 RC-6 Pulled/Updated 8/1
• OS: CEntOS 7

Description

Snapin Log under Reports is not showing pending Snapin tasks. Snapins continue to run and show pending/complete on Snapin History for each machine. This ‘feature’ is fairly critical to monitoring progress during deployment activities.

Also, I BELIEVE I’ve seen Snapin Tasks when one clicks on the Tasks Icon. They seem to be displaced to the Snapin report when a deployment task is created. I’m doing more testing and will get screenshots if I can.

How is this supposed to work?

Jim

Are you stopping FOG as part of running Sysprep?

I think you need to stop fog and disable it so the FOGService doesn’t start on the target computer and then enable and start fogservice up in the SetupComplete.cmd (or is it CompleteSetup.cmd?).

I don’t think you’ll get a good result if the FOG service starts while sysprep is running (post imaging). You don’t need to reinstall FOGService (at least we don’t have to). Also, the issue may be the encryption data, if you’re imaging the machine on which you created the image.

Jim

@Tom-Elliott I believe it’s working since I never changed that, but you tell me:

Not sure since it says I’m not running the latest.

Jim

@Tom-Elliott I pulled the latest working from Github and installed this morning but my Single Snapin Snapin choices look the same as before.

Any idea why I’m not seeing the change?

thanks,

Jim

And addition -

I’m seeing group settings being retained and not retained within a screen. The Group retains Group EFI Exit Type setting under Group General, but not the Group BIOS Exit Type. When you leave the group definition and come back, the Group BIOS Exit Type is - Please Select an option -. It also sets all members this way. Perhaps the problem is an error in reading the set value, ending up with the default value and that getting applied to all members.

Jim

Server

• FOG Version: 1.5.0 RC3 Working Branch Updated 9am EDT Today
• OS: CEntOS 7

Description

• list itemWhen you create a Group, add PCs to it, etc. The Location Tab does nothing.

Is a groups supposed to be able to assign location membership?

• list itemWhen you assign snapins, the snapin selection isn’t retained in the group.

Is this by design? It seems it would be more useful if the Group object at least retained the snapin selected even if the group works only to update the members when the selection is made. This would make the group snapin selection re-usable as we add new members to a group.

• Similar to above, the Image Association isn’t retained in the group.

Same issue as with snapins.

• Some selections are retained (AD Settings for certain, maybe Printers, Power Management, not sure)

Is this by design?

I previous versions of FOG, I’ve ignored Groups since I found some of these same inconsistencies. If groups are functioning as they always have, feel free to ignore all issues here except the Location issue. If there was never integration between FOG groups and the location plugin, then the tab should not appear. If there was integration, it needs to be restored.

Jim