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 [cjwat...@debian.org]
