Legacy Client - won't reboot when an image deployment is waiting.


  • Moderator

    Fedora 23
    SELinux is set to permissive.
    Firewalld is turned on per @Jbob 's instructions.
    SVN revision 4455.

    The service setting “Task Reboot” is enabled for this particular host.

    Here’s the log:
    0_1448914985243_fog.log


  • Senior Developer

    @Wayne-Workman while I realize this is very old, I feel I must add, the legacy clients Config files always defaulted force reboot to off. It is this I imagine is the meaning of lazy mode.


  • Moderator

    Wonder what lazy mode is…

     12/1/2015 8:54 AM FOG::TaskReboot Taskreboot in lazy mode.
     12/1/2015 8:54 AM FOG::TaskReboot Starting Task Reboot...
    

  • Moderator

    @Developers

    New day, new logs, new screen shots :-)

    SVN Revision 4457 Cloud 5572 Fedora 23 Server - Firewalld enabled per @Jbob and SELinux still set to permissive.

    0_1448982016685_fog.log


    0_1448981982443_upload-e7718db4-3463-4ee1-acba-ddfd0a6218f0


    0_1448981488190_upload-05d513c4-167a-4cc9-b8ea-24a2c5c35ba8


    0_1448981939650_upload-03611407-105f-45e0-9474-0783181b56bd


  • Moderator

    @ITSolutions The Task Manager shows the task as queued. I think the MAC is correct, because if I reboot the machine manually it images as normal.

    This morning, I migrated from Fedora 21 server to Fedora 23 server.

    I moved over the public & private SSL certificates and CA in /opt/fog to the new server. I moved over the images. The new server uses the same IP as the old one - but has a different name. The Legacy clients in the environment were installed using the IP. I’ve created a DNS A record for the server’s name along with a corresponding PTR record. I exported/imported the hosts and images also, not the entire DB - I didn’t want to bring over all the old data.

    Just me and another guy uses our building’s FOG Server, and the other guy didn’t change the MAC. FOG is sort-of my baby in my building.

    I’m still mostly using the Legacy Client because I felt the new client was not ready when I was making all of the images I needed - that was in May & June this year. I know it’s come a long way and is pretty solid, and I do want to move to the new client but I don’t have a strong reason to do it. I only need three things from the client on Windows - rebooting, naming, and domain joining. The Legacy Client does those three things fine on Windows Vista through Windows 8.1. If the @Developers chose to discontinue support for the Legacy Client, naturally I’d move to the new one. But you understand how it’s not pressing to me? Testing is going on in my building and I will not do any software deployments during this time. For my particular situation and needs - I think it is best to move to the new client via imaging instead of all at once.


  • Testers

    What does the task list on the server show? From scanning the log it appears the server is being contacted and it knows it should reboot if there is a task, but it isn’t finding a task. I wonder if the MAC address is wrong on the server, not sure who all has access to your FOG server but could be someone accidentally changed the MAC. I know it has happened to me especially when someone new gets access and starts poking around on the server. It will be great if more granular rights can be given in the future.

    Also if you are on Trunk, as you indicate with SVN445 is there a reason why you are not wanting to use the new client? The new client works much better with Trunk as it each are being developed together. I assume the @Developers are not really focusing on maintaining the compatibility with the legacy client as it is being depreciated.


  • Moderator

    @ITSolutions It’s a desktop, an Optiplex 7010 with Windows 7 specifically.


  • Testers

    Is this a laptop? If so I know the legacy client had a few issues if the wireless was on and connected to Ethernet. Try turning off the wireless and see if that helps.


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.