build fails in chrooted system

I know that I asked you to report this problem but now that I recall the use case for the code I don't think it's a bug.

If you don't pass the -k parameter to update-initramfs, it uses the latest kernel by default.

In the following code, the initramfs is always called for the latest kernel, however if you're installing the driver after booting from an older kernel (which therefore is your current kernel), the initramfs for this kernel will be updated too.

        ALTERNATIVE=$(readlink /etc/alternatives/gl_conf)
        if [ "$ALTERNATIVE" = "/usr/lib/nvidia-current/ld.so.conf" ]; then
            # Update initramfs so that the blacklist ends up in the initramfs
            update-initramfs -u

            if [ -n "$NEWEST_KERNEL" ] && [ ${CURRENT_KERNEL} != ${NEWEST_KERNEL} ]; then
                update-initramfs -u -k $CURRENT_KERNEL
            fi
        fi

I understand that in a chroot this can be a problem. Would it be ok if I simply did "update-initramfs -u -k $CURRENT_KERNEL || true" so that the installation doesn't fail in chroots?

I'm ok with that workaround. Tks for the quick patch proposal.

Ok, thanks for your feedback

Note: the problem also affects the fglrx driver

This bug was fixed in the package fglrx-installer - 2:8.721-0ubuntu8

---------------
fglrx-installer (2:8.721-0ubuntu8) lucid; urgency=low

  * debian/rules, fglrx.dirs, fglrx.postinst:
    - Install the blacklist file in /lib/fglrx instead of
      /usr/lib/fglrx so that the file is available early
      in the boot process when /usr is on a different
      partition (LP: #538071).
    - Ignore errors when trying to update the initramfs
      with -k $CURRENT_KERNEL which is known to fail when
      using chroots (LP: #556653).
    - Make 10fglrx a slave link so that it's removed from
      /etc/X11/Xsession.d when we switch to a different
      alternative (LP: #552903).
  * debian/fglrx.preinst:
    - Make sure that any 10fglrx file in /etc/X11/Xsession.d
      which is not a symbolic link is removed.
    - Remove diversions previously added by xorg-driver-fglrx
      not by fglrx (LP: #552782). Thanks to Steve Langasek
      for spotting the problem.
 -- Alberto Milone <email address hidden> Thu, 08 Apr 2010 18:37:48 +0200

This bug was fixed in the package nvidia-graphics-drivers-96 - 96.43.14-0ubuntu12

---------------
nvidia-graphics-drivers-96 (96.43.14-0ubuntu12) lucid; urgency=low

  * debian/nvidia-$flavour.{dirs|postinst}.in, rules:
    - Install the blacklist file in /lib/nvidia-$flavour instead
      of /usr/lib/nvidia-$flavour so that the file is available
      early in the boot process when /usr is on a different
      partition (LP: #538071).
    - Ignore errors when trying to update the initramfs
      with -k $CURRENT_KERNEL which is known to fail when
      using chroots (LP: #556653).
 -- Alberto Milone <email address hidden> Fri, 09 Apr 2010 13:03:03 +0200

This bug was fixed in the package nvidia-graphics-drivers-173 - 173.14.22-0ubuntu11

---------------
nvidia-graphics-drivers-173 (173.14.22-0ubuntu11) lucid; urgency=low

  * debian/nvidia-$flavour.{dirs|postinst}.in, rules:
    - Install the blacklist file in /lib/nvidia-$flavour instead
      of /usr/lib/nvidia-$flavour so that the file is available
      early in the boot process when /usr is on a different
      partition (LP: #538071).
    - Ignore errors when trying to update the initramfs
      with -k $CURRENT_KERNEL which is known to fail when
      using chroots (LP: #556653).
 -- Alberto Milone <email address hidden> Fri, 09 Apr 2010 13:10:28 +0200

This bug was fixed in the package nvidia-graphics-drivers - 195.36.15-0ubuntu2

---------------
nvidia-graphics-drivers (195.36.15-0ubuntu2) lucid; urgency=low

  * debian/nvidia-$flavour.{dirs|postinst}.in, rules:
    - Install the blacklist file in /lib/nvidia-$flavour instead
      of /usr/lib/nvidia-$flavour so that the file is available
      early in the boot process when /usr is on a different
      partition (LP: #538071).
    - Ignore errors when trying to update the initramfs
      with -k $CURRENT_KERNEL which is known to fail when
      using chroots (LP: #556653).
 -- Alberto Milone <email address hidden> Fri, 09 Apr 2010 13:18:57 +0200

I'm testing the natty package in the same chrooted environment, and although the implemented fix allows the configuration to be successful, a bogus file /boot/initrd.img-2.6.xx-yy-generic (ie initrd.img-2.6.35-28-generic if running on a maverick host) is generated.
That file is an incomplete initrd image, since all the modules from the host kernel are missing, but more important it breaks the livecd build process using Debian's live-build.

A working workaround (tested) would be to check for the kernel existence, something like:

            if [ -n "$NEWEST_KERNEL" ] && [ ${CURRENT_KERNEL} != ${NEWEST_KERNEL} ]; then
                # This can fail when dealing with a chroot see LP: #556653
  if [ -e /boot/config-$CURRENT_KERNEL ]; then
      update-initramfs -u -k $CURRENT_KERNEL || true
  fi
            fi

Ideally package should use KVERS and KVERSION within the environment wrt kernel modules.

can you attach the image build log, please?

Attaching the transcript of the debug session.

Upon entering the chroot env, after receiving the error once, I cleaned the remnant initrd file.
The I modified the postinst script inserting a set -x, set GL to be provided by MESA and reconfigured the package. No errors.
Then I configured nvidia for GL and reconfigured again the package. Errors are shown in the log.
Finally I edited the postinst again, insterted the above check and reconfigured the package. No errors.

It is still not possible to install nvidia-current in a chrooted environment if the kernel name of the running kernel (e.g. 2.6.38-10-server) is different to the kernel name of the chroot (e.g. 2.6.38-10-generic).

(The system tries to locate modules.dep in /lib/modules/2.6.38-10-server/ in the chroot.)

--
The system I have tried is 11.04.

To add to #14 comment, a file in /var/lib/initramfs-tools also gets generated if the host kernel differs from the chroot environments kernel.

In my case I'm running a Debian system with the 4.9.0-6-amd64 kernel and a Ubuntu (Xenial) chroot environment with the 4.4.0-127-generic kernel. When installing the nvidia-384 package inside the chroot environment the /var/lib/initramfs-tools/4.9.0-6-amd64 file gets generated.

# ls -l /initrd.img
lrwxrwxrwx 1 root root 29 Apr 5 11:31 /initrd.img -> boot/initrd.img-4.9.0-6-amd64
# ls -l /target/initrd.img
lrwxrwxrwx 1 root root 33 Jun 8 23:03 /target/initrd.img -> boot/initrd.img-4.4.0-127-generic
# ls -l /target/var/lib/initramfs-tools/
total 8
-rw-r--r-- 1 root root 77 Jun 8 23:06 4.4.0-127-generic
-rw-r--r-- 1 root root 73 Jun 8 23:08 4.9.0-6-amd64

(/target is the chroot environment)

The /var/lib/initramfs-tools/4.9.0-6-amd64 file is dangerous since update-initramfs will think that it's a valid existing kernel and produce errors as the following that will prevent updating the initrd in the future.

# chroot /target
sh-4.3# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.9.0-6-amd64
WARNING: missing /lib/modules/4.9.0-6-amd64
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.9.0-6-amd64: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open /var/tmp/mkinitramfs_s6nF9f/lib/modules/4.9.0-6-amd64/modules.order: No such file or directory
depmod: WARNING: could not open /var/tmp/mkinitramfs_s6nF9f/lib/modules/4.9.0-6-amd64/modules.builtin: No such file or directory