Sign in to follow this  
Followers 0
mchipser

Cable not connected after updates

20 posts in this topic

Well that would confirm the guess about a strange timing issue (whatever it might cause it) on the specific system only when running the AutoIT.

IF this timing issue is connected to "software", if you restore to the "queer machine" a sysprepped image coming from another one BEFORE the update, maybe you can re-run the autoit successfully, if it's a hardware originated issue, you should not (unless it was a one-time glitch in the matrix).

jaclaz

The problem is..

We start with image rev A and apply patches to systems that have the image every quarter, until a new rev B comes out. These revs all come from masters or as Microsoft likes to call them the reference machines. I manually update the masters and pull a new image for deployment which include the rollup. This image and the base image all work normal on the machine. I have two of these machines and they are both doing the same exact thing. I have 20 other models and they work normal.

What timing could be the issue? When the patches are applied? I could add a sleep between those, or I can do a runonce and add each one on every reboot :)

0

Share this post


Link to post
Share on other sites

What timing could be the issue? When the patches are applied? I could add a sleep between those, or I can do a runonce and add each one on every reboot :)

The most logical (though not necessarily the one that causes the issue) would be some update that "interrogates" the system (either software or hardware) and "spawns" one or more "child process(es)" that are not terminated soon enough, i.e. before the "next" update starts.

The matter must be a question of fractions of seconds (or seconds).

I would try inserting a 5 or 10 seconds "sleep" between each update and see what happens, it will add the most 2 minutes to the update time, which I presume is much more "bearable" than doing several reboots.

Of course actions like removing the java updater should be totally irrelevant.

jaclaz

0

Share this post


Link to post
Share on other sites

The most logical (though not necessarily the one that causes the issue) would be some update that "interrogates" the system (either software or hardware) and "spawns" one or more "child process(es)" that are not terminated soon enough, i.e. before the "next" update starts.

The matter must be a question of fractions of seconds (or seconds).

I would try inserting a 5 or 10 seconds "sleep" between each update and see what happens, it will add the most 2 minutes to the update time, which I presume is much more "bearable" than doing several reboots.

Of course actions like removing the java updater should be totally irrelevant.

jaclaz

It appears this is working.. I am still testing it though..

Thanks!!

0

Share this post


Link to post
Share on other sites

It appears this is working.. I am still testing it though..

Thanks!!

Well didn't work.. There is another piece to the puzzle..

If the cable is unplugged when doing the rollup, then after the system reboots we plug the cable back in, the cable is never seen to be plugged in. However if the cable stays plugged in while doing the rollup the cable is detected.

This doesn't make any sense.

0

Share this post


Link to post
Share on other sites

Well didn't work.. There is another piece to the puzzle..

If the cable is unplugged when doing the rollup, then after the system reboots we plug the cable back in, the cable is never seen to be plugged in. However if the cable stays plugged in while doing the rollup the cable is detected.

This doesn't make any sense.

I concur. :yes:

Really weird. :w00t:

jaclaz

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.