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 [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
