grub-pc.config prevents replacing with new config file contents

[molostoff]

A behavior of grub-pc.config does not allow to reach "replacing config file with new version", as shown below in a session listing:

# echo grub-pc grub2/linux_cmdline string acpi=force elevator=deadline | debconf-set-selections
# dpkg-reconfigure -f noninteractive grub-pc
Replacing config file /etc/default/grub with new version
Installation finished. No error reported.
Generating grub.cfg ...
...

The problematic code introduced in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/grub2/precise/revision/31/debian/grub-pc.config (lines 24-38)
(where it overwrites preseeded values in debconf database with call to db_set):

if test -e /etc/default/grub ; then
  . /etc/default/grub

  db_set grub2/linux_cmdline "$GRUB_CMDLINE_LINUX"
   db_set grub2/linux_cmdline_default "$GRUB_CMDLINE_LINUX_DEFAULT"

   case grub-pc in
   grub-pc)
      if [ "${GRUB_TIMEOUT}" != "" ]; then
        db_set grub-pc/timeout "$GRUB_TIMEOUT"
      fi
      if [ "${GRUB_HIDDEN_TIMEOUT}" != "" ]; then
        db_set grub-pc/hidden_timeout true
      elif egrep -q '^#?[[:space:]]*GRUB_HIDDEN_TIMEOUT=' /etc/default/grub; then
        db_set grub-pc/hidden_timeout false
      fi
    ;;
  esac
fi

Commenting it out makes the above example in listing to work.

I dont understand the purpose to update debconf preseed values with those from config file.
 (assuming db has these already calibrated before adding into db with 'interactive' backend)

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: grub-pc 1.99-21ubuntu3.7
ProcVersionSignature: Ubuntu 3.2.0-35.55-generic 3.2.34
Uname: Linux 3.2.0-35-generic x86_64
ApportVersion: 2.0.1-0ubuntu17
Architecture: amd64
Date: Sat Dec 15 21:04:37 2012
MarkForUpload: True
ProcEnviron:
 LANGUAGE=ru_RU
 TERM=xterm
 PATH=(custom, user)
 LANG=ru_RU.UTF-8
 SHELL=/bin/bash
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

[Colin Watson (cjwatson)]

The standard rules for debconf are that changes in the filesystem are more important than those in the debconf database. Have you tried simply changing /etc/default/grub rather than using debconf-set-selections?

[molostoff (molostoff)]

>> The standard rules for debconf are that changes in the filesystem are more important than those in the debconf database

Yes and this is monitored via ucf tools, as shown in sample config scripts (preinstall and postinstall).

Thus, if I have changed /etc/default/grub , then ucf will see my changes and would prevent them from being overwritten by automated updates/upgrades (creating grub.ucf-dist file, or providing 3-way merge or any other way it can offer).

If I somehow decided to overwrite my /etc/default/grub changes I have to direct ucf to forget about monitoring (via ucfr tool - just removing package config file from internal ucf list) , and then dpkg-reconfigure will successfully overwrite my changes using already preseeded parameters from debconf database.

I assume this way is legal, while voluntary unconditional update of debconf database is not, especially with those parameters which I whould like to recover. A typical situation is when I have changed one line in /etc/default/grub and got errorneous boot process, which I want to recover.

 With your code in grub-pc.config any ucf related things are just disconnected from being partify in this configuration process, and with your code I can recover only that errorneous modified version, since that errorneous parameter is already propagated into debconf database, and this looks like a nonsense action.

[molostoff (molostoff)]

partify = take a part