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