Installing a kernel inside a openvz guest chroot fails with:

[....]
Setting up linux-image-2.6.35-grml64 (grml.00) ...
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.35-grml64 /boot/vmlinuz-2.6.35-grml64
update-initramfs: Generating /boot/initrd.img-2.6.35-grml64
[...]
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.35-grml64 /boot/vmlinuz-2.6.35-grml64
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.35-grml64.postinst line 346, <STDIN> line 2.
[...]

It's due to the failing update-grub command in
/etc/kernel/postinst.d/zz-update-grub:

  # update-grub
  /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

It fails because of the way openvz guests look like (simfs as
rootfs):

  # /usr/sbin/grub-probe --target=device /
  /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

  # cat /proc/self/mounts
  none /proc proc rw 0 0
  none /sys sysfs rw 0 0
  simfs /dev simfs rw 0 0

It works fine inside a KVM guest chroot which doesn't use the simfs
as rootfs:

  # /usr/sbin/grub-probe --target=device /
  /dev/vda1

  # cat /proc/self/mounts
  rootfs / rootfs rw 0 0
  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
  none /dev/pts devpts rw,nosuid,noexec,mode=600,ptmxmode=000 0 0
  /dev/disk/by-uuid/2bd80bd3-528c-431b-8b4a-47ecd1e27e24 / ext3 rw,errors=remount-ro,data=ordered 0 0
  [...]

  # readlink -f /dev/disk/by-uuid/2bd80bd3-528c-431b-8b4a-47ecd1e27e24
  /dev/vda1

I brought up a related issue on the grub mailinglist ~9 months ago:
"execution of update-grub in chroots might fail" ->
http://www.mail-archive.com/grub-devel@gnu.org/msg14328.html

And related as well (but not 100% similar) is issue #538118.
If you need further information, testing,... I'd be happy to help
out.

regards,
-mika-

What does linux expect as root= on command line in such config? How such
config can be detected and needed parameters figured out? Would it be
possible to have a root ssh access to such a system (since it's virtual
I guess you could copy one that contains no private data and wipe it
after we're done).

What does linux expect as root= on command line in such config? How such
config can be detected and needed parameters figured out? Would it be
possible to have a root ssh access to such a system (since it's virtual
I guess you could copy one that contains no private data and wipe it
after we're done).

* Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> [Mon Nov 08, 2010 at 05:33:41PM +0100]:

There's no root=... in the kernel command line involved, openvz
guests are like chroots.

There's a simple way to trigger the problem on your own:

  mount -o remount,rw,exec,dev,suid /dev/shm
  debootstrap sid /dev/shm/testchroot http://cdn.debian.net/debian
  mount --bind /dev /dev/shm/testchroot/dev
  chroot /dev/shm/testchroot /bin/bash
  apt-get install grub-pc
  grub-probe --target=device /

-> this will return:

  grub-probe: error: cannot find a device for / (is /dev mounted?).

as well - the same problem as with the openvz guest.
Building on tmpfs like on /dev/shm is actually not uncommon if speed
matters for a buildprocess.

Maybe testing for /dev/root and skipping update-grub/grub-probe
calls if the device doesn't exist is enough to resolve this issue?

regards,
-mika-

If I understand this statement correctly you mean that GRUB isn't used
to boot the system and grub.cfg isn't used, right? Then  update-grub
shouldn't be run at all. Perhaps you shouldn't even install GRUB
packages in this case.
(actually this information shifts the issue from my area [upstream] to
Debian-specific). Can someone familiar with packaging handle it?

* Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> [Mon Nov 08, 2010 at 06:23:09PM +0100]:

Correct.

When building live systems this isn't really an option. If GRUB
needs to be shipped (for example to provide a rescue system) it
needs to be installed inside the chroot that's being used to build
the live system.

regards,
-mika-

Linux kernel and many other packages inside very commonly used chroots
like openvz run update-grub as part of the installation process.  I use
it to maintain package installations on hundreds of servers
simultaneously.  Not being able to install any packages in the chroot
because the post install script calls update-grub and update-grub FAILS
is not good.

-- 

WERYFIKACJA KONTA W EMAILU

Drogi Kliencie,

Twoje konto e-mail przekroczyło swój limit i musi zostać zweryfikowane,
jeśli nie zostanie zweryfikowane w ciągu 24 godzin, zawiesimy Twoje
konto.

Aby uzyskać natychmiastowy dostęp, kliknij poniższy link: KLIKNIJ TUTAJ
[1]

Dziękuję Ci
IT ADMIN HELPDESK

Links:
------
[1] http://securityadminhelpdeskn.moonfruit.com/

Rozhodl jsem se vás kontaktovat kvůli naléhavosti spojené s touto otázkou,
jsem Julian Marshall, advokát. Já osobně jsem svěřeneckým agentem Dr.
Edwina, který byl zde v Lome Togo známým nezávislým dodavatelem, který
zemřel se svou ženou a jedinou dcerou při autonehodě. Kontaktoval jsem tě,
abys mi pomohl při repatriaci majetku fondu Dva miliony pět set tisíc
dolarů na váš účet. Prosím, kontaktujte mě pro více informací ohledně této
záležitosti.

Ahoj,

Zdravím vás. Prosím, laskavě mi dejte vědět své myšlenky na
financování příbuzných.

Těšíme se na Vaši odpověď.

S pozdravem

Pane Michael Mensa

This problem shows also in very similar form in live-boot environment:

Setting up linux-image-5.17.0-3-amd64 (5.17.11-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.17.0-3-amd64:Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
.
/etc/kernel/postinst.d/initramfs-tools:
I: update-initramfs is disabled (live system is running on read-only media).
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of `overlay'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-5.17.0-3-amd64 (--configure):
 installed linux-image-5.17.0-3-amd64 package post-installation script subprocess returned error exit status 1


While the grub obviously is not used in the live-boot environment itself,
due to construction of live-boot, it must be installed there. Then if the
users tries to perform an upgrade of packages inside the live
environment, it might trigger update of the kernel packages too, which
will fail at update-grub as presented above.

Would be nice to detect this chroot and live-boot enviornments, and skip update-grub.

Even on live-boot environment, /boot/grub/grub.cfg does exist, and while
modifying it (as it is on overlay fs), will not accomplish much (changes
are not persisted to the underlying medium), upgrade should not fail.

Regards,
Witold