Block ASL3 install if dahdi-dkms install fails

[Allan-N]

Despite our cautions in the ASL3 Manual of issues with "cloud" kernels that doesn't appear to keep people from trying the install and then running into problems later.

And an example of this occurred on a recent Ham Radio 2.0 YouTube video.

Can we detect the mismatch and block the install? or scream loudly?

[jxmx]

As we discussed in Slack, there isn't a direct synchronous tie between the package installations and the building of the DKMS modules. By necessity, that's a "trigger" model and the dahdi-dmks package is "successful" in its installation once it triggers DKMS to do something. The fact that DKMS's build didn't work because of other issues isn't technically the dahdi-dkms package's problem or fault such that it should stop and rollback.

There's a couple of ways we could handle this (just thinking out loud)

1. Have the asl3 package itself print a warning - maybe with a sleep 5 or something - that a "cloud" kernel has been detected and to follow some set of directions.

2. Modify the asterisk.service to detect a missing DAHDI module and error out rather than boot-to-brokenness. I have mixed feeling about doing this though.

3. Create something that watched /var/log/asterisk/messages.log that complains loudly to syslog about broken DAHDI. However I'm not sure how much more successful that would be vs. someone inspecting /var/log/asterisk/messages.log to begin with.

[jxmx]

With the pending resolution of cloud kernels in the new dahdi-dkms_3.4.0-5+asl package, I think this item is now a corner-case at best.