I build live images, similar to the official Debian Live images.
The issue below has annoyed me for many years, but
it was only today someone suggested this might actually be a *BUG*.

A minimum recipe to reproduce this is:

    $ mmdebstrap sid sid.tar.zst \
          --components='main contrib non-free' \
          --include=intel-microcode \
          --essential-hook='>$1/etc/default/intel-microcode echo IUCODE_TOOL_INITRAMFS=yes IUCODE_TOOL_SCANCPUS=no' \
          --verbose
    [...]
    Setting up intel-microcode (3.20201118.1) ...

    Configuration file '/etc/default/intel-microcode'
     ==> File on system created by you or by a script.
     ==> File also in package provided by package maintainer.
       What would you like to do about it ?  Your options are:
        Y or I  : install the package maintainer's version
        N or O  : keep your currently-installed version
          D     : show the differences between the versions
          Z     : start a shell to examine the situation
     The default action is to keep your current version.

At this point the build hangs forever.
(And without --verbose, it is not even obvious that it has hung!)

The reason this matters is that the ramdisk is built at kernel installed time.
So I have four bad choices:

    [A] This recipe hangs:

        1. configure /etc/default/intel-microcode
        2. install all packages (inc. kernel & intel-microcode)

    [B] This recipe builds an insecure ramdisk (some microcode missing):

        1. install all packages (inc. kernel & intel-microcode)
        2. configure /etc/default/intel-microcode

    [C] This recipe rebuilds the ramdisk twice, adding about 1 minute (20%) to the total build time:

        1. install all packages (inc. kernel & intel-microcode)
        2. configure /etc/default/intel-microcode
        3. manually rebuild ramdisks with "update-initramfs -u -k all"

    [D] This recipe works but requires manually calling apt a second time,
        AFTER mmdebstrap has cleaned away all the apt lists (i.e. also slow):

        1. install everything EXCEPT the kernel (inc. intel-microcode)
        2. configure /etc/default/intel-microcode
        3. manually apt update and manually apt install kernel

ALLEGEDLY when DEBIAN_FRONTEND=noninteractive (which mmdebstrap does),
that prompt should not appear, and method [A] should Just Work.


Is this reasonable?

Sorry I can't cite chapter-and-verse of the Debian Policy right now.


PS: this issue also affects debootstrap but the recipe is longer, slower, and uglier.

PS: it's possible this applies to lots of packages, and
I just don't trigger it because 99% of them support "dropin" dirs
(e.g. rsyslog.d/foo.conf instead of rsyslog.conf).
If there's a dropin dir I can use for /etc/default/intel-microcode,
that's Good Enough for me.


PS: amd64-microcode has the exact same problem:

        $ mmdebstrap sid sid.tar.zst \
              --components='main contrib non-free' \
              --include=amd64-microcode \
              '--essential-hook=>$1/etc/default/amd64-microcode echo AMD64UCODE_INITRAMFS=yes' \
              --verbose
        [...]
        Configuration file '/etc/default/amd64-microcode'
         ==> File on system created by you or by a script.
         ==> File also in package provided by package maintainer.
           What would you like to do about it ?  Your options are:
            Y or I  : install the package maintainer's version
            N or O  : keep your currently-installed version
              D     : show the differences between the versions
              Z     : start a shell to examine the situation
         The default action is to keep your current version.
        [hangs]

    I can't see anything in /var/lib/dpkg/info/*microcode*inst that
    looks relevant, so maybe this is a dpkg issue?

That is a DPKG prompt, about a changed "conffile".  You need to tell
dpkg what it should do when it detects that a "conffile" has been
changed [prior to installation of a package].  Keep in mind dpkg also
prompts for this when a package upgrade changes a conffile that has been
locally modified.

Your options are in the dpkg manpage, and I don't know how you'd tell
mmdebstrap how to specify them.

If this is a bug, it affects *all* packages using conffiles
(configuration files managed by dpkg) and mmdebstrap's method of
preseeding them.

dpkg is not debconf (which responds to DEBIAN_FRONTEND), it is far more
low-level / basic.

There's no dropin dir, as that'd be overkill for something like
intel-microcode.

For the same reason, it uses a plain dpkg conffile instead of elaborate
script-driven "config files", which you could deal with through
preseeding and DEBIAN_FRONTEND=noninteractive.

It is an issue on how mmdebstrap and other such utilities interact with
dpkg and user-modified conffiles, yes.  And it affects every package
that uses conffiles.

Thanks for the prompt reply; discussion follows.

Henrique de Moraes Holschuh wrote:

Thanks, I did not realize DEBIAN_FRONTEND= only affected debconf.

OK, I think you are referring to --force-{confold,confnew,confdef}.

If I add force-confold to /etc/dpkg.cfg.d/blah it does indeed bypass this issue.[0]

(force-confold feels a bit brute-force -- since there's only a single
"apt-get install" call, it applies to everything -- but I guess it's
no worse than DEBIAN_FRONTEND=noninteractive.)

I'll move this over to the mmdebstrap package so the mmdebstrap
maintainer can set dpkg force-confXXX next to
DEBIAN_FRONTEND=noninteractive --- or at least document the issue in
the mmdebstrap manpage.

(Maybe this is already documented for debootstrap in
installation-guide-amd64 and I just never found it?)


[0]

    twb@not-omega:~$ mmdebstrap sid sid.tar.zst --components='main contrib non-free' --include=amd64-microcode '--essential-hook=>$1/etc/default/amd64-microcode echo AMD64UCODE_INITRAMFS=yes' --verbose --dpkgopt=force-confold --customize-hook='cat $1/etc/default/amd64-microcode'
    [...]
    I: running --essential-hook in shell: sh -c '>$1/etc/default/amd64-microcode echo AMD64UCODE_INITRAMFS=yes' exec /tmp/mmdebstrap._D0TIGFL66
    [...]
    Setting up amd64-microcode (3.20191218.1) ...

    Configuration file '/etc/default/amd64-microcode'
     ==> File on system created by you or by a script.
     ==> File also in package provided by package maintainer.
     ==> Using current old file as you requested.
    [...]
    I: running --customize-hook in shell: sh -c 'cat $1/etc/default/amd64-microcode' exec /tmp/mmdebstrap._D0TIGFL66
    AMD64UCODE_INITRAMFS=yes
    [...]
    I: success in 36.8867 seconds