@Brian-David well this is certainly strange. This is the best theory I can think of:

Is one of the snapins specifically to blame? You state that this only happens when you run “All Snapins”; from the client perspective this is no different then running them individually. Are you running all of the snapins individually, and this issue is not present then?

If this is not the case let me know, and I can walk you through using the client’s debugger, it should help narrow down the issue pretty quickly.

@damonledet Any news on this?

@patate01 Sorry this has slipped through. Just too many things happening here in the forums. Thanks for reporting. I know Tom has changed the code to only print a warning but keep going but I added a fix to not warn/fail on empty diskuuid as well.

Moved to bug reports and marked as solved.

@joe-schmitt you can close this sorry to waste your time…it is working correctly.

@tom-elliott Ok, I confirm it is working. Thanks!

Okay. You have a point about backing up the original disk.
I’ll give that a bash and check if it works.

@tom-elliott Thanks for your attention on my tickets!
The most cryptic one (count= issue) is not solved by sgdisk -z before dd but after. I’m going to add some infos.
Thanks again for FOG: I’ve been using it by 6-7 years. I can multicast deploy a 20 dual boot pc classroom in 30 minutes!

@sebastian-roth Doing the DB maintenance resolved the issue.

Wanted to give a reply… but with Houston after Hurricane, and business having to pickup and move… just now getting around to following up.

Thank you for your help and patience!

Thanks Tom!

Hi guys, @Wayne-Workman @Tom-Elliott

Finally I solved it was because once that you delete the image name, can’t be empty name on the log so, is using the last image name that you use, even if the information is not true.

If you don’t delete any image the log is working ok. If you delete will use the previous name from the last usage. I believe that the best is that the log become in this field as “empty” to not confuse, but it is ok.

Thanks.

Hi Tom,

It seems that works fine, shows all tasks and the daemon doesn’t show anormal behavour.

0_1508415265464_Screenshot-2017-10-19 http fog6 lgp ehu es.png

@Jim-Graczyk Do you still need assistance on deleting that snapin from the DB? When editing the snapin in the web UI you can see it’s ID in the URL. Note that down and open a terminal on your FOG server:

shell> mysql -u root -p ... mysql> use fog; mysql> DELETE FROM snapinAssoc WHERE saSnapinID = x; mysql> DELETE FROM snapins WHERE sID = x; mysql> quit shell>

Replace “x” in ... = x; with the ID you noted down earlier.

@sebastian-roth I don’t know how that happened but I copied the srvpublic.crt from a backup and it is fixed.

Thanks for all the help

@tom-elliott Just looking at rom-o-matic 1b67a is the latest release. I’m not in a place right now to see what boot version is in 1.4.4. I can check later tonight. But I would suspect that 1.5.0RC9 will have the fixed version of ipxpe where/when/since ipxe7156.efi was removed from fog.

@tom-elliott

Tom,

Sorry about the delay, but I wanted to see more data before responding.

The time zone change resolved a big part of the problem. All the times are now making more sense. I’m guessing the log store UTC because after changing the timezone setting, all Snapin Histories are as they should be - no time shifts.

I can only suppose that to have the times appear as they did originally, the initial time stamps may have been coming from the client. I would suggest this isn’t a good idea since PCs are notoriously out of sync, but these days with SNTP, not so much. One would think it would be desirable to use all time stamps from the server.

So… Thanks very much for pointing that out to me. I once knew timezone was a setting but seem to have forgotten…

To be thorough, I do want to point out something, just to be sure that what I’m seeing is by design.

Attached is a screenshot of the snapin history after a deployment for a machine.

0_1507741140553_d0a33bc5-87b8-455b-bb7d-f18054867b0e-image.png

Please note that there are only 5 Start Times for all 17 Snapins. It seems that the start time is only recorded for the first Snapin in a series of snapins executed in one pass of the FOG Service. Given the current report, one can determine the actual start time of a particular Snapin by doing the math (Add the previous snapin’s duration to the posted start time for the task). One can also determine the duration of each individual snapin by subtracting the previous snapin’s duration from the posted snapin duration.

Personally, I’d like to see the snapin start time be the start time for each snapin, not the start time of a group of snapins that just happen to run sequentially. Simialrly, I’d also like to see the duration as the duration of a single snapin, not a group.

If the current approach is by design, then ok. I certainly can live with what we have.

Thanks,

Jim

@ch3i Bump?

@tom-elliott Oh Ok… Thanks for the help. Now to just get the PXE working on my local subnet I will be good to go. This is a local network issue. 🙂

Thanks for the help.

Had same problem here, also have some errors on the following accesscontrol plugin

Adding some rules with empty fields says you cannot save (you solve this by entering some stuff and then editing to erase it).

After add some user to a role, It doesn’t show up on the role member section but it is added. If you want to remove some users from a role you need to edit the table RoleUserAssoc).

You cannot hide the accesscontrol menu by the default rules created by the plugin, you need to add it. (Just add it following the other rules).

*Same problem as above about memory size exhausted.

*After enable some plugin, the appareance of the main menu doubles the height size in some sub-menus. (my screen is 1366x768).

I wish i could help fixing there kind of things but just a networking specialist =(. I’m just can report some of the errors I find.

Latest Version: 1.4.4
Latest Development Version: 1.5.0-RC-9
Latest SVN Version: 6078

@wayne-workman said in Boot File Testing for SR:

@george1421 said in Boot File Testing for SR:

@psycholiquid Pssst… to adjust the small font size try this FOS kernel parameter vga=792

vga=792 should be 1024x768x24 video mode, and clean your monitor, please!!! 😛

ref: https://unix.stackexchange.com/questions/71231/grub2-and-kernel-vga-parameter/114980

#wiki worthy

LOL I don’t think you should wiki me having to clean my monitor… LOL I kid.

@Tom-Elliott

I have been keeping an eye out on this issue with replication myself, im running V52 of working branch, should I wait until RC10 to come out to update? So far I think everything is functioning normally for replication but figured I could wait until RC10.