Re: What drives automounting volumes?

[Gary Thomas <gary@mlbassoc.com>]

On 2014-12-04 09:04, Burton, Ross wrote:
> On 4 December 2014 at 15:58, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     I've noticed this before - the /run/media mounts were sometimes
>     present, other times not.  Any clues what drives this and why
>     they worked on Tuesday and not on Thursday (this week)?
>
>
> udev-extraconf is the recipe that installs these rules.  If you can replicate it working and not working reliably, then bisecting it would be appreciated.

Thanks.  It turns out that it was one of my other layers
(meta-fsl-arm) that was pulling in that package before and
now no longer does.  My base image did not explicitly include
udev-extraconf, so it was only the meta-fsl-arm recipe that
was bringing it in.

I've tried to add udev-extraconf to my image, but now I'm
getting this [strange] persistent error:
   Collected errors:
    * check_data_file_clashes: Package udev-rules-imx wants to install file 
/local/p0382-cutting-edge_2014-11-21/tmp/work/teton_p0382-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs/etc/udev/rules.d/10-imx.rules
         But that file is already provided by package  * udev-extraconf

This makes no sense to me as those packages do not have any
overlapping files:
   $ find tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/rules.d
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/rules.d/automount.rules
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/rules.d/localextra.rules
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/rules.d/autonet.rules
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/scripts
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/scripts/mount.sh
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/scripts/network.sh
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-extraconf/1.1-r0/image/etc/udev/mount.blacklist
   $ find tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-rules-imx/1.0-r0/image/
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-rules-imx/1.0-r0/image/
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-rules-imx/1.0-r0/image/etc
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-rules-imx/1.0-r0/image/etc/udev
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-rules-imx/1.0-r0/image/etc/udev/rules.d
   tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/udev-rules-imx/1.0-r0/image/etc/udev/rules.d/10-imx.rules

I've tried rebuilding both packages via
   $ bitbake udev-extraconf udev-rules-imx -c cleansstate
still the problem persisted.

After more investigation, I found why this is happening.  Previously
there was no udev-rules-imx, only a .bbappend to udev-extraconf
that did the same thing.  This caused the resulting package to
be considered machine dependent.  When the recipes were split,
the resulting packages are only architecture dependent.  Hence
the clash as the old machine dependent package still lives in
my package repo:
   $ find tmp/deploy/ipk/ -name "udev-extra*" -or -name "udev-rules-imx*"
   tmp/deploy/ipk/teton_p0382/udev-extraconf_1.1-r0.1_teton_p0382.ipk
   tmp/deploy/ipk/teton_p0382/udev-extraconf-dev_1.1-r0.1_teton_p0382.ipk
   tmp/deploy/ipk/teton_p0382/udev-extraconf-dbg_1.1-r0.1_teton_p0382.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-rules-imx-dev_1.0-r0.0_cortexa9hf-vfp-neon.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-extraconf-dbg_1.1-r0.0_cortexa9hf-vfp-neon.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-extraconf_1.1-r0.0_cortexa9hf-vfp-neon.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-rules-imx_1.0-r0.0_cortexa9hf-vfp-neon.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-rules-imx-dbg_1.0-r0.0_cortexa9hf-vfp-neon.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-extraconf-dev_1.1-r0.0_cortexa9hf-vfp-neon.ipk

So the clash is coming because the build uses these packages and it's picking from
   tmp/deploy/ipk/teton_p0382/udev-extraconf_1.1-r0.1_teton_p0382.ipk
   tmp/deploy/ipk/cortexa9hf-vfp-neon/udev-rules-imx_1.0-r0.0_cortexa9hf-vfp-neon.ipk
which would definitely have a clash.  When I remove the [now incorrect] machine
dependent packages, the image build succeeds.

Was there a way for the build system to have properly detected this
change and cleaned the machine dependent package?  I've seen it before
(very rarely) and it's really hard to figure out when it happens...

n.b. the main reason for this extensive email was to document
the issue I ran into and its solution in hopes of helping the
next poor sod (maybe me) that runs into this problem.  I can
see it biting any number of meta-fsl-arm users that had builds
that crossed 2014-12-03 when the change was made.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------