Re: execution of update-grub in chroots might fail

[Colin Watson]

On Sun, Dec 13, 2009 at 11:08:04PM +0100, Michael Prokop wrote:
> as reported in #550337 update-grub might fail inside chroots.
> I'm providing detailed information about this issue in this mail as
> discussed on IRC in #grub.

update-grub is actually a Debian-specific wrapper around grub-mkconfig.
While some of the issues you raise might be fixed in grub-mkconfig, I
think that the necessary change may well actually be in the Debian
packaging.

> Situation
> =========
> 
> For example postinst of memtest86+ uses:
> 
>   if [ "$1" = "configure" ] && [ -x "`which update-grub2 2>/dev/null`" ] ; 
> then
>       update-grub2
>   fi
> 
> which is the recommended and suggested way to install grub menu entries.

Recommended where? (This implies the existence of documentation on the
subject, which I wasn't aware of ...)

> Problem
> =======
> 
> When executing update-grub the command might fail. For example it
> *does* fail inside chroots on openvz containers (see end of mail for
> full details regarding the setup in question):
> 
>   # update-grub2
>   grub-probe: error: cannot find a device for /.
> 
> Then the installation of for example the memtest86+ package fails.
> Recommended fixes were (binded) mounting /proc, /sys and /dev, though
> this is already present and doesn't help.
> 
> The problem is NOT the grub package itself (it installs and updates
> just fine). The problem exists in packages that call update-grub but
> don't have a clean interface *when* (and how) to execute it. See
> #481468 and #550337 for example.

The simplest fix is to add '&& [ -e /boot/grub/grub.cfg ]' to the test
in memtest86+; that is, if the configuration file hasn't been generated
already, it shouldn't be updated. (This check is in the memtest86+
postinst in Ubuntu.) This accounts for the OpenVZ problem as well as for
other reasons why GRUB might not actually be being used as a boot
loader.

You're right that it is suboptimal that every package has to implement
the check itself. My instinct is that the semantics of update-grub ought
to change slightly, so that it really is an *update* - that is, it
shouldn't by default generate a configuration file if there isn't one
already. It could have a --force option (or better name?) for
convenience, for use by the grub2 packaging itself, and for use by the
installer. Anything much more complex than that smells of
overengineering to me.

Note, though, that care would need to be taken to ensure that
grub-installer is changed in step; it's important to minimise the
chances of consequential installer brokenness. There's little urgency on
this so we could afford the time for a proper transition. For example,
update-grub could accept but ignore the new option for a while; then,
after the relevant version of grub2 has moved to testing, grub-installer
could be updated to use it; then, at some later point, the default
semantics of update-grub could change.

If that's too complicated, we could just add an --if-exists option or
something that does what memtest86+ and other similar packages need.
There are very few packages in this boat, so it may not be worth very
much effort to deal with them.

Robert, Felix, what do you think?

-- 
Colin Watson                                       address@hidden