Bug#921702: grub2 2.02+dfsg1-10 ignores user input at debconf prompts

[Colin Watson]

On Thu, Feb 07, 2019 at 10:17:54PM -0800, Steve Langasek wrote:
> The changes to ucf handling in grub2 2.02+dfsg1-10 result in any changes the
> user tries to make to their config via dpkg-reconfigure being ignored.
> 
>  - user edits the kernel commandline through debconf prompt
>  - postinst script applies the change to the "new" /etc/default/grub via a
>    tmpfile
>  - /usr/share/grub/default/grub is unchanged vs
>    /var/lib/grub/ucf/grub.previous
>  - UCF_FORCE_CONFOLD=1 is passed, which means the new config in the tmpfile
>    is completely ignored in favor of the copy already in /etc/default/grub

I spent some time today reflecting on our IRC conversation the other day
regarding
https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/362869,
and doing some experiments.

I've changed my mind from what I said on IRC, and I think I now agree
with you that it's necessary to apply debconf answers directly to
/etc/default/grub; doing so arguably also produces less confusing
debconf prompts in the case of a ucf conflict, so it's probably a good
thing.  However, I do still think we need to be a bit more careful in
two ways:

 * /etc/default/grub may not exist at the relevant point in the case of
   a fresh installation, and there's one case given your patch where I
   believe that will cause sed to fail and trip "set -e".

 * There was one case where $tmp_default_grub was being edited and you
   hadn't added a corresponding edit of /etc/default/grub.  I think we
   need a bit more machinery to make it harder to make this kind of
   mistake, as it's hard to spot.

And since this is all difficult to reason about, I've added a good deal
of commentary for future travellers.

Hopefully this will all work better now!

  https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/362869

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]