What drives automounting volumes?

What drives automounting volumes?

[Gary Thomas]

I'm perplexed by a behaviour in my system.  When I built
on Dec 2 (poky/master=b8631416f12b8a904ce3deb036f9d5ce632937b0)
I get all available/mountable devices automatically mounted
at boot, e.g.
   # df
   Filesystem     1K-blocks    Used Available Use% Mounted on
   /dev/root        7487288 1020016   6086936  15% /
   devtmpfs          383760       4    383756   1% /dev
   tmpfs                 40       0        40   0% /mnt/.psplash
   tmpfs             514980     224    514756   1% /run
   tmpfs             514980     108    514872   1% /var/volatile
   /dev/mmcblk1p1      8168    4652      3516  57% /run/media/mmcblk1p1
   /dev/mmcblk1p2     43499   31903      9139  78% /run/media/mmcblk1p2
   /dev/sda1         126527    4676    121852   4% /run/media/sda1
   /dev/mmcblk0p1    126527    4960    121568   4% /run/media/mmcblk0p1
   /dev/mmcblk0p2  29723452   80044  28126872   1% /run/media/mmcblk0p2

Today I updated from master and when I rebuilt my image, those
/run/media/* file systems are gone (poky/master=a862bf045109d213c301121961bd8d389e48b13d)
   # df
   Filesystem     1K-blocks    Used Available Use% Mounted on
   /dev/root       15108832 1163564  13177764   9% /
   devtmpfs          383768       0    383768   0% /dev
   tmpfs                 40       0        40   0% /mnt/.psplash
   tmpfs             514988     268    514720   1% /run
   tmpfs             514988      92    514896   1% /var/volatile

This is the same hardware, the same system image, same everything.

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)?

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

Re: What drives automounting volumes?

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On 4 December 2014 at 15:58, Gary Thomas <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.

Ross

[-- Attachment #2: Type: text/html, Size: 811 bytes --]

Re: What drives automounting volumes?

[Gary Thomas]

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