Xen DomU hanging at "Checking for hardware changes"? Check your xenconsoled in your Dom0.

Dear self,
This is the second time this has happened to me, so I'm writing to you, my future self, a quick note so you don't have to relearn this a second time.

If when restarting a DomU, the DomU hangs at "Checking for hardware changes", check on the Dom0 to see if your xenconsoled has died. If so, restart it (ie. /usr/sbin/xenconsoled) and it should immediately fix the hanging DomUs.

This guy has a blog post with same issue, but I don't think he ever figured it out because he took a scorched-earth route to fix the problem. However, it does have a nice screen shot of what the hung DomU looks like.


Yours truely,

yourself

Making pepper sauce

 

Habenero, garlic, cilantro, lime juice, salt.

Stupidity, brought to you by the letter L

I grabbed some time formatting code from an older project of mine to use in my current project.

However, I noticed that the constants defined at the top of the class had some weird values. The constant, number of milliseconds per whatever, was ending in a 1 instead of a 0. My first thought was that a co-worker had mangled my source to fix some stupid off-by-one time issue they were having, incidentally breaking everything else that relied on that constant.

While 600 to 601 is a plausible change, 60 milliseconds per minute to 600 milliseconds per minute should have set off alarm bells in my head.

I spent several minutes grepping through the svn repository trying to find the lazy rat-bastard that had messed with my code, only to find that it wasn't a '601' but a '60l' (60L). The L is there to force the value into a long integer type.

Lesson learned? Use uppercase L.