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

["Cody A.W. Somerville" <cody.somerville@canonical.com>]

Hi Colin,

On 12-03-02 03:38 PM, Colin Watson wrote:
> 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.
Thanks for clarifying. Was just using start-stop-daemon as an example; 
there are other files such as initctl and hostname that appear to be in 
the same situation and thus should be handled using dpkg-divert.

> > 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.
Sorry - shouldn't write e-mails I guess late at night ;). In my defence, 
I think I've been working with hardlinks too much lately ;)

> > 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.
Agreed.

> Cheers,

Cheers,

--
Cody A.W. Somerville
Release Engineer
Commercial Engineering
Canonical Canada Ltd.
Phone: +1 781 850 2087
Cell: +1 613 401 5141
Fax: +1 613 687 7368
Email: cody.somerville@canonical.com