[Please Cc me on replies as I'm not subscribed to the ML but
read/write through gmane. Thanks]
Hi,
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.
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.
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.
Affected: The problem affects at least (verified) current
Debian/unstable and Debian/testing.
Rationale
=========
People having to deal with chroots for deployments or building live
systems usually want to ship grub as bootloader. Then grub needs to
be installed as *package* inside the chroot *without* the need for
an existing grub.cfg and having grub in the boot sector of any
physical device of the build system. Instead grub is being used as
bootloader on the later deployed system/live system instead. So grub
being installed in a chroot without directly accessing/using it
there is necessary and common practice. This works for the grub
package itself just fine, but fails for any package that wants to
install additional menu files through update-grub.
Implementing the according logic (when to execute update-grub and
when not) inside the non-grub packages isn't a reasonable approach
IMHO because it would require changes in *any* single package as
soon as *something* needs to be changed, instead of adjusting just
the interface script once when necessary.
What I'm searching for
======================
An official and clean way how packages can interact with grub
without failing in situations like the mentioned openvz setup.
Addon: It would be nice if there's a way to skip grub commands
inside chroots completely (and that there's no need for mount --bind
of /dev). It's often not needed as the hardware of the chroot
doesn't match the system where grub is finally being used (for
example also see #538118).
Possible solutions
==================
1) Maintainer scripts of non-grub packages use 'update-grub || true'
so the grub-probe call doesn't cause the package to fail its
installation (which doesn't affect chroots only but is just
a workaround then).
2) The grub package provides a way to disable any grub related
commands like update-grub, grub-install,... so they can be just
called by the maintainer scripts of non-grub packages without
having to deal with situations like openvz. (Could be realized by
preseeding and/or a configuration file.) Could be combined with a
dpkg trigger.
3) grub-probe learns how to deal with the openvz situation (though
this might fail in other similar and existing situations and doesn't
really solve the interface issue AFAICT).
4) The grub package provides an official interface to update-grub
for maintainer scripts. Like policy-rc.d exists for invoke-rc.d a
specific interface for grub would provide maintainers as well as
admins a way to configure grub setup and its command execution
according to their needs. Could be combined with a dpkg trigger as
well.
Details regarding /proc/mounts of the setup in question
=======================================================
On the host system:
# mount
/dev/md1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
# cat /proc/mounts
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/md1 / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
/var/lib/vz/private/3000 /var/lib/vz/root/3000 simfs rw 0 0
tmpfs /var/lib/vz/root/3000/lib/init/rw tmpfs rw,nosuid,mode=755 0 0
proc /var/lib/vz/root/3000/proc proc rw,nosuid,nodev,noexec 0 0
sysfs /var/lib/vz/root/3000/sys sysfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lib/vz/root/3000/dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /var/lib/vz/root/3000/dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
[...]
Inside the openvz container:
# vzctl enter 3001
entered into VE 3001
# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
simfs on / type simfs (rw)
# cat /proc/mounts
simfs / simfs rw 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,mode=600 0 0
Inside the chroot:
# mount --bind /dev /grml/grml-live/grml_chroot/dev
# chroot /grml/grml-live/grml_chroot
# mount -t proc none /proc
# mount -t sysfs none /sys
# mount
sysfs on /sys type sysfs (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
# cat /proc/mounts
simfs /dev simfs rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
=====================================================================================
If I can provide any further information/help/... please let me
know, I can easily reproduce the above mentioned issue.
-mika-
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
