post-image-creation postinsts

post-image-creation postinsts

[Colin Walters]

Hi,

Currently from poky-bernard-5.0, in gdk-pixbuf_2.22.1.bb, we have:

postinst_pixbufloader () {
if [ "x$D" != "x" ]; then
    exit 1
fi

GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders
gdk-pixbuf-query-loaders --update-cache

test -x ${bindir}/gtk-update-icon-cache && gtk-update-icon-cache  -q
${datadir}/icons/hicolor
}

This results in a first-boot icon cache query in my image, which is
pretty lame since we could equally well do this after the image is
generated, and not on every computer that boots the image.

It seems to me we could add some mechanism for mounting the image
filesystem and running a script in there (guestfs?), or maybe an
automated QEMU boot, run the postinsts, and sync/shutdown?

Thoughts?

Re: post-image-creation postinsts

[Mark Hatle]

There is a variable that you can set specific commands to be executed post fs
creation, pre-packaging:

ROOTFS_POSTPROCESS_COMMAND

There is a catch with this and the item below.  In the case of a field upgrade,
the code is currently written to cause a refresh of the icon cache.  Assuming
this is desired behavior, then you would need to preserve existing behavior
(other then first boot) as well as add the new behavior for the rootfs post
process command.

NOTE: As far as I am aware, all of the rootfs class types [deb, rpm, and ipk]
run the post-install scripts as a unit -AFTER- the filesystem has been created.
 So if the cache can be generated on the host system, then there is no reason to
have the 'exit 1' in the code below -- and the use of ROOTFS_POSTPROCESS_COMMAND
is not needed.

(I have not investigated the pixbufloader items, but I would assume based on
experience with other caching programs, that it would need to be modified to
understand the sysroot environment and be able to cache the path names as they
would appear on the target and not on the host.  If we corrected this issues,
and provided a native version of the cache program -- we could likely resolve
this with a simply host app.)

--Mark


On 5/2/11 10:12 AM, Colin Walters wrote:
> Hi,
> 
> Currently from poky-bernard-5.0, in gdk-pixbuf_2.22.1.bb, we have:
> 
> postinst_pixbufloader () {
> if [ "x$D" != "x" ]; then
>     exit 1
> fi
> 
> GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders
> gdk-pixbuf-query-loaders --update-cache
> 
> test -x ${bindir}/gtk-update-icon-cache && gtk-update-icon-cache  -q
> ${datadir}/icons/hicolor
> }
> 
> This results in a first-boot icon cache query in my image, which is
> pretty lame since we could equally well do this after the image is
> generated, and not on every computer that boots the image.
> 
> It seems to me we could add some mechanism for mounting the image
> filesystem and running a script in there (guestfs?), or maybe an
> automated QEMU boot, run the postinsts, and sync/shutdown?
> 
> Thoughts?
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

Re: post-image-creation postinsts

[Richard Purdie]

On Mon, 2011-05-02 at 11:12 -0400, Colin Walters wrote:
> Currently from poky-bernard-5.0, in gdk-pixbuf_2.22.1.bb, we have:
> 
> postinst_pixbufloader () {
> if [ "x$D" != "x" ]; then
>     exit 1
> fi
> 
> GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders
> gdk-pixbuf-query-loaders --update-cache
> 
> test -x ${bindir}/gtk-update-icon-cache && gtk-update-icon-cache  -q
> ${datadir}/icons/hicolor
> }
> 
> This results in a first-boot icon cache query in my image, which is
> pretty lame since we could equally well do this after the image is
> generated, and not on every computer that boots the image.
> 
> It seems to me we could add some mechanism for mounting the image
> filesystem and running a script in there (guestfs?), or maybe an
> automated QEMU boot, run the postinsts, and sync/shutdown?
> 
> Thoughts?

The lines at the top:

if [ "x$D" != "x" ]; then
    exit 1
fi

force the script to run on the target device. If there is a way to run
this at image generation time (cross safe), tell us what it is and we
can make it happen at image generation time!

(postinstalls are run at image generation time with $D set to the
directory containing the image).

Cheers,

Richard

Re: post-image-creation postinsts

[Colin Walters]

Hi Richard,

On Tue, May 3, 2011 at 6:36 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
>> It seems to me we could add some mechanism for mounting the image
>> filesystem and running a script in there (guestfs?), or maybe an
>> automated QEMU boot, run the postinsts, and sync/shutdown?
>>
> force the script to run on the target device. If there is a way to run
> this at image generation time (cross safe), tell us what it is and we
> can make it happen at image generation time!

See the bit I quoted from my original mail.  I think the most general
solution is simply "run qemu, then shutdown", and I can look at
automating this inside OE, but was just curious if anyone had any
better ideas.

Would a patch to do this by default for image.bbclass make sense?

Re: post-image-creation postinsts

[Richard Purdie]

On Tue, 2011-05-03 at 19:01 -0400, Colin Walters wrote:
> On Tue, May 3, 2011 at 6:36 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> >> It seems to me we could add some mechanism for mounting the image
> >> filesystem and running a script in there (guestfs?), or maybe an
> >> automated QEMU boot, run the postinsts, and sync/shutdown?
> >>
> > force the script to run on the target device. If there is a way to run
> > this at image generation time (cross safe), tell us what it is and we
> > can make it happen at image generation time!
> 
> See the bit I quoted from my original mail.  I think the most general
> solution is simply "run qemu, then shutdown", and I can look at
> automating this inside OE, but was just curious if anyone had any
> better ideas.
> 
> Would a patch to do this by default for image.bbclass make sense?

Well, we've been trying to remove the dependencies on qemu rather than
add them. I'm still not convinced we need qemu for all these cases...

Cheers,

Richard

Re: post-image-creation postinsts

[Joshua Lock]

On Tue, 2011-05-03 at 19:01 -0400, Colin Walters wrote:
> Hi Richard,
> 
> On Tue, May 3, 2011 at 6:36 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> >> It seems to me we could add some mechanism for mounting the image
> >> filesystem and running a script in there (guestfs?), or maybe an
> >> automated QEMU boot, run the postinsts, and sync/shutdown?
> >>
> > force the script to run on the target device. If there is a way to run
> > this at image generation time (cross safe), tell us what it is and we
> > can make it happen at image generation time!
> 
> See the bit I quoted from my original mail.  I think the most general
> solution is simply "run qemu, then shutdown", 

Wouldn't this only work for images where there's kernel support for the
QEMU emulated devices? 

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Re: post-image-creation postinsts

[Mark Hatle]

On 5/3/11 6:22 PM, Joshua Lock wrote:
> On Tue, 2011-05-03 at 19:01 -0400, Colin Walters wrote:
>> Hi Richard,
>>
>> On Tue, May 3, 2011 at 6:36 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>>
>>>> It seems to me we could add some mechanism for mounting the image
>>>> filesystem and running a script in there (guestfs?), or maybe an
>>>> automated QEMU boot, run the postinsts, and sync/shutdown?
>>>>
>>> force the script to run on the target device. If there is a way to run
>>> this at image generation time (cross safe), tell us what it is and we
>>> can make it happen at image generation time!
>>
>> See the bit I quoted from my original mail.  I think the most general
>> solution is simply "run qemu, then shutdown", 
> 
> Wouldn't this only work for images where there's kernel support for the
> QEMU emulated devices? 

Yes, and that is precisely why we're trying to avoid QEMU as much as possible.

The right answer really is to fix the install actions with appropriately
modified native utilities to generate caches, files, etc as necessary on the
target filesystem -- without ever having to boot into the target filesystem.

--Mark

> Cheers,
> Joshua