flash-kernel failed in an armhf lxc container on ARM: /usr/sbin/flash-kernel: 214: /usr/sbin/flash-kernel: mkimage: not found

This is interesting - thanks Jean-Baptiste.

So do we need to:

 - Not have a kernel image package installed in the container in the first place?
 - Arrange for flash-kernel not to be run inside a container (kernel postinst? update-initramfs postinst?)?
 - Make flash-kernel depend on u-boot-tools instead of merely suggesting it?

It is even more annoying because if you specify "apt_upgrade: true" in a cloud-config script and there is a package that triggers kernel hooks, then it breaks the provisioning of the lxc guest.

it breaks even without that directive.

Another test case to run on a day with a package upgrade that will run kernel hooks

1. Create the user-data file with the following content:
====8<========8<========8<========8<========8<====
#cloud-config
locale: en_US.UTF-8

password: ubuntu
chpasswd: { expire: False }
ssh_pwauth: True

ssh_authorized_keys:
 - SOMEPUBKEY

apt_sources:
 - source: deb http://archive.ubuntu.com/ubuntu raring restricted multiverse
 - source: deb-src http://archive.ubuntu.com/ubuntu raring restricted multiverse

byobu_by_default: system

packages:
 - eatmydata
 - autopkgtest
 - dpkg-dev
 - pbuilder
 - bzr

runcmd:
 - [sh, -xc, "echo '127.0.1.1 autopkgtest' >> /etc/hosts" ]
====>8========>8========>8========>8========>8====

2. On an ARM host provision an LXC guest with the command (replace user-data by the path to the user-data file you created above)
  $ sudo lxc-create -n raring-armhf-20130326_094008 -t ubuntu-cloud -- -r raring -a armhf -s daily -u user-data -T https://cloud-images.ubuntu.com/raring/current/raring-server-cloudimg-armhf-root.tar.gz

3. Start the container and wait
  $ sudo lxc-start -n raring-armhf-20130326_09400

@Robie: The right solution here is to do the same hack we have in grub, which is to using "running-in-container" to detect LXC and skip that part of the code.

/etc/kernel/postinst.d/zz-update-grub can be used as an example for that change if you're interested in fixing this issue yourself.

I'm also vaguely surprised that flash-kernel uses mkimage but doesn't depend on it, though that's a separate issue :)

Jean-Baptiste kindly tested this attached change, but it didn't work. He said that it still broke in the initramfs-tools postinst as it did before.

But I wonder - why is flash-kernel installed at all in the cloud images? Can we fix this by not including flash-kernel at all?

Moving to flash-kernel
LXC do not rootfs modifications from the templates. The proposed fix in attached branch do the equivalent of then environment variable FLASH_KERNEL_SKIP and skips flash-kernel run inside LXC container by checking the result of 'running-in-container'

Is there a sysvinit equivalent to running-in-container that would be suitable for inclusion in Debian?

(See bug #1160488 for why u-boot-tools shouldn't be a dep)

Generally, it's still a good idea to avoid installing flash-kernel in the container though.

I don't know if there is a sysvinit equivalent. For non-upstart systems, we could check the cgroup name in /proc/self/cgroup but I think systemd uses cgroup too so a name there wouldn't guarantee if we are or not in a container. Another solution would be to check if inode number of / is not 2 which would work for chroots and lxc.

As the branch fixing this bug already makes this appear on the sponsor's list I'm unsubscribing ubuntu-sponsors from this bug.

This bug was fixed in the package flash-kernel - 3.0~rc.4ubuntu30

---------------
flash-kernel (3.0~rc.4ubuntu30) raring; urgency=low

  * Do not run flash-kernel inside an LXC container (LP: #1160360)
 -- Jean-Baptiste Lallement <email address hidden> Wed, 27 Mar 2013 16:29:20 +0100