• Hi there! We are fairly new to FOG, so we are still in the experimental phase of implementing this. But overall… so far so good!

    Anyways, we’ve sucessfully imaged hundreds of laptops and a handful of desktops in the past few weeks. Today, we tried imaging 6 desktop computers by stacking them on top of each other, then plugging in power and cat5 cable. We set the BIOS to pxe boot by default. So theoretically, the desktops should start up, pxe, queue in the multicast, and then begin downloading the image automatically.

    Problem is, we kept getting the error:

    “[FONT=Verdana][COLOR=#333333][I]irq#16: nobody cared (try booting with the “irqpoll” option)[/I]”[/COLOR][/FONT]

    [COLOR=#333333][FONT=Verdana]It would then roll through some of the normal FOG gargle, and then at the end would hang at “[/FONT][I]Checking in”[/I] with multiple asterisks as it counts down.[/COLOR]

    [COLOR=#333333]Anyways, after tinkering and googling for a while, I found that the irq might be due to some sort of I/O error with a port (internal or external) on the desktop. We plugged a monitor, keyboard and mouse into both computers (we reduced the load to 2 for testing purposes) and restarted the whole process. Both went off without a problem.[/COLOR]

    [COLOR=#333333]My question is, is hardware such as monitors, keyboards, and mice necessary for FOG to complete its self-checkup and begin the process? Or is this error due to a separate problem altogether? [/COLOR]

    [COLOR=#333333]P.S This is the very first time I’ve seen this type of error, and the other desktops we’ve done were already hooked up with monitors, mice, etc. So that’s another reason we’re thinking this is the problem.[/COLOR]

    [COLOR=#333333]Thanks for any feedback![/COLOR]

  • I set up one of the desktops alone with monitor, keyboard, and mouse all hooked up. Updated the kernel, which I think is why the “[I]checking in”[/I] error occurred. Fog worked fine.

    However, as a test I pulled out the VGA cable and plugged it back in during an image deployment, and [I]“irq#16: will be disabled” [/I](or something along those lines) message popped up in the FOG screen. So, even though I don’t understand how or why, it appears that this error is, in my case at least, related to monitor connections or the video cards. It’s possible that if the output changes in some way, FOG isn’t sure how to handle it.

    For assurance’s sake, we will just have our desktops fully hooked up from now on. Strange FOG would barf over something so trivial, but who knows.

    Thanks for your help Tom!

  • I’m not well versed in kernel argument passing, but it’s telling you that you should maybe start the system with the irqpoll options (kernel argument) on bootup. However, I don’t think this is the real problem. I think it’s more just a warning to you stating the kernel didn’t load that interrupt and it’s probably not needed for what you’re doing.

    Other than that, to my knowledge this issue could, possibly, be resolved with debugging the task to possibly get more information out of it. Maybe check your apache error_log/error.log file when it’s queued as well. My guess is the hosts just aren’t checking in for the MC task.