Thanks
Jim
When deploying an unassigned Snapin using Single Snapin, under Basic Tasks for a Host, the following message appears when no Snapins are assigned to the host:
It appears there is a check somewhere that requires at least one snapin to be assigned before a snapin - assigned or unassigned - can be deployed.
Jim
I would also offer the suggestion that you separate the /images folder onto a separate virtual disk. You Could do this without rebuilding. I’ve used USB disks on ‘toaster’ that are mounted as /images as well. In either case, this allows use to expand the /images folder w/o messing with the rest of the install.
Wayne is an expert, so maybe my approach is more work. I’ve backed into this problem over and again, as image space has grown (mostly from uploads, in my case), but we were able to mount the old volume as /oldimages, mount the new empty volume as /images, copy image, then unmount the /oldimages volume. If I recall, it was only a matter of mess with fstab in my case.
Just a thought.
Jim
Tom,
We’re good on the cancellation issue, but I’m still seeing a series of packets with the same start time and ever increasing durations times for each subsequent snapin.
I didn’t get that you made a change. I doubt I can be of any help with the code, but I’ll look.
The screenshot above is a single deployment of an image with several snapins. There’s a reboot after 0-W7PostImageCleanup and another after 1-UACDisable. So there are 3 “series” of snapins in this deployment.
2017-08-10 12:24:36 (2 snapins)
2017-08-10 12:25:28 (1 snapin)
2017-08-10 12:26:14 (6 snapins)
All scheduled as part of the image deployment and all separated only by reboots implemented by FOG as part of a snapin.
Jim
OK - so yeah, maybe it was a DNS issue on the client side after all. One of the snapins I’m working on dorked the DNS search list.
I determined this by examining the spanins deployed to the host - 100% alignment with snapin that dorks the DNS searchlist.
Go Figure…
Thanks and sorry for the trouble…
Jim
That depends on whether you (all) have any intention of changing the reported start time and duration for snapins when they run in a series (a single pass of the Snapin component in FOGService.
I still believe it’s unclear to have all spanins show the start time of the first snapin in a series. I’ve done some extending of FOG on the Snapin deployment side. My snapins are network installs that reside on DFS on windows servers and Samba on storage nodes. This allows dynamic editing of all snapins w/o the need to reupload anything to the FOG server and prevents snapins from requiring 2x the freespace (1 to download from FOG, 1 for the installation). The FOG Snapin is a small exe that passes needed info the the CMD (regarding where to connect to the SMB share at each site) and starts the CMD. I log the output of each CMD (>>some_log_file.log) so as to make debugging easier for creating and running snapins.
The logging process I have clearly shows each subsequent snapin starting after the previous one completes. I don’t see why this wouldn’t be how FOG records snapin execution.
So, leave this one as UNSOLVED only if you will consider making the reported times accurate based on start time, end time and duration the snapin actually has.
Mark it as SOLVED if you don’t intend to change anything or feel there’s nothing to change.
Thanks,
Jim
Sebastian,
I often work late.
I’m working on a reusable design model so we’ve abstracted a great deal. We intend to use an alias for the FOGServer to point to (…wait for it… ) the FOG server, for each deployment - we’ve just changing the Alias in DNS. We want the desktop images to be reusable and generic.
So, for all the system I mentioned that work, they are also all using fogserver as the name of the fogserver - so it’s not a DNS issue.
Jim
I’m seeing the following in fog.log on Windows 7 PCs after deploying some snapins and several reboots:
This just seems to repeat over and again. The problem appeared only after the last update. I worked late into the night last night running identical task in FOG with no problems on Win7.
I’ve reset the Encryption for the PC from FOG Web UI and I’ve rebooted the machines, but I find no solution except re-imaging.
I have static Windows 7 PCs (one’s I haven’t been working with) that aren’t having this problem, and I’ve seen the problem on no Windows 10 PCs. But I haven’t been beating on Win10 pcs today.
Anyone have any ideas what to start looking at?
Thanks,
Jim
Tom,
One more similar observations - when you cancel snapins, they’re each assigned a duration equal to the time between the snapin request being submitted and the snapin being canceled. Again, since none of the snapins actually ran, one would expect to see a duration of 0 time for each.
Jim
Tom,
Thanks for the quick fix. Imaging is back working again.
Jim
Updated around 10 am today and since couldn’t deploy an image. Saw the RC7 notice and updated again, but the issue remains:
Jim
Tom,
I’m hoping that the start time, end time and duration for the execution of each snapin would be just that. I’m not concerned with seconds. If one is lucky enough to have PCs so fast 5 snapins start and end on the same second, whoohoo.
I’m tracking what PCs are taking what time to do what snapin. Sometimes we’ll see something odd and we’ll need to check out why this happened. The value is also the long-term record plus we have timeout limits to set for each snapin. So we’re looking for long time intervals for snapin installation.
I’ll check out the change you’ve made later tonight or tomorrow.
Thanks
Jim
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,
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 - I tested this on several Gen2 VMs and they all extended to the fill disk size.
Thanks - SOLVED.
Jim
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