Comment 4 for bug 2011925

Thanks for the logs -- the latter is most interesting in that it indicates the eventual cycle *isn't* the first cycle error that occurs. One occurs earlier on flash-kernel's second execution, when the kernel is reported as being in "triggers-pending" state (presumably because its initrd hasn't been generated yet).

Because dpkg decides (for some reason I don't understand yet) that f-k has triggered a cycle *there*, it places the kernel in half-configured state (because the triggers it's awaiting have failed), and that explains the later cycle that gets triggered.

So, the question becomes: why is dpkg deciding that f-k has triggered a cycle that early when it doesn't in the Xilinx and Pi cases... Is there something different about this kernel to others? In particular, with regard to its initrd and corresponding initramfs-tools trigger?

In the meantime, I'll have a dig into the dpkg cycle detection and try and figure out why that first cycle is detected when it doesn't in the Xilinx and Pi cases.