Re: execution of update-grub in chroots might fail

[Felix Zielcke]

Am Montag, den 14.12.2009, 11:56 +0000 schrieb Colin Watson:
> On Sun, Dec 13, 2009 at 11:08:04PM +0100, Michael Prokop wrote:
> > 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 ...)

I wonder too why he wrote that. When I talked with him on IRC yesterday,
I mainly said that using `update-grub || true' would be wrong. And
neither me nor Robert (at leat until I was on IRC which was though later
then he wrote this mail) not at all anything that says there's a written
policy for interacting with GRUB things or even that the above thing is
the recommended and suggested way.

> > 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.

We have alredy changed our postinst some time ago to only execute when
either grub.cfg already exists or when grub-install gets run in the
postinst.

> 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?
> 

Why so complicated?
We use just `touch /boot/grub/grub.cfg' in the grub-pc/install_devices
part and then at the end of postinst we check if it exists and then run
update-grub
The same could be done in grub-installer now without needing to modify
anything else.

Sad that we can't make update-grub a trigger. At least as long as nobody
comes up with a great solution which makes sure the system is always
bootable even if it's not run or that the trigger is always run even if
the dpkg/apt run aborts.
Then we could control when update-grub gets run in our postinst instead
of every package which wants/needs to run it.

Then if we add a check for grub.cfg in the update-grub stub, the only
question is if we should print a warning that it doestn't do anything or
not in case grub.cfg doesn't exist.
-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer