awful hack to avoid kernel-helper debconf clash

[Colin Watson]

Binary package hint: oem-config

I've had to institute an awful hack in oem-config-firstboot to work around a clash with an /etc/event.d script in Intrepid. It's perhaps easiest if I just quote the code and its accompanying comment, added in oem-config 1.47:

# TODO: This is an awful, awful hack. In Ubuntu intrepid, kernel-helper runs
# from an /etc/event.d script (in parallel to rc2) and uses debconf; as a
# result, it is often running while oem-config is trying to start and locks
# the debconf database. I can't think of a way to declare that
# /etc/event.d/last-good-boot needs to complete before our single init
# script in rc2 starts, so we're left with this piece of pure evil.
while pidof -x kernel-helper; do
        sleep 1
done

Scott, is there something better I can do here?

[Scott James Remnant (Canonical) (canonical-scott)]

It's not *that* awful ;)

It's quite racy though, since kernel-helper could actually start as you get to "done" and then you'll have exactly the same problem.

[Colin Watson (cjwatson)]

Perhaps the real problem is that using debconf asynchronously during the boot sequence is not in fact an excellent plan composed solely of kittens.

[Colin Watson (cjwatson)]

Racy: yes, that was pretty much exactly my point, though perhaps I could have spelled it out more clearly. I suppose I figured anyone competent to change that code would see the pidof and recognise this. :-)

[Scott James Remnant (Canonical) (canonical-scott)]

Actually I was more thinking that your code waits for a condition to become false before continuing, on the assumption that it has been true at some point in the past.

When in fact, the very nature of asynchronousity means that the condition may be yet to become true when this code runs.

Upstart may be fully intending to run kernel-helper, but may simply not have gotten around to it yet. Your test passes, you start your code, and kernel-helper comes along later and thwarts you right at the point you thought you'd guarded.

You could vaguely rely on Upstart's goal for the job that runs kernel-helper, it will be "start" at any point after the runlevel 2 event until kernel-helper has actually exited. Obviously this only guards against being run from Upstart...

  while status last-good-boot | grep -q '(start)'; do
    sleep 1
  done

You could even avoid a sleep here ;)

  initctl jobs | sed -n -e '/^last-good-boot (stop)/q' &
  WAIT=$!
  if status last-good-boot | grep -q '(stop)'; then
    kill $WAIT
  else
    wait $WAIT
  fi

But we're still skirting around the merciless murder of kittens going on in the background.

Could you not take a debconf lock out, where you wait for it to be free (assuming last-good-boot has a debconf lock while it tries to run?)

[Colin Watson (cjwatson)]

There actually is a lock; the problem is waiting for it to be free rather than just falling over. The fact that the lock is taken out deep in the internals of debconf and the result of it failing is a message on stderr and an exit code, not a nice exception, doesn't help.

You're probably right that waiting for the lock is the right answer though (short of making last-good-boot not use debconf in the boot sequence in the first place!). Thanks.

[Colin Watson (cjwatson)]

This is no longer a problem for Intrepid since Ben has disabled last-good-boot by default. It may be a problem for future releases if it continues to use update-grub and update-grub continues to use debconf in all modes.

[Colin Watson (cjwatson)]

Since last-good-boot and kernel-helper are all gone, replaced (conceptually) with smarter code in grub2, this is no longer an issue; and the offending code in oem-config-firstboot was removed long ago.