[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions regarding diversion of flash-kernel while building chroot



On Fri, Mar 02, 2012 at 12:50:36AM -0500, Cody A.W. Somerville wrote:
> I was curious why it is necessary to use dpkg-divert to temporarily
> disable /usr/sbin/flash-kernel per your patch accepted to live-build
> upstream but not start-stop-daemon which is instead just moved aside
> with mv a few lines above. Is it to properly handle the case where
> the file is updated via package upgrade? If so, I assume the other
> instances like start-stop-daemon need to be fixed to use dpkg-divert
> as well?

start-stop-daemon is installed as part of the base system, before
lb_chroot_dpkg runs.  flash-kernel is not, and if it's going to be
installed then it will be installed after flash-kernel.  This means that
the requirements are different.

I'm not sure whether it's possible for dpkg to be upgraded in the
context of a live-build run.  If it is, then start-stop-daemon needs to
be handled using dpkg-divert; otherwise, it isn't necessary.

> Additionally, I see you symlink /bin/true from outside the chroot to
> act as a dummy /usr/sbin/flash-kernel.

No, symlinks don't work that way.  The result of 'ln -s /bin/true
chroot/usr/sbin/flash-kernel' is that chroot/usr/sbin/flash-kernel
becomes a symlink inode with the text '/bin/true', which is resolved at
the point when it's opened, not before.  If you open
/usr/sbin/flash-kernel inside the chroot, then you'll get /bin/true
inside the chroot.

It's not possible to create a symlink that will result in the contents
of a file outside the chroot when opened inside the chroot.

> This is problematic if the (E)ABI between the host system and chroot
> system are incompatible (eg. armel host and armhf chroot) as the
> binary will not be executable and thus most likely cause the build to
> fail if flash-kernel is called. I've filed bug #661871 in Debian BTS
> regarding this.

IMO this bug should be closed as invalid.

Cheers,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]


Reply to: