Ben Schwartz's picture

UPDATE: Narrowed down the problem.  When a TKL patch contains acpid (specifically acpid_1.0.4--5ubuntu9.3_i386.deb), the build gives a long stream of errors like

Failed to read file turnkey-mediawiki-2009.10-2-hardy-x86.rootfs/proc/irq/9/smp_affinity, creating empty file

Failed to read file turnkey-mediawiki-2009.10-2-hardy-x86.rootfs/proc/kallsyms, creating empty file

The build ultimately fails with

Failed to read file turnkey-mediawiki-2009.10-2-hardy-x86.rootfs/proc/kcore, creating empty file

Failed to read file turnkey-mediawiki-2009.10-2-hardy-x86.rootfs/proc/key-users, creating empty file

It fails at 27% completion, with proc-chroot still mounted on /root/turnkey-mediawiki-2009.10-2-hardy-x86.rootfs/proc.

So something about the acpid package seems to be causing tklpatch to try to package up the contents of procfs, which of course is not going to work.  I can work around this by installing acpid manually after installation, but I'd rather not.  This seems like a bug in tklpatch, but maybe I'm doing something wrong.

UPDATE: I believe this is a bug in tklpatch.  We successfully worked around it by creating a tklpatch that adds the acpid .deb and a script to live-installer.d using the overlay/ mechanism.  The script invokes dpkg to install the .deb.

Liraz Siri's picture

Thanks for reporting this and sorry for getting back to you late. We've been insanely busy recently with the Hub launch and the upcoming Lucid builds.

What's probably happening is that once you install ACPID, it spawns a daemon which opens /proc and prevents it from being unmounted. That's the reason the build fails.

The solution is for tklpatch to kill any process that is opening /proc before it umounts, or at least fail if it can't umount. Not sure why it doesn't.

In the meantime, one workaround you could try is to kill your daemon in the conf/post-debs script.

Ben Schwartz's picture

The best suggestion I've seen is:

the debootstrap method for this is:
mv ${ROOT_DIR}/sbin/start-stop-daemon ${ROOT_DIR}/sbin/start-stop-daemon.REAL
cat >${ROOT_DIR}/sbin/start-stop-daemon<<EOF
/bin/true (or something).  and then chmoding +x

That would prevent autostarting any daemons and avoid the need for ad-hoc process killing.

EDIT: An even more principled solution might be to use policy-rc.d to prevent any daemons from launching:

	Most people using chroot jails just need an one-line
script which returns an exit status of 101 as the jailed
/usr/sbin/policy-rc.d script.
 Exit status codes:
  0 - action allowed
  1 - unknown action (therefore, undefined policy)
 100 - unknown initscript id
 101 - action forbidden by policy

Liraz Siri's picture

I was thinking of using the fuser command to kill any process that had open files in /proc but neutralizing start-stop-daemon or policy-rc.d should prevent the problem outright. Killing processes can be a bit risky. If you send them a SIGTERM signal, they may ignore it or take their sweet time cleaning up and if you SIGKILL them you may leave something in an inconsistent state.

Add new comment