On Mon, Jan 02, 2017 at 12:37:32PM +0100, Thorsten Glaser wrote:
> On Sat, 31 Dec 2016, Colin Watson wrote:
> > The current postinst is certainly trying to use ucf in such a way, so
> > let's try to debug this. Please could you:
>
> Oh ok. Let me check that this system is affected first…
Thanks, and sorry for once again taking a while to get round to this.
> > * attach /var/lib/ucf/cache/:etc:default:grub
> > * attach /etc/default/grub
>
> Attached.
>
> > * show the output of "grep /etc/default/grub /var/lib/ucf/hashfile"
>
> tglase@tglase:~ $ grep /etc/default/grub /var/lib/ucf/hashfile
> fe09266a730fcba271f832ebb82a6a91 /etc/default/grub
>
> > With any luck that will be enough to make some progress here.
>
> OK, thanks!
Unfortunately, when I put these in place in a VM, I couldn't reproduce
your bug; and the information here looks right, in that the hash in
/var/lib/ucf/hashfile matches the hash of
/var/lib/ucf/cache/:etc:default:grub. There must be something a bit
more subtle happening, or else I'm being stupid.
I guess we need to break out bigger guns. Could you do the same
package-reinstall procedure as before, only this time:
* temporarily edit /usr/bin/ucf, changing its initialisation from:
DEBUG=0
VERBOSE=''
to:
DEBUG=1
VERBOSE=1
* export DEBCONF_DEBUG=developer in the environment
That should let me see both what ucf is doing and (enough of) what the
GRUB postinst is doing.
Thanks,
--
Colin Watson [cjwat...@debian.org]
